Al hacer clic en "Subir", las herramientas de desarrollo muestran una línea de texto rojo: el tamaño del paquete principal supera el límite de 2 MB. La versión no se puede publicar y las solicitudes están en cola.
Este artículo no trata sobre una enciclopedia de principios, sino que enumera métodos para reducir el paquete principal por debajo de los 2 MB, ordenados por "ahorro grande, cambios pequeños".
Primero aclaremos: ¿qué está bloqueado exactamente con los 2 MB
WeChat tiene dos límites duros para el tamaño del paquete de código de Mini Programas:
| Límite | Límite |
|---|---|
| Paquete principal (incluyendo app.js, páginas tabBar, recursos públicos, etc.) | 2 MB |
| Subpaquete individual | 2 MB |
| Tamaño total de todos los paquetes del Mini Programa | 20 MB |
Tenga en cuenta que el "tamaño" aquí es el volumen del paquete de código después de la carga, no solo JS. Todos los archivos que se empaquetarán en el proyecto cuentan: .js、.wxml、.wxss、.、fuentes, audio, y --que a menudo ocupan la mayor parte-- las imágenes.
Es una restricción rígida de "no se puede publicar si no se puede reducir", no una "optimización que es mejor". Por lo tanto, el primer paso no es empezar a trabajar, sino ver primero dónde se gasta el dinero.
Paso 0: Ver qué está ocupando espacio en el paquete principal
En las herramientas de desarrollo de WeChat, "Detalles → Información básica" en la esquina superior derecha muestra el tamaño total del paquete de código local; para algo más detallado, use "Análisis de dependencias de código" en la barra de herramientas, que enumera el volumen por archivo y marca qué archivos no son referenciados por ninguna página.
La mayoría de los proyectos, tras ver esta tabla, descubrirán lo mismo: los recursos estáticos como imágenes y fuentes son mucho más grandes que el código de negocio. Un JS escrito con decenas de miles de líneas solo tiene unos cientos de KB, mientras que una imagen de banner sin procesar puede ser de cientos de KB, y un directorio images/ puede comerse fácilmente la mitad del paquete principal.
A continuación, se ordenan por beneficio de mayor a menor.
Método 1: Eliminar archivos que no sirven para nada
El más sencillo, y el que a menudo se pasa por alto.
- Archivos marcados como no referenciados en "Análisis de dependencias de código": iconos antiguos de versiones anteriores, páginas obsoletas, imágenes de prueba, eliminarlos directamente.
- Archivos que no deben entrar en el paquete: bocetos de diseño, README,
.psd, materiales originales, datos Mock. Si se pueden mover fuera del directorio del proyecto, muévanlos; si no, usepackOptions.ignoreenproject.config.para excluirlos:
{
"packOptions": {
"ignore": [
{ "type": "folder", "value": "design" },
{ "type": "suffix", "value": ".psd" }
]
}
}
- Introducción completa de la biblioteca de componentes: es común tener un "hombre invisible gordito" al introducir toda la biblioteca de UI solo para usar tres componentes. Cambie a introducción bajo demanda, mantenga solo los directorios de componentes que se usan.
Método 2: Subpaquetes -- Mover páginas que no son de la pantalla principal fuera del paquete principal
Esta es la solución oficial. El paquete principal solo debe contener la página de inicio, las páginas tabBar y su código público necesario, y las demás páginas se dividen por negocio en subpaquetes:
{
"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"] }
}
}
Puntos clave:
- Recursos que siguen a las páginas: las imágenes y componentes usados por las páginas del subpaquete deben colocarse en el directorio del subpaquete. Si se ponen en
images/público del paquete principal, independientemente de cómo se divida el subpaquete, el volumen todavía se cuenta como parte del paquete principal. - Descarga previa de subpaquetes (
preloadRule): al entrar en la página de inicio, descargue a la vez los subpaquetes que es probable que se usen en el siguiente paso, para que el usuario casi no sienta la demora al hacer clic en ellos. - Subpaquetes independientes (
"independent": true): adecuados para páginas como actividades o páginas de aterrizaje que pueden abrirse independientemente del paquete principal, no dependiendo del paquete principal al iniciar. - Asincronización de subpaquetes: al hacer referencia a componentes o JS entre subpaquetes, puede usar componentes de marcador de posición y
require.asyncpara evitar traer de nuevo el código al paquete principal solo para "compartir".
El costo de los subpaquetes es que debe modificar la estructura del directorio y las rutas de salto. La división de proyectos antiguos puede ser un trabajo considerable, por eso vale la pena hacer primero el siguiente paso -- a menudo, después de hacerlo, el paquete principal ya vuelve a estar por debajo de los 2 MB.
Método 3: Reducir el tamaño de las imágenes (cambios mínimos, beneficio directo)
Las imágenes son la parte más fácil de "tener mucho peso innecesario" en el paquete principal. Los PNG exportados por los diseñadores traen bloques de datos extraños, y los JPG usan parámetros de calidad más altos; estos bytes no se ven para el usuario, pero cada uno cuenta para los 2 MB.
¿Qué imágenes deben mantenerse en el paquete
No todas las imágenes se pueden mover a un CDN:
- Iconos tabBar:
iconPath/selectedIconPathsolo pueden ser rutas locales, no admiten imágenes de red. - Página de inicio, Logo de pantalla principal, imágenes de respaldo: deben poder mostrarse incluso en redes débiles o sin conexión.
- Iconos pequeños que aparecen con frecuencia: no tiene sentido hacer una solicitud de red cada vez.
Estas imágenes solo se pueden mantener en el paquete, por lo que el único método es hacerlas más pequeñas.
Evitar un truco común: imágenes de fondo en wxss
Al usar background-image en .wxss para hacer referencia a una imagen local, esto no funciona en dispositivos reales, y el truco común es convertirlas a base64 incrustadas. Pero la codificación base64 hará que el volumen se influya aproximadamente en un tercio, y está oculta en el archivo de estilo, por lo que no es muy visible en el análisis de dependencias. Si se puede cambiar a un componente <image> o a una imagen de red, no lo incruste; si es absolutamente necesario incrustarlo, primero reduzca el tamaño de la imagen original y luego conviértala.
Usar ImgZilla para comprimir todo el directorio de recursos in situ
Lo que más temen hacer los Mini Programas es tener que volver a cambiar las rutas después de comprimir las imágenes -- en wxml, en wxss, en la configuración de JS, en la configuración de tabBar, hay referencias a /images/xxx.png por todas partes. Muchas herramientas de compresión guardan como xxx-min.png o requieren que las exporte a otra carpeta, y después de la compresión debe reemplazarlas manualmente y verificar si falta alguna.
ImgZilla es una herramienta de compresión de imágenes para macOS que hace compresión in situ:
- El nombre del archivo, la ruta y el formato no cambian.
icon-home.pngsigue siendoicon-home.pngdespués de la compresión, no se necesita cambiar ninguna línea en el código. - Simplemente arrastre todo el directorio. Escaneará recursivamente todos los subdirectorios y saltará automáticamente archivos ocultos y
node_modules. Arrastreimages/,static/o incluso todo el directorio del proyecto, y luego verá el cambio en el volumen del paquete directamente en las herramientas de desarrollo. - Por defecto mueve las imágenes originales a la papelera, si no le gusta alguna, haga clic derecho en "Devolver al origen" para restaurarla. Si el proyecto está en Git, tiene una capa más de seguridad.
- Se ejecuta completamente localmente, sin subir a internet. Los materiales del proyecto de la empresa no salen de su computadora, y no hay límites por cantidad de imágenes o tamaño por imagen en los sitios de compresión en línea.
En cuanto a la calidad, el manejo de diferentes formatos es diferente; aquí está claro:
- PNG: usa oxipng para compresión sin pérdida, sin cambiar un solo píxel. En los Mini Programas, muchas iconos y recortes son PNG, por lo que esto se puede comprimir con confianza.
- SVG: limpia las etiquetas redundantes, también sin pérdida.
- JPG / WebP / GIF, etc.: pertenecen a recodificación con pérdida, los parámetros ya se han ajustado al rango de "sin pérdida visual" -- difícil de notar con el ojo desnudo. No es necesario confiar ciegamente; la ventana de comparación integrada (
⌘D) permite dividir la pantalla, ampliar a píxeles reales y comparar lado a lado.
Dos puntos más también vale la pena saber:
- No forzará la compresión si ya está comprimido al máximo: los archivos con una tasa de compresión inferior al 0,4% se marcarán como "ya mínimo" y se mantendrán como están, no arruinarán la imagen solo para que el número se vea mejor. Así que si sus imágenes ya han sido optimizadas seriamente, este paso podría no ahorrar mucho -- lo cual es normal, y también indica que debería pasar a usar subpaquetes.
- No cambia el formato ni la resolución. PNG sigue siendo PNG después de la compresión, las dimensiones no cambian. Si desea cambiar la imagen a WebP o reducir una imagen de 3x a 2x, eso es otra cosa que requiere un manejo separado.
Cuánto se puede ahorrar depende de cómo se exportaron originalmente las imágenes, no daremos un porcentaje general. Como referencia, hicimos dos pruebas públicas: un lote de JPG que ya había sido comprimido una vez al registrar el sitio web, comprimir de nuevo ahorró 46,8%; un lote de JPG directamente de la cámara ahorró 76,8% (ver la serie "Pruebas de ImgZilla"). Las imágenes en los Mini Programas suelen ser exportadas directamente desde herramientas de diseño, generalmente no han sido comprimidas seriamente, por lo que vale la pena ejecutar una vez para ver.
Actualmente, ImgZilla solo está disponible para macOS (macOS 12.3 o superior), se puede descargar desde la Mac App Store, y se puede comprimir 10 imágenes gratis por día. Para los estudiantes que desarrollan con Windows, el pensamiento de esta sección también se aplica, solo cambie a una herramienta que también pueda "mantener el nombre del archivo original".
Método 4: Mover imágenes grandes a un CDN
Después de reducir el tamaño, si todavía son muy grandes -- como banners de actividades, imágenes largas de páginas de detalles, grandes imágenes de productos -- no deberían haber estado en el paquete en primer lugar. Cárguelos en almacenamiento de objetos o CDN, y cambie las direcciones a URLs de red en el código, el paquete principal se aligerará inmediatamente.
Pero no es gratuito:
- La primera carga debe pasar por la red, habrá un período de tiempo en blanco en redes débiles, lo mejor es combinarlo con una imagen de marcador de posición o una pantalla esquelética.
- Debe mantener un conjunto de procesos de carga, caché y actualización.
- El CDN se cobra por tráfico. Cada vez que se carga una imagen se gasta dinero, la tarifa de tráfico es aproximadamente "tamaño de la imagen × veces de acceso". Por lo tanto, antes de moverlo al CDN, también vale la pena comprimir las imágenes primero -- comprimir una vez, y cada vez que se accede se ahorra tráfico.
Método 5: Rematado a nivel de código
Después de procesar las imágenes y la estructura, el espacio residual se puede extraer del código:
- En las herramientas de desarrollo "Detalles → Configuración local" marque la compresión de scripts, estilos y WXML al subir.
- En
app., active"lazyCodeLoading": "requiredComponents"(inyección bajo demanda). Principalmente mejora la velocidad de inicio en lugar del volumen del paquete, pero dado que se está haciendo una optimización de rendimiento, también actívelo. - Verifique
miniprogram_npm: si el paquete npm construido tiene una introducción completa pero solo se usan una o dos funciones. - Los grandes datos estáticos escritos directamente en JS (listas de ciudades, tablas de configuración) considere cambiarlos para que se entreguen a través de la interfaz.
Una tabla para resumir
| Método | Cuánto se puede ahorrar | Cuánto hay que cambiar | Orden sugerido |
|---|---|---|---|
| Eliminar archivos inútiles | Depende de la "herencia" del proyecto | Poco | 1 |
| Compresión in situ de imágenes | Cuantas más imágenes, más descuidadas al exportar, más se ahorra | Casi cero, las rutas no cambian | 2 |
| Subpaquetes | Puede ser mucho | Directorios y rutas deben moverse | 3 |
| Mover imágenes grandes a CDN | Mucho | Cambiar referencias, mantener procesos de carga | 4 |
| Compresión de código e introducción bajo demanda | Poco | Depende del caso | 5 |
La lógica del orden es simple: haga primero los cambios pequeños, luego los cambios grandes. Eliminar archivos y comprimir imágenes casi no tocan el código de negocio; después de hacerlo, verifique cuánto falta en el paquete principal -- si ya está por debajo de los 2 MB, la versión de hoy se puede publicar; si no es suficiente, luego mueva subpaquetes y CDN, y tendrá claro en su mente.
El límite del paquete principal a menudo ocurre justo antes del lanzamiento, en el momento más estresante. Ponga la compresión de imágenes en el flujo diario -- comprima una vez antes de agregar cada nueva imagen -- la próxima vez no tendrá que preocuparse frente a esa línea de texto rojo en la fecha límite.