Klik op 'Uploaden', dan verschijnt er een rode tekst in de ontwikkeltools: de grootte van het hoofdpakket overschrijdt de 2MB-limiet. De versie kan niet worden geüpload en de requirements staan in de rij.
In dit artikel gaat het niet over een overzicht van de theorie, maar over methoden om het hoofdpakket onder de 2MB te krijgen, gesorteerd op 'veel bespaart, weinig moet veranderen'.
Eerst even duidelijk maken: waarom precies 2MB de limiet is
WeChat heeft twee harde limieten voor de grootte van de codepakketten van Mini Programmen:
| Limiet | Limiet |
|---|---|
| Hoofdpakket (incl. app.js, tabBar-pagina's, gedeelde bronnen, etc.) | 2MB |
| Een enkel subpakket | 2MB |
| Totaal van alle pakketten van het hele Mini Programma | 20MB |
Let op dat de 'grootte' hier de grootte van het geüploade codepakket is, niet alleen JS. Alle bestanden in de projectmap die meegenomen worden in het pakket tellen mee: .js, .wxml, .wxss, ., lettertypes, audio, en — meestal het grootste deel — afbeeldingen.
Dit is een harde limiet: als je de grootte niet onder controle krijgt, gaat er geen versie uit. Het is geen 'optimalisatie die leuk is', maar een noodzakelijke vereiste. Dus stap één is niet het direct aanpakken van de code, maar eerst goed kijken waar de ruimte gaat.
Stap 0: Kijk goed wat er in het hoofdpakket zit
In de rechterbovenhoek van de WeChat-ontwikkeltools kun je via 'Details → Basisinformatie' de totale grootte van het lokale codepakket zien; meer gedetailleerd is het in de werkbalk 'Code afhankelijkheidsanalyse', waar bestanden per bestand kunnen worden weergegeven en gemarkeerd welke bestanden niet door een enkele pagina worden gebruikt.
Bij de meeste projecten leert men uit deze tabel één ding: statische bronnen zoals afbeeldingen en lettertypes zijn veel groter dan de bedrijfscode. JS is in de orde van duizenden regels, wat nog eens honderden KB is, maar een niet-geoptimaliseerde banner-afbeelding kan al honderden KB zijn, en een images/-map kan het hoofdpakket gemakkelijk in tweeën delen.
Hieronder staan de methoden gesorteerd op baten van groot naar klein.
Methode 1: Verwijder bestanden die helemaal niet nodig zijn
Het makkelijkste en het vaakst over het hoofd geziene.
- Bestanden gemarkeerd als niet verwezen in de 'Code afhankelijkheidsanalyse': oude iconen van eerdere versies, verouderde pagina's, testafbeeldingen — verwijder ze direct.
- Bestanden die niet in het pakket horen: ontwerpschetsen, README,
.psd, originele bronnen, mock-data. Zet ze buiten de projectmap; als dat niet kan, negeer ze inproject.config.metpackOptions.ignore:
{
"packOptions": {
"ignore": [
{ "type": "folder", "value": "design" },
{ "type": "suffix", "value": ".psd" }
]
}
}
- Gehele componentbibliotheek importeren: Als je maar drie componenten gebruikt, maar de hele UI-bibliotheek in het hoofdpakket stopt, dan heb je een 'verborgen dikke'. Pas op voor nodig importeren en houd alleen de gebruikte componentmappen over.
Methode 2: Subpakketten — verplaats niet-alleen-voor-de-startpagina's naar buiten
Dit is de officiële oplossing. Laat alleen de startpagina, tabBar-pagina's en de daadwerkelijk benodigde gedeelde code in het hoofdpakket, en verdeel de overige pagina's op basis van de bedrijfslogica in subpakketten:
{
"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"] }
}
}
Belangrijke punten:
- Bronnen gaan met de pagina mee: Afbeeldingen en componenten die voor een subpakketpagina nodig zijn, moeten in de subpakketmap geplaatst worden. Als ze in het hoofdpakket in een gedeelde
images/staan, telt de grootte van het subpakket niet mee, maar de grootte van het hoofdpakket blijft gelijk. preloadRulevoor vooraf downloaden van subpakketten: Als gebruikers de startpagina openen, download je vooraf het subpakket dat waarschijnlijk de volgende stap is, zodat er geen vertraging is als ze daadwerkelijk op de pagina klikken.- Onafhankelijke subpakketten ("independent": true): Geschikt voor activiteitpagina's, landingspagina's en andere pagina's die los van het hoofdpakket kunnen worden geopend; deze hoeven bij het opstarten niet afhankelijk te zijn van het hoofdpakket.
- Asynchroon subpakketten: Bij het verwijzen naar componenten of JS van een ander subpakket kan met een placeholder-component en
require.asyncworden voorkomen dat de code omwille van het 'delen' weer in het hoofdpakket wordt geplaatst.
De prijs hiervoor is dat de mappenstructuur en de navigatiepaden moeten worden gewijzigd. Het splitsen van een oud project kost veel werk, wat ook de reden is waarom het de moeite waard is eerst de volgende stap te doen — vaak is het hoofdpakket al onder de 2MB na deze stap.
Methode 3: Maak afbeeldingen kleiner (minste wijzigingen, directste baten)
Afbeeldingen zijn het deel van het hoofdpakket dat het makkelijkst 'ongewogen dik' kan worden. Ontwerpers exporteren PNG's met extra datablokken en JPG's met hoge kwaliteit; deze bytes zijn voor de gebruiker niet zichtbaar, maar tellen wel mee voor de 2MB.
Welke afbeeldingen moeten in het pakket blijven
Niet alle afbeeldingen kunnen naar een CDN worden verplaatst:
- TabBar-icoontjes:
iconPath/selectedIconPathkunnen alleen lokale paden zijn en ondersteunen geen netwerkafbeeldingen. - Startpagina, startscherm-logo, fallback-plaatjes: Deze moeten ook getoond worden bij zwakke netwerken of offline.
- Kleine iconen die vaak voorkomen: Elke keer een netwerkverzoek doen is niet voordeliger.
Deze afbeeldingen moeten in het pakket blijven, dus de enige manier is ze kleiner te maken.
Vermijd een valkuil: achtergrondafbeeldingen in wxss
Het gebruik van background-image in .wxss om lokale afbeeldingen aan te roepen werkt niet op echte apparaten; een veelvoorkomende oplossing is het omzetten naar base64 inline. Maar base64-codering maakt de grootte ongeveer een derde groter, en het zit verstopt in het stijlbestand, dus het valt minder op in de afhankelijkheidsanalyse. Als je het kunt veranderen naar een <image>-component of een netwerkafbeelding, doe dat dan niet inline; als het niet anders kan, maak de originele afbeelding eerst kleiner en converteer daarna.
Gebruik ImgZilla om een hele resource-map direct te comprimeren
Het allerergste bij het werken aan Mini Programmen is dat je na het comprimeren van afbeeldingen de paden opnieuw moet aanpassen — in wxml, in wxss, in JS-configuratie, in de tabBar-configuratie; overal staan /images/xxx.png. Veel compressietools slaan het op als xxx-min.png of vereisen dat je het naar een andere map exporteert; dan moet je handmatig vervangen en dubbelchecken of je iets bent vergeten.
ImgZilla is een macOS-tool voor het comprimeren van afbeeldingen. Zijn aanpak is direct comprimeren (in-place):
- Bestandsnaam, pad en formaat veranderen niet.
icon-home.pngblijfticon-home.png; in de code hoeft er niets aangepast te worden. - Slepen van een hele map. Het scant recursief alle submappen en slaat verborgen bestanden en
node_modulesover. Sleep deimages/-map, destatic/-map of zelfs de hele projectmap in; na het comprimeren zie je direct de verandering in de pakketgrootte in de ontwikkeltools. - De originele bestanden gaan standaard naar de prullenmand. Als je niet tevreden bent over een bepaald bestand, kun je het met een rechtermuisknop 'terugplaatsen'. Als je project in Git staat, heb je er een extra laag bescherming bij.
- Lokale uitvoering, geen upload naar het internet. De bronnen van bedrijfsprojecten blijven op je eigen computer; er zijn geen limieten op het aantal bestanden of de grootte per bestand zoals bij online compressiesites.
Wat betreft de kwaliteit: de verwerking verschilt per formaat, hier is het duidelijk:
- PNG: oxipng wordt gebruikt voor zonder verlies van kwaliteit comprimeren; de pixels veranderen niet. Veel iconen en snipets in Mini Programmen zijn PNG, dit deel kan veilig worden geoptimaliseerd.
- SVG: het opruimen van overbodige tags is ook zonder verlies van kwaliteit.
- JPG / WebP / GIF etc.: dit is met verlies van kwaliteit recoderen; de parameters zijn al zo ingesteld op een visueel verlies-vrij bereik — voor het oog nauwelijks zichtbaar verschil. Gebruik het ingebouwde vergelijkingsvenster (
⌘D) om met vergelijking en zoom naar pixelniveau te controleren.
Twee extra dingen die het weten waard zijn:
- Het comprimeert niet zwaar als de compressie al dicht bij het minimum ligt: bestanden met minder dan 0,4% verbetering worden gemarkeerd als 'al minimaal' en worden origineel bewaard. Het wordt niet verward om cijfers mooi te maken door de kwaliteit te verlagen. Dus als je afbeeldingen al goed zijn geoptimaliseerd, levert deze stap weinig op — wat normaal is en aangeeft dat het tijd is om naar subpakketten te gaan.
- Het verandert formaat of resolutie niet. PNG blijft PNG, de afmeting blijft hetzelfde. Als je wilt overschakelen naar WebP of van 3x naar 2x wilt gaan, is dat een andere zaak die apart moet worden afgehandeld.
Hoeveel je kunt besparen hangt af van hoe de afbeeldingen oorspronkelijk zijn geëxporteerd, dus hier geven we geen algemene percentage. Als referentie hebben we twee openbare tests gedaan: een batch JPG die al was geoptimaliseerd voor website-invoer, bespaarde nog 46,8% bij nog een keer comprimeren; een batch JPG direct van de camera bespaarde 76,8% (zie de 'ImgZilla Tests'-serie). Afbeeldingen in Mini Programmen zijn vaak direct geëxporteerd vanuit ontwerptools en zelden al goed geoptimaliseerd, dus het is de moeite waard om dit even te proberen.
ImgZilla is momenteel alleen beschikbaar voor macOS (macOS 12.3 of hoger), verkrijgbaar in de Mac App Store; er kunnen gratis 10 afbeeldingen per dag worden gecomprimeerd. Voor gebruikers van Windows is het concept hieronder eveneens toepasbaar; gebruik een andere tool die ook 'originele bestandsnamen bewaart'.
Methode 4: Verplaats grote afbeeldingen naar een CDN
Na het comprimeren zijn er nog grote afbeeldingen — zoals activiteitsbanners, lange detailpagina's, grote productafbeeldingen — die eigenlijk niet in het pakket thuishoren. Upload ze naar objectopslag of een CDN en gebruik de netwerk-URL's in de code; het hoofdpakket wordt direct lichter.
Maar dit is niet kosteloos:
- De eerste laadvergissing gaat via het netwerk; bij zwakke netwerken kan er een lege periode zijn, dus het is beter om een placeholder-afbeelding of skeleton screen te gebruiken.
- Je moet een proces voor uploaden, cachen en updaten in stand houden.
- CDN rekent per verkeer. Elke keer dat een afbeelding wordt geladen, wordt er voor betaald; de kosten voor verkeer zijn ongeveer gelijk aan 'afbeeldingsgrootte × aantal keer bekeken'. Dus voordat je iets naar een CDN verplaatst, is het de moeite waard om eerst af te sluiten wat kleiner is; comprimeer één keer, dan bespaar je verkeer bij elke volgende weergave.
Methode 5: Finale afronding op code-niveau
Na het afhandelen van afbeeldingen en de structuur kunnen de resterende kleine ruimtes van de code worden weggehaald:
- In de ontwikkeltools 'Details → Lokale instellingen' het selectievakje aanvinken voor compressie van scripts, stijlen en WXML bij het uploaden.
app.de optie"lazyCodeLoading": "requiredComponents"inschakelen (op aanvraag injecteren). Dit verbetert vooral de startsnelheid in plaats van de pakketgrootte, maar als je al bezig bent met prestatie-optimalisatie, kun je dit ook aan.- Controleer
miniprogram_npm: of het gegenereerde npm-pakket niet de hele bibliotheek importeert terwijl er maar één of twee functies worden gebruikt. - Grote hoeveelheden statische data die in de JS geschreven zijn (stedenlijst, configuratietabellen) overwegen om via API's op te halen in plaats van hardcoded te laten staan.
Samenvatting in een tabel
| Methode | Besparing | Wijzigingen | Aanbevolen volgorde |
|---|---|---|---|
| Onnodige bestanden verwijderen | Afhankelijk van historie | Weinig | 1 |
| Directe comprimeren van afbeeldingen | Hoe meer afbeeldingen, hoe losser geëxporteerd, hoe meer besparing | Bijna nul, paden ongewijzigd | 2 |
| Subpakketten | Kan veel zijn | Mappen en routes moeten aangepast worden | 3 |
| Grote afbeeldingen naar CDN | Veel | Verwijzingen aanpassen, uploadproces onderhouden | 4 |
| Code-compressie en op aanvraag importeren | Weinig | Afhankelijk van situatie | 5 |
De logica achter de volgorde is simpel: eerst de wijzigingen die klein zijn, daarna de grote wijzigingen. Het verwijderen van bestanden en het comprimeren van afbeeldingen raakt nauwelijks de bedrijfscode; als het hoofdpakket dan al onder de 2MB is, kan de huidige versie worden geüpload; als dat nog niet genoeg is, ga dan naar subpakketten en CDN. Dan heb je een goed beeld.
Het overschrijden van de limiet gebeurt vaak vlak voor de lancering. Zet het comprimeren van afbeeldingen in het dagelijks proces — comprimeer nieuwe afbeeldingen altijd even voordat ze in het project komen — dan hoef je bij een volgende deadline niet meer in paniek te kijken naar die rode tekst.