Page Size Checker

Pega cualquier URL en el campo URL de página de arriba y presiona verificar. El verificador de tamaño de página obtiene la URL, lee los encabezados de respuesta y devuelve el tamaño del documento HTML sin procesar, el tamaño de la red gzip o brotli, el tiempo de respuesta en milisegundos, los valores Content-Encoding y Cache-Control, y un recuento de cada CSS externo, JS, imagen, fuente e iframe declarado. Estima el peso total de la página utilizando medianas de Web Almanac 2024 (2,4 MB mediana, 5 MB en p75) y marca si te encuentras en ligero, promedio o hinchado. Chrome DevTools muestra los mismos números en la pestaña Network, pero tienes que cargar la página, limpiar caché, recarga forzada y leer entre varios paneles. Esta herramienta da la misma respuesta en dos segundos contra cualquier URL pública.

El tamaño de la página es la suma de cada byte que el navegador descarga para representar la página: el documento HTML más cada archivo CSS, archivo JS, imagen, fuente, video e iframe activo. El número más útil es el tamaño de la red comprimida, ya que es lo que cruza la red. Para calcular manualmente, abre Chrome DevTools, cambia a Network, recarga forzada con caché deshabilitado y lee la barra inferior donde Chrome imprime solicitudes y bytes totales transferidos. El verificador anterior hace la misma aritmética para el documento HTML directamente y estima el peso total desde activos declarados utilizando medianas de Web Almanac 2024, por lo que no tienes que esperar a que terminen todos los sub-recursos.

Usa el campo de arriba. Coloca la URL en URL de página, presiona verificar y lee la tarjeta de respuesta. El verificador informa bytes del documento HTML, bytes de la red gzip, tiempo de respuesta, codificación, encabezados de caché e inventario de solicitudes de activos por tipo. Compara el total estimado contra medianas de Web Almanac 2024 y etiqueta la página en verde, ámbar o rojo. Para una auditoría de representación más profunda, ejecuta google-crawler-simulator que ejecuta JavaScript y muestra el DOM post-representación, luego ejecuta alt-text-checker en el inventario de imágenes. La combinación te dice exactamente qué activos comprimir, diferir o eliminar primero.

Apunta a menos de 1,5 MB de peso total en páginas de destino y conversión. Web Almanac 2024 midió la página mediana a 2,4 MB y el p75 a 5 MB, con el p90 superior a 9 MB. Las páginas menores a 1 MB pasan el umbral de LCP de 2,5 segundos el 82% de las veces en 4G móvil. Las páginas superiores a 3 MB lo pasan solo el 38% de las veces. Dentro del presupuesto, mantén HTML bajo 100 KB comprimido, JS bajo 300 KB comprimido, CSS bajo 60 KB comprimido y la imagen individual más grande bajo 200 KB. El verificador marca páginas que exceden esos umbrales. Vuelve a verificar después de cada despliegue porque los scripts de terceros y los complementos CMS routinariamente añaden peso sin que nadie se dé cuenta.

LCP mide cuánto tiempo tarda el elemento visible más grande en representarse. En la mayoría de las páginas ese elemento es una imagen hero, un marco de video de banner o un bloque de encabezado grande. Las páginas pesadas retrasan LCP porque CSS y JS de bloqueo de representación en el head empujan la pintura más tarde, la imagen LCP en sí a menudo está sin optimizar, y la contención de red priva la solicitud de LCP del ancho de banda. El umbral de Google es 2,5 segundos. Los datos del HTTP Archive 2024 muestran que las páginas superiores a 3 MB lo pierden el 62% de las veces en móvil. Corrige LCP precargando la imagen hero, sirviéndola como AVIF o WebP, diferiendo JS no crítico con defer o async y recortando CSS crítico. Vuelve a ejecutar el verificador después de cada cambio.

Ambas son algoritmos de compresión de texto aplicados en la capa HTTP. Gzip ha sido el estándar web desde los años 90 y es compatible con todos los navegadores. Brotli fue lanzado por Google en 2015 y se envía en el 96% de los navegadores a partir de 2026. Brotli comprime texto 15-25% más pequeño que gzip en promedio para HTML, CSS y JS, con la brecha más amplia en markup altamente repetitivo. La mayoría de los CDN (Cloudflare, Fastly, CloudFront) habilitan brotli por defecto para texto estático y retroceden a gzip para clientes más antiguos. El verificador informa el Content-Encoding actual que devolvió tu servidor. Si muestra gzip o vacío, cambia tu CDN a brotli para una caída inmediata de 15-25% en peso de texto sin cambios de código.

Aborda primero las categorías más pesadas. Las imágenes son generalmente el elemento de línea más grande: convierte fotos hero a AVIF con respaldo WebP (AVIF promedian 50% más pequeño que JPEG a la misma calidad), cambia el tamaño a dimensiones de visualización reales y carga de forma diferida cualquier cosa debajo del pliegue con loading="lazy". JavaScript es lo siguiente: divide el código por ruta, diferencia scripts de terceros hasta después de la primera pintura y elimina dependencias sin usar. CSS: purga selectores sin usar con PurgeCSS o Tailwind's JIT, incrustra CSS crítico en el head y carga el resto de forma asincrónica. Fuentes: haz un subconjunto de los glifos que usas y aloja automáticamente con font-display: swap. Una auditoría de hinchazón típica reduce el peso total 40-60% en el primer paso.

Sí, severamente. En una conexión 4G rápida (12 Mbps), una página de 5 MB tarda aproximadamente 3,5 segundos en descargar antes de que comience la representación. En una conexión 3G lenta (1,6 Mbps), la misma página tarda 25 segundos. Google's Lighthouse simula un perfil "Slow 4G" precisamente porque las redes móviles del mundo real son más lentas que lo que sugiere el marketing de los operadores. Web Almanac 2024 encontró que el 53% de los usuarios móviles abandonan páginas que tardan más de 3 segundos en cargarse. Las páginas pesadas también agotan los planes de datos medidos en una única visita. Apunta a menos de 1 MB en plantillas mobile-first y empareja el verificador con google-crawler-simulator para confirmar que el bot móvil ve la misma carga ligera.

Usa AVIF como formato principal con respaldo WebP para el 4% de navegadores que carecen de soporte AVIF. AVIF comprime fotos 50% más pequeño que JPEG a calidad visual equivalente y 20-30% más pequeño que WebP. Para un hero JPEG de 400 KB, la versión AVIF típicamente pesa 90-130 KB. Usa el elemento <picture> con <source type="image/avif"> y <source type="image/webp"> luego un respaldo JPEG <img>. Para iconos y gráficos simples, usa SVG: se escala infinitamente, pesa menos de 5 KB para la mayoría de iconos y se comprime bien con brotli. Evita PNG excepto para capturas de pantalla que necesiten transparencia sin pérdida. Reemplaza GIF con un MP4 o WebM de reproducción automática silenciado, que pesa 90% menos.

Sí. Un peso completo de fuente de Google Fonts o Adobe Fonts a menudo pesa 80-120 KB porque incluye cada glifo latino, cirílico, griego y vietnamita más el conjunto de puntuación completo. La mayoría de los sitios usan solo Latin básico. Hacer un subconjunto lo reduce a 18-25 KB, un ahorro del 75-85% por fuente. Herramientas como glyphhanger o Fontsource manejan el subconjunto automáticamente. Aloja automáticamente el archivo del subconjunto con font-display: swap para que el texto se represente inmediatamente en una fuente de respaldo y se repinte cuando se cargue la fuente personalizada. Limita los pesos totales a dos o tres (uno de cuerpo, uno de encabezado, opcionalmente uno de visualización). Cada peso adicional es otros 18-25 KB más una solicitud de bloqueo de representación a menos que se precargue.

Ejecuta una herramienta de purga CSS contra tu compilación de producción. PurgeCSS escanea plantillas de HTML y JS para nombres de clase y elimina cualquier selector en tu CSS que nunca se use. El compilador JIT de Tailwind hace esto automáticamente. Para CSS escrito a mano, marcos como Next.js, Astro y SvelteKit ejecutan un paso de purga en tiempo de compilación. El ahorro suele ser dramático: un sitio Bootstrap que envía el marco completo de 200 KB puede bajar a 8-15 KB después de purgar. Incrustra CSS crítico para contenido por encima del pliegue en el head (típicamente 10-15 KB) y carga el resto con <link rel="stylesheet" media="print" onload="this.media='all'">. Vuelve a verificar con el verificador de tamaño, luego ejecuta h1-checker para confirmar que el HTML más ligero aún tiene una estructura de encabezado válida.

La carga diferida difiere la descarga de activos fuera de pantalla hasta que el usuario se desplaza cerca de ellos. El atributo HTML nativo loading="lazy" funciona en <img> e <iframe> en el 95% de los navegadores y no requiere JavaScript. En una página de artículo largo con 30 imágenes, la carga diferida típicamente difiere 25 de ellas, reduciendo la carga inicial en 60-80% y bajando LCP en 1-2 segundos. Aplícalo a cada imagen e iframe debajo del pliegue, pero nunca a la imagen LCP en sí, ya que cargar de forma diferida el hero retrasa la métrica que estás intentando mejorar. Combina con conversión de formato de imagen (AVIF o WebP) para ganancias compuestas. El verificador marca páginas con recuentos de imágenes altos; si ves 40+ imágenes en una sola página, la carga diferida es tu mayor ganancia disponible.

El tamaño del documento HTML son los bytes de la respuesta HTML en sí: el markup que el servidor devolvió antes de que el navegador obtuviera cualquier sub-recurso. El peso total de la página es la suma del documento HTML más cada archivo CSS, archivo JS, imagen, fuente, video e iframe que carga la página. Una página puede tener un documento HTML de 8 KB y un peso total de 6 MB si carga imágenes pesadas y scripts. O puede tener un documento de 250 KB lleno de contenido integrado y un total de 400 KB. El verificador informa el tamaño del documento HTML directamente desde la respuesta y estima el peso total desde el recuento de activos declarados utilizando medianas de Web Almanac 2024. El número del documento HTML importa más para presupuesto de rastreo; el peso total importa más para LCP.

Los encabezados de control de caché le dicen al navegador cuánto tiempo guardar un activo antes de solicitarlo nuevamente. Un encabezado de cache-control: public, max-age=31536000, immutable le dice al navegador que mantenga el archivo durante un año y nunca revalide. Los visitantes repetidos descargan cero bytes para ese activo. El verificador informa el valor Cache-Control en la respuesta HTML para que puedas verificar tu configuración de CDN. El HTML en sí generalmente debe estar en caché corto (300-600 segundos) ya que el contenido se actualiza frecuentemente. Los activos estáticos (JS, CSS, fuentes, imágenes) con nombres de archivo con hash deben almacenarse en caché un año porque un cambio de contenido crea un nuevo nombre de archivo. Sin almacenamiento en caché adecuado, cada carga de página es una carga fría.

Content-Encoding es el encabezado de respuesta HTTP que le dice al navegador cómo se comprimió el cuerpo. Los valores comunes son gzip, br (brotli), deflate, zstd o vacío (sin comprimir). El verificador informa lo que sea que devolvió tu servidor. Si muestra gzip en una respuesta de texto, estás ahorrando 70-80% del ancho de banda versus sin comprimir. Si muestra br, ahorras un 15-25% adicional en la parte superior de gzip. Si está vacío en una respuesta HTML, CSS o JS superior a 5 KB, tu servidor o CDN está mal configurado y cada visitante paga el peso completo sin comprimir. Los formatos binarios (JPEG, PNG, WebP, AVIF, MP4) ya están comprimidos a nivel de formato y típicamente devuelven Content-Encoding vacío.