Publica un juego web que cargue rápido (una lista de comprobación práctica)

Si los jugadores no pueden empezar a jugar en cuestión de segundos, se marchan. Este tutorial es una lista de comprobación práctica que puedes aplicar a casi cualquier stack para juegos web (Canvas/WebGL/WebGPU, Pixi/Three/PlayCanvas, motor propio, etc.).

1) Define primero los límites (o no podrás optimizar)

Elige límites que se ajusten a tu dispositivo objetivo. Un buen punto de partida para una experiencia de «juego instantáneo»:

• JS+CSS enviados: menos de ~300–500 KB con gzip (cuanto menos, mejor)
• Recursos críticos antes de la primera interacción: menos de ~2–5 MB comprimidos
• Tiempo hasta la primera interacción: menos de ~3–5 segundos en un móvil de gama media

Anótalos y trátalos como contratos de API.

2) Mide lo que importa

En Chrome DevTools:

• Usa Performance para capturar una sesión e inspeccionar las tareas largas.
• Usa Network para comprobar:
  • el tamaño transferido frente al tamaño descomprimido
  • las cabeceras de caché
  • si los recursos se transmiten progresivamente o llegan como un único bloque enorme

En términos del juego, registra:

• El tiempo hasta que «el jugador puede moverse»
• El tiempo hasta el «primer fotograma significativo»
• La «latencia de la primera interacción» (entrada → fotograma)

Tu concepto de «latencia de la primera interacción» ahora se corresponde con una métrica estándar: Interaction to Next Paint (INP) sustituyó a First Input Delay como Core Web Vital en marzo de 2024 y mide el tiempo completo desde la entrada hasta el siguiente repintado en todas las interacciones, no solo en la primera. Intenta mantener el INP por debajo de 200 ms en el percentil 75, un punto de referencia externo útil para las cifras de capacidad de respuesta que ya registras.

3) Comprime todo lo que puedas

Asegúrate de que tu alojamiento sirva:

• Brotli (br) para recursos de texto (JS/CSS/HTML/WASM) cuando esté disponible
• gzip como alternativa

Si tu proveedor de alojamiento y CDN lo permiten, Zstandard (zstd) es ahora una tercera opción para Content-Encoding. Está disponible en Chrome y Edge 123+, Firefox 126+ y Safari 26.3+ (aproximadamente el 80 % de los usuarios), y puede alcanzar relaciones de compresión similares a las de Brotli con un menor coste de CPU en el servidor, lo que resulta útil para cargas grandes de WASM y JSON. Los navegadores solo anuncian Accept-Encoding: zstd mediante HTTPS, así que mantén Brotli y gzip configurados como alternativas para todos los demás.

En las compilaciones de WebAssembly, la compresión suele marcar la diferencia entre una carga «instantánea» y una que «nunca termina».

4) No descargues todo el mundo por adelantado

Divide tu juego en:

• Arranque: cargador mínimo + entrada + primera escena
• Núcleo: sistemas principales de juego
• Opcional: niveles adicionales, elementos cosméticos, texturas de alta resolución, audio adicional, etc.

Carga el contenido «Opcional» solo después de que:

• el jugador ya pueda jugar, o
• sepas que quiere ese contenido (por ejemplo, porque ha llegado a un menú o nivel)

5) Elige los formatos de recursos adecuados

Para la mayoría de los juegos web:

• Imágenes: prioriza WebP (o AVIF si puedes aceptar una codificación más lenta) para interfaces y fondos.
• Audio: prioriza Ogg Vorbis para uso general; prueba AAC para los ecosistemas de Apple.
• Vídeo: prioriza MP4/H.264 por compatibilidad y WebM cuando sea compatible y ocupe menos.

Ten en cuenta el coste de decodificación: una «descarga más pequeña» puede seguir siendo «más lenta de decodificar».

6) Mantén tu primera escena pequeña y determinista

Evita lo siguiente en tu primera escena interactiva:

• avalanchas de compilación de shaders
• cargas de texturas enormes
• generación procedural que bloquee el hilo principal
• análisis síncrono de bloques JSON de varios megabytes

En concreto para las texturas, distribuye KTX2 con la supercompresión Basis Universal en lugar de PNG o JPEG. Permanece comprimido en la GPU después de cargarse (se transcodifica a BC7 en ordenadores de escritorio o a ASTC en móviles durante la carga), lo que reduce la VRAM entre 4 y 8 veces y hace que las cargas sean mucho menos costosas que decodificar un PNG a tamaño completo y enviar los píxeles sin comprimir a la GPU.

Si tienes que realizar tareas pesadas, hazlo:

• de forma incremental a lo largo de varios fotogramas, o
• en un Worker (cuando sea posible)

7) Usa la caché de forma agresiva (pero correcta)

Usa una caché de larga duración para los recursos identificados por contenido:

• Cache-Control: public, max-age=31536000, immutable

Para los puntos de entrada HTML, usa una caché de corta duración para poder desplegar actualizaciones de forma segura.

8) Haz que los «fallos» sean rápidos y comprensibles

Si algo sale mal, muestra:

• un mensaje de error claro
• un botón para volver a intentarlo
• un enlace para informar del problema

Los fallos silenciosos destruyen la confianza.

9) Si usas hilos de Wasm, comprende COOP/COEP

Si tu compilación depende de SharedArrayBuffer (algo habitual en algunas configuraciones de hilos de Wasm), probablemente necesitarás cabeceras de aislamiento entre orígenes:

• Cross-Origin-Opener-Policy: same-origin
• Cross-Origin-Embedder-Policy: require-corp

Tienes dos opciones para la cabecera COEP. require-corp es la opción estricta, pero implica que cada recurso de origen cruzado (texturas de CDN, scripts de terceros) debe enviar una cabecera Cross-Origin-Resource-Policy o será bloqueado. Cross-Origin-Embedder-Policy: credentialless también habilita SharedArrayBuffer y el aislamiento entre orígenes, pero carga los recursos de origen cruzado sin credenciales en lugar de exigirles que den su consentimiento mediante CORP. Si obtienes recursos de una CDN que no controlas, credentialless suele ser la opción menos problemática.

Haz pruebas cuanto antes en tu alojamiento real, porque las cabeceras y las integraciones de terceros pueden causar problemas.

10) Haz que se pueda jugar sin un SDK

Si tu objetivo es el flujo de trabajo para creadores de Cinevva, procura ofrecer:

• una única URL que arranque de forma fiable
• ningún inicio de sesión obligatorio para comenzar una demo
• controles de entrada predecibles

Así estarás listo para distribuir tu juego sin integrar SDK adicionales.

Contenido relacionado:

• Para creadores de juegos
• Política sobre contenido generado por IA
• Carga de recursos en streaming — patrones de carga progresiva para juegos grandes
• Service workers para almacenar juegos en caché — almacena recursos en caché para que las visitas posteriores carguen al instante
• Comparativa de motores para juegos web — tamaños de compilación y tiempos de carga entre distintos motores
• Cómo publicar tu juego en itch.io — optimización de juegos para navegador integrados en itch.io