Cosa fare se la dimensione del bundle principale di WeChat Mini Program supera i 2MB: un elenco di ottimizzazione ordinato per beneficio

Clicca su "Carica" e lo strumento di sviluppo mostra una riga di testo rosso: la dimensione del bundle principale supera il limite di 2MB. La versione non può essere pubblicata e le richieste sono in coda.
Questo articolo non è un manuale teorico, ma elenca metodi per ripristinare il bundle principale sotto i 2MB in ordine di "risparmio maggiore, modifica minore".

Prima di tutto: di cosa si occupa il limite di 2MB

WeChat ha due limiti rigidi per la dimensione dei bundle di codice dei mini programmi:

Limitazione	Soglia
Bundle principale (incluso app.js, pagine tabBar, risorse pubbliche, ecc.)	2MB
Singolo subbundle	2MB
Tutti i bundle del mini programma sommati	20MB

Nota che qui "dimensione" si riferisce al volume del bundle di codice dopo l'upload, non solo a JS. Tutti i file nella directory del progetto che vengono impacchettati contano: .js, .wxml, .wxss, ., font, audio e, solitamente, le immagini.

Questo è un limite rigido di "se non si può comprimere, non si può pubblicare la versione", non "ottimizzare per ottenere un risultato migliore". Quindi il primo passo non è agire, ma capire prima di tutto dove vanno i soldi.

Passo 0: Capire cosa occupa spazio nel bundle principale

Nello strumento di sviluppo WeChat, "Dettagli → Informazioni di base" in alto a destra mostra la dimensione totale del bundle di codice locale; per i dettagli più precisi c'è "Analisi dipendenze del codice" nella barra degli strumenti, che elenca i file per volume e segnala quali file non sono referenziati da nessuna pagina.

La maggior parte dei progetti dopo aver guardato questa tabella scoprirà la stessa cosa: le risorse statiche come immagini e font sono molto più grandi del codice aziendale. Scrivere decine di migliaia di righe di JS richiede solo centinaia di KB, mentre una singola banner non elaborata può superare i centinaia di KB, e una directory images/ può facilmente mangiare metà del bundle principale.

Di seguito sono elencati i metodi in ordine dal beneficio maggiore a quello minore.

Metodo 1: Eliminare file completamente inutili

Il metodo più facile e quello più spesso trascurato.

File contrassegnati come "non referenziati" nell'"Analisi dipendenze del codice": icone obsolete, pagine abbandonate, immagini di test, ecc. Eliminale direttamente.
File che non dovrebbero entrare nel bundle: bozze di design, README, .psd, materiali originali, dati Mock. Se possibile spostali fuori dalla directory del progetto; se non possibile, usa packOptions.ignore in project.config. per escluderli:

{
"packOptions": {
"ignore": [
{ "type": "folder", "value": "design" },
{ "type": "suffix", "value": ".psd" }
]
}
}

Introduzione completa della libreria di componenti: è comune "ingrassare" in modo invisibile il bundle principale importando l'intera libreria UI quando si usano solo tre componenti. Cambia per un'importazione on-demand, mantenendo solo le directory dei componenti utilizzati.

Metodo 2: Subbundle — sposta fuori dal bundle principale le pagine non nella prima schermata

Questa è la soluzione ufficiale. Lascia nel bundle principale solo la pagina di avvio, le pagine tabBar e il loro codice pubblico reale necessario; le altre pagine, in base al business, vengono suddivise in subbundle:

{
"pages": ["pages/index/index", "pages/mine/mine"],
"subPackages": [
{ "root": "packageOrder", "pages": ["list/list", "detail/detail"] },
{ "root": "packageActivity", "pages": ["index/index"] }
],
"preloadRule": {
"pages/index/index": { "network": "all", "packages": ["packageOrder"] }
}
}

Punti chiave:

Risorse seguono la pagina: le immagini e i componenti usati dalle pagine del subbundle devono essere inseriti nella directory del subbundle. Metterli nella cartella pubblica images/ del bundle principale significa che, indipendentemente da come si suddivide il subbundle, il volume viene comunque contato nel bundle principale.
PreloadRule — pre-download subbundle: quando si entra nella pagina iniziale, scarica in anticipo il subbundle che si presume verrà usato nel prossimo passo, in modo che l'utente quasi non senta ritardi quando lo apre.
Subbundle indipendente ("independent": true): ideale per pagine di eventi o pagine di atterraggio che possono essere aperte indipendentemente dal bundle principale senza dipendere da esso all'avvio.
Subbundle asincrono: quando si fanno riferimenti incrociati a componenti o JS tra subbundle, si possono usare componenti di segnaposto e require.async per evitare di "condividere" il codice riportandolo nel bundle principale.

Il costo del subbundle è dover modificare la struttura delle directory e i percorsi di navigazione. Per i progetti vecchi, il lavoro di suddivisione non è poco, il che spiega perché vale la pena fare prima il seguente passaggio — spesso, dopo averlo fatto, il bundle principale ritorna sotto i 2MB.

Metodo 3: Comprimere le immagini (modifica minima, beneficio diretto)

Le immagini sono la parte più facile che si "ingrassa" nel bundle principale. Le PNG esportate dai designer contengono blocchi di dati inutili, e i JPG usano parametri di qualità troppo alti. Questi byte non sono visibili dagli utenti, ma ogni singolo byte conta per i 2MB.

Quali immagini devono rimanere nel bundle

Non tutte le immagini possono essere spostate su CDN:

Icone tabBar: iconPath / selectedIconPath devono essere percorsi locali, le immagini di rete non sono supportate.
Pagina di avvio, logo della prima schermata, immagini segnaposto di fallback: devono essere visualizzabili anche in rete debole o offline.
Icone piccole che appaiono frequentemente: non conviene farne una richiesta di rete ogni volta.

Queste immagini possono solo rimanere nel bundle, quindi l'unico metodo è renderle più piccole.

Evitare una trappola comune: immagini di sfondo in wxss

Usare background-image in .wxss per fare riferimento a immagini locali non ha effetto su dispositivi reali; il metodo comune è convertirle in base64 inline. Tuttavia, la codifica base64 fa aumentare il volume di circa un terzo e si nasconde nel file di stile, rendendola meno evidente nell'analisi delle dipendenze. Se possibile, cambia in un componente <image> o immagine di rete; se non è possibile farlo inline, comprimi prima l'originale prima di convertire.

Usare ImgZilla per comprimere in loco l'intera directory delle risorse

Quello che teme di più nello sviluppo di mini programmi è dover tornare a modificare i percorsi dopo aver compresso le immagini — in wxml, in wxss, nelle configurazioni JS, nella configurazione tabBar, ecc. Dappertutto c'è /images/xxx.png. Molti strumenti di compressione salvano come xxx-min.png o richiedono di esportare in una cartella diversa, costringendoti a sostituire manualmente e a ricontrollare se hai perso qualcosa.

ImgZilla è uno strumento di compressione immagini per macOS che funziona con compressione in loco:

Nome file, percorso e formato non cambiano. icon-home.png dopo la compressione è ancora icon-home.png, nessuna modifica richiesta nel codice.
Trascina semplicemente l'intera directory. Scansiona ricorsivamente tutte le sottocartelle e salta automaticamente i file nascosti e node_modules. Trascina images/, static/ o persino tutta la directory del progetto; dopo la compressione puoi controllare immediatamente il volume del bundle nello strumento di sviluppo.
Per impostazione predefinita, l'originale va nel Cestino. Se non ti piace il risultato, clicca con il tasto destro su "Torna indietro" per ripristinarlo. Se il progetto è in Git, hai un ulteriore strumento di sicurezza.
Elaborazione completamente locale, senza caricamento in rete. I materiali dei progetti aziendali non lasciano il tuo computer e non ci sono limiti di numero di immagini o dimensione singola tipici dei siti di compressione online.

Per quanto riguarda la qualità, il modo di elaborazione è diverso per i vari formati, ecco come funziona:

PNG: usa oxipng per una compressione senza perdita. I pixel non cambiano affatto. Le icone e le immagini tagliate per i mini programmi sono principalmente in PNG, quindi questa parte può essere compressa con fiducia.
SVG: pulisce i tag ridondanti, anch'esso senza perdita.
JPG / WebP / GIF, ecc.: è una riscrittura con perdita. I parametri sono già ottimizzati nell'intervallo "visivamente senza perdita" — difficile notare la differenza a occhio nudo. Non c'è bisogno di fidarsi ciecamene; c'è una finestra di confronto integrata (⌘D) che permette di dividere lo schermo a sinistra e destra e di ingrandire a pixel reali per confrontare le immagini una per una.

Due punti aggiuntivi da sapere:

Non comprimerà duramente le immagini già ottimizzate: i file con una percentuale di compressione inferiore a 0,4% sono contrassegnati come "già minimizzati" e vengono conservati così, senza appiattire l'immagine solo per avere un numero migliore. Quindi se le tue immagini sono già state attentamente ottimizzate, questo passaggio potrebbe risparmiare poco — è normale e indica che dovresti passare al subbundle.
Non cambia formato o risoluzione. PNG compresso resta PNG, le dimensioni non cambiano. Se vuoi cambiare il formato in WebP o ridurre una immagine a 3x in una a 2x, è un'altra faccenda che richiede un trattamento separato.

Quanto si può risparmiare dipende da come sono state esportate le immagini originalmente, non possiamo dare una percentuale generica. Come riferimento, abbiamo effettuato due test pubblici: un batch di JPG già compressi al momento dell'archiviazione del sito web ha risparmiato ancora il 46,8% dopo una seconda compressione; un altro batch di JPG diretti dalla fotocamera ha risparmiato il 76,8% (vedi la serie "Test ImgZilla"). Le immagini nei mini programmi sono spesso esportate direttamente dagli strumenti di design, spesso non statestate attentamente compresse, quindi vale la pena farlo una volta per vedere.

ImgZilla è attualmente disponibile solo per macOS (macOS 12.3 o superiore) e può essere scaricato dall'App Store di Mac. Puoi comprimere gratuitamente 10 immagini al giorno. Per gli studenti che usano Windows, il ragionamento di questa sezione vale comunque, basta usare uno strumento che supporti la "conservazione del nome del file".

Metodo 4: Sposta le immagini grandi su CDN

Dopo averle comprime, se le immagini sono ancora molto grandi — come banner di eventi, immagini lunghe per le pagine di dettaglio, grandi immagini dei prodotti — non dovrebbero essere nel bundle. Caricale su object storage o CDN e cambia gli indirizzi in codice, il bundle principale si alleggerisce immediatamente.

Tuttavia, non è gratuito:

Il primo caricamento richiede una richiesta di rete, ci sarà un periodo di bianco in rete debole, è meglio abbinarlo a immagini segnaposto o scheletri (skeleton screen).
Devi mantenere un flusso di caricamento, cache e aggiornamento.
CDN addebitato in base al traffico. Ogni volta che un'immagine viene caricata costa, le spese per il traffico equivalono a "volume immagine × numero di accessi". Quindi, prima di spostare su CDN, vale la pena comprimere le immagini — comprimere una volta fa risparmiare traffico per ogni accesso futuro.

Metodo 5: Chiusura a livello di codice

Dopo aver gestito immagini e struttura, puoi recuperare spazio rimanente dal codice:

Nello strumento di sviluppo, vai su "Dettagli → Impostazioni locali" e seleziona la compressione dello script, dello stile e di WXML durante l'upload.
Apri "lazyCodeLoading": "requiredComponents" in app. (iniezione on-demand). Questo migliora principalmente la velocità di avvio piuttosto che la dimensione del bundle, ma dato che stai facendo ottimizzazioni delle prestazioni, attivalo comunque.
Controlla miniprogram_npm: verifica se il bundle npm generato contiene importazioni complete quando si usano solo una o due funzioni.
Considera di convertire i grandi blocchi di dati statici hardcoded in JS (elenco delle città, tabelle di configurazione) in dati scaricati via API.

Riepilogo in tabella

Metodo	Risparmio stimato	Modifiche richieste	Ordine consigliato
Elimina file inutili	Dipende dal "peso" storico del progetto	Molto poche	1
Compressione immagini in loco	Dipende dalle immagini e da come sono state esportate, più risparmio maggiore	Quasi nulla, percorsi invariati	2
Subbundle	Molto	Struttura directory e rotte da modificare	3
Sposta immagini grandi su CDN	Molto	Modifica riferimenti, manutenzione flusso upload	4
Compressione codice e importazione on-demand	Poco	Dipende dalla situazione	5

Il logica è semplice: fai prima le modifiche minori, poi quelle maggiori. Eliminare file e comprimere immagini non toccano quasi il codice aziendale; dopo aver fatto questo, controlla quanto manca al bundle principale — se è già sotto i 2MB, questa versione può essere pubblicata oggi; se non basta, allora agisci con subbundle e CDN, avendo un quadro chiaro.

Il superamento del limite del bundle principale avviene spesso nei momenti più stressanti prima del lancio. Inserisci la compressione delle immagini in un processo quotidiano — comprimi sempre prima di aggiungere una nuova immagine — così la prossima volta non dovrai preoccuparti davanti a quella riga rossa alla scadenza.