Cliquez sur « Upload » : la boîte de dialogue de l'outil de développement affiche une ligne en rouge : la taille du paquet principal dépasse la limite de 2 Mo. La version ne peut pas être publiée, les demandes sont en attente.
Cet article ne couvre pas une théorie exhaustive, mais présente uniquement les méthodes pour ramener le paquet principal sous les 2 Mo, classées par ordre de gain et de facilité de modification.
Comprendre d'abord : à quoi la limite de 2 Mo s'applique-t-elle ?
WeChat impose deux limites strictes pour la taille des paquets de code :
| Limite | Plafond |
|---|---|
| Paquet principal (incluant app.js, pages tabBar, ressources communes, etc.) | 2 Mo |
| Sous-paquet unique | 2 Mo |
| Toutes les combinaisons de paquets | 20 Mo |
Notez que la « taille » ici désigne le volume du paquet de code une fois téléchargé, et non seulement le JS. Tous les fichiers qui seront inclus dans l'empaquetage comptent : .js, .wxml, .wxss, ., polices, audio, et — habituellement la partie la plus lourde — les images.
C'est une contrainte rigide : si vous ne pouvez pas la réduire, vous ne pouvez pas publier la version. Ce n'est pas une optimisation optionnelle. Par conséquent, la première étape n'est pas d'agir, mais de voir précisément où l'espace est gaspillé.
Étape 0 : voir ce qui occipe l'espace dans le paquet principal
L'outil de développement WeChat permet de voir la taille totale du paquet de code local en allant dans « Détails » → « Informations de base » en haut à droite ; pour plus de détails, utilisez « Analyse des dépendances du code » dans la barre d'outils, qui liste les fichiers par volume et indique quels fichiers ne sont référencés par aucune page.
Dans la plupart des projets, après avoir vu ce tableau, on découvre la même chose : les ressources statiques comme les images et les polices sont beaucoup plus volumineuses que le code métier. Quelques dizaines de milliers de lignes de JS ne représentent que quelques centaines de Ko, tandis qu'une bannière non optimisée peut dépasser les centaines de Ko, et un répertoire images/ peut facilement engloutir la moitié du paquet principal.
La suite est classée du gain le plus élevé au plus faible.
Méthode 1 : supprimer les fichiers inutiles
La méthode la plus simple, et souvent la plus ignorée.
- Fichiers marqués comme non référencés dans l'« Analyse des dépendances du code » : anciens icônes de versions précédentes, pages abandonnées, images de test — supprimez-les directement.
- Fichiers qui ne devraient pas être inclus : maquettes, README,
.psd, matériaux originaux, données de test. Déplacez-les hors du répertoire du projet ; si ce n'est pas possible, utilisezpackOptions.ignoredansproject.config.pour les exclure :
{
"packOptions": {
"ignore": [
{ "type": "folder", "value": "design" },
{ "type": "suffix", "value": ".psd" }
]
}
}
- Intégration complète d'une bibliothèque de composants : utiliser une bibliothèque UI complète alors qu'on n'en utilise que trois composants est un « gros mangeur d'espace » fréquent. Changez pour une importation sélective (on-demand) et ne gardez que les répertoires des composants utilisés.
Méthode 2 : sous-paquets — déplacer les pages non premières hors du paquet principal
C'est la solution officielle. Le paquet principal ne doit contenir que la page de démarrage, les pages de barre d'onglets et les ressources communes dont elles ont réellement besoin ; le reste des pages doit être divisé en sous-paquets selon la logique métier :
{
"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"] }
}
}
Quelques points clés :
- Les ressources suivent les pages : les images et composants utilisés par les pages de sous-paquet doivent être placés dans leurs propres répertoires. Si vous les mettez dans un
images/commun du paquet principal, le volume sera toujours compté pour le paquet principal, peu importe comment vous divisez. preloadRulepour le téléchargement préalable : lors de l'entrée sur la page d'accueil, téléchargez en arrière-plan le sous-paquet qui sera probablement utilisé ensuite. L'utilisateur ne sentira pratiquement aucune latence quand il cliquera dessus.- Sous-paquets indépendants (
"independent": true) : adaptés pour les pages de campagnes ou de pages d'atterrissage qui peuvent s'ouvrir sans dépendre du paquet principal. - Asynchrone des sous-paquets : lors de références de composants ou de JS entre sous-paquets, utilisez des composants de substitution et
require.asyncpour éviter de devoir remonter le code dans le paquet principal juste pour « partager ».
L'inconvénient est qu'il faut modifier la structure des répertoires et les chemins de navigation. Le découpage d'un ancien projet demande un travail non négligeable, c'est pourquoi il vaut mieux d'abord faire l'étape suivante — souvent, après l'avoir faite, le paquet principal est déjà sous les 2 Mo.
Méthode 3 : comprimer les images (le moindre changement, le gain le plus direct)
Les images sont la partie la plus facile à « faire grossir inutilement » dans le paquet principal. Les PNG exportés par les designers contiennent des blocs de données superflus, et les JPG utilisent des paramètres de qualité élevés. Ces octets ne sont pas visibles par l'utilisateur, mais chaque octet compte pour les 2 Mo.
Quelques images doivent rester dans le paquet
Toutes les images ne peuvent pas être déplacées vers un CDN :
- Icônes de la barre d'onglets :
iconPath/selectedIconPathne peuvent être que des chemins locaux, les images en ligne ne sont pas supportées. - Page de démarrage, logo de l'écran d'accueil, images de repli : elles doivent être affichables même en cas de réseau faible ou hors ligne.
- Petites icônes fréquemment utilisées : charger à chaque fois depuis le réseau n'est pas rentable.
Ces images ne peuvent rester que dans le paquet, donc la seule méthode est de les rendre plus petites.
Attention à un piège courant : les images d'arrière-plan dans le wxss
Utiliser background-image dans .wxss pour référencer une image locale ne fonctionne pas sur l'appareil réel. La méthode habituelle consiste à la convertir en base64 en ligne. Mais le codage en base64 augmente le volume d'environ un tiers, et il est caché dans le fichier de style, donc peu visible dans l'analyse des dépendances. Si vous pouvez le changer en composant <image> ou en image en ligne, ne le faites pas en base64 ; si c'est impératif, compressez l'image originale d'abord avant de la convertir.
Utiliser ImgZilla pour compresser l'intégralité du répertoire de ressources sur place
Le plus redoutable pour les applets WeChat, c'est de devoir modifier les chemins après la compression — dans le wxml, le wxss, la configuration JS, la configuration de la barre d'onglets... De nombreux outils de compression sauvegardent sous xxx-min.png ou vous obligent à exporter dans un autre dossier, ce qui demande ensuite une manipulation manuelle pour remplacer et vérifier s'il ne manque rien.
ImgZilla est un outil de compression d'images pour macOS qui fonctionne sur place :
- Le nom de fichier, le chemin et le format ne changent pas.
icon-home.pngresteicon-home.png, aucune ligne de code à modifier. - Glissez simplement le répertoire entier. Il analyse récursivement tous les sous-répertoires et saute automatiquement les fichiers cachés et
node_modules. Glissezimages/,static/ou même tout le répertoire du projet ; après la compression, vous pouvez voir immédiatement la variation du volume du paquet dans l'outil de développement. - L'original est déplacé vers la corbeille par défaut. Si une image ne vous plaît pas, faites un clic droit pour « Restaurer ».
- Exécution locale, pas d'upload en ligne. Les matériaux des projets d'entreprise ne quittent pas votre ordinateur, et vous n'êtes pas limité par le nombre d'images ou la taille individuelle sur les sites de compression en ligne.
En ce qui concerne la qualité, le traitement varie selon le format :
- PNG : utilise oxipng pour une compression sans perte, aucun pixel ne change. Beaucoup d'icônes et de découpes d'applets sont en PNG, ce qui est sécurisé à compresser.
- SVG : nettoie les balises redondantes, également sans perte.
- JPG / WebP / GIF : il s'agit d'une re-encodage avec pertes, avec des paramètres réglés pour rester dans une zone de « perte visuelle négligeable » — difficile à distinguer à l'œil nu. N'acceptez pas aveuglément ; une fenêtre de comparaison intégrée (
⌘D) permet de comparer côte à côte et de zoomer pour voir les différences de pixels.
Deux autres points :
- Il ne force pas la compression sur des fichiers déjà optimisés : les fichiers avec un taux de compression inférieur à 0,4 % sont marqués comme « déjà minimaux » et sont conservés tels quels. Donc si vos images ont déjà été sérieusement optimisées, cette étape peut ne pas faire beaucoup d'économies — c'est normal et indique qu'il faut passer à la méthode suivante.
- Il ne convertit pas le format ni ne change la résolution. Un PNG reste un PNG après compression, la taille ne change pas. Si vous voulez passer au WebP ou passer d'une version 3x à une version 2x, c'est une autre opération qui nécessite un traitement séparé.
Le gain dépend de la manière dont vos images ont été exportées ; nous ne donnons pas de pourcentage générique. Comme référence, nous avons effectué deux tests publics : une série de JPG déjà compressés lors de l'indexation de site web a encore permis d'économiser 46,8 % après une nouvelle compression ; une série de JPG directement issus d'appareils photo a permis d'économiser 76,8 % (voir la série « Tests ImgZilla »). Les images dans les applets sont souvent exportées directement depuis des outils de design et généralement n'ont pas été sérieusement compressées, donc il vaut mieux y aller tout de suite.
ImgZilla est actuellement disponible uniquement sur macOS (macOS 12.3 et supérieur), téléchargeable sur l'App Store, avec 10 compressions gratuites par jour. Pour les étudiants développeurs sous Windows, la logique de cette section s'applique de la même manière : utilisez simplement un autre outil qui permet de « conserver le nom du fichier original ».
Méthode 4 : déplacer les grandes images vers un CDN
Après avoir comprimé, si certaines images sont encore trop volumineuses — comme les bannières de campagnes, les longues images de détail, les grandes images de produits — elles ne devraient pas être dans le paquet. Uploadez-les vers un stockage d'objets ou un CDN et remplacez les liens par des adresses réseau pour alléger immédiatement le paquet principal.
Mais ce n'est pas gratuit :
- Le premier chargement nécessite un réseau ; en cas de réseau faible, il y aura une période de blanc, mieux vaut utiliser une image de remplacement ou une page de chargement (skeleton screen).
- Il faut maintenir un processus de téléchargement, de mise en cache et de mise à jour.
- Le CDN est facturé au volume de données. Chaque chargement de l'image coûte de l'argent. Les frais de trafic sont approximativement égaux à « volume de l'image × nombre de vues ». C'est pourquoi il est tout aussi important de comprimer les images avant de les déplacer sur le CDN : une compression permet d'économiser du trafic à chaque chargement futur.
Méthode 5 : finitions au niveau du code
Une fois les images et la structure traitées, les derniers espaces peuvent être récupérés au niveau du code :
- Dans l'outil de développement, cochez « Compresser le script, le style et le WXML » lors du téléchargement dans « Détails » → « Paramètres locaux ».
- Activez
"lazyCodeLoading": "requiredComponents"dansapp.(injection sélective). Cela améliore principalement la vitesse de démarrage plutôt que la taille du paquet, mais puisque l'on optimise les performances, autant l'activer. - Vérifiez
miniprogram_npm: le paquet npm construit contient-il des importations intégrales alors qu'on n'utilise que quelques fonctions ? - Les grandes quantités de données statiques écrites en dur dans le JS (listes de villes, tableaux de configuration) peuvent être remplacées par des appels d'API.
Résumé sous forme de tableau
| Méthode | Gain | Changements requis | Ordre suggéré |
|---|---|---|---|
| Supprimer les fichiers inutiles | Selon l'historique du projet | Très peu | 1 |
| Compression d'images sur place | Plus les images sont nombreuses et mal exportées, plus on gagne | Presque rien, chemins inchangés | 2 |
| Sous-paquets | Peut être important | Modification des répertoires et des routes | 3 |
| Grandes images vers CDN | Beaucoup | Modification des références, maintenance du processus de téléchargement | 4 |
| Compression du code et importation sélective | Moins | Selon le cas | 5 |
La logique de l'ordre est simple : faire d'abord les changements minimes, puis les changements importants. La suppression de fichiers et la compression d'images ne touchent presque pas au code métier ; après l'avoir fait, regardez combien il manque au paquet principal — si vous êtes déjà sous les 2 Mo, la version d'aujourd'hui peut être publiée ; si ce n'est pas suffisant, passez alors aux sous-paquets et au CDN, vous aurez une idée claire.
Le dépassement de la limite du paquet principal arrive souvent juste avant la mise en ligne, dans une période de stress. Intégrez la compression d'images dans votre routine — compressez toujours avant d'ajouter une nouvelle image — et la prochaine fois, vous n'aurez pas à vous inquiéter devant cette ligne rouge à la date limite.