Informe «Técnico»

El Informe «Técnico» no sigue las métricas de usuario, sino los indicadores técnicos, como el volumen de datos o el número de solicitudes.

Tomamos todas las URLs que introduces a través de configuración de la prueba y diariamente tomamos la mediana de las pruebas y te mostramos estos datos.

Un pequeño desvío ocasional no es preocupante, pero si empeora y no se recupera, merece una reflexión.

No consideramos los indicadores técnicos como las métricas principales, pero te ayudan a encontrar las causas de los problemas con las métricas de usuario Core Web Vitals, que te reporta el Vigilante o que ves en los datos de Google (Chrome UX Report) en el informe de Dominios o Páginas.

🔐 El Informe «Técnico» es una funcionalidad disponible solo en pruebas PLUS.

¿Por qué es importante medir los indicadores técnicos en la velocidad del sitio?#

El moderno campo de optimización de la velocidad del sitio ya no sigue estos indicadores técnicos como métricas primarias.

Nuestro asesoramiento en velocidad web nos ha enseñado que incluso sitios que descargan grandes volúmenes de datos pueden ser rápidos para el usuario gracias a una buena optimización de las primeras visualizaciones.

Aun así, en nuestro «Técnico», que precisamente sigue estos indicadores secundarios. El volumen de datos, el número de solicitudes y otras métricas merecen ser vistas por otras razones:

• Son útiles para encontrar correlaciones entre cambios en las métricas de usuario (p.ej., LCP, CLS, INP) y cambios en el desarrollo del sitio (p.ej., volumen de datos de imágenes o el tamaño de JavaScript bloqueante).
• Consideramos que ahorrar en el volumen de datos es un gesto de respeto hacia los usuarios, quienes podrían tener recursos limitados para descargar datos en el móvil.
• A menudo, cuanto menos datos se transferen, más ahorro en infraestructura se logra para el operador del sitio.

En las pruebas PLUS, verás el informe «Técnico» para todos los tipos de páginas que incluyas en la configuración de la prueba.

A partir del gráfico a continuación, se puede ver tanto el estado actual de la métrica como su evolución en el tiempo. Especialmente para móvil y para escritorio.

Basándonos en nuestra experiencia de consultoría, hemos añadido esta información y reportes al informe «Técnico»:

Volumen de datos HTML#

El gráfico muestra la evolución del volumen de datos HTML para cada página. Se trata del estado en el que el HTML llegó al navegador de prueba, por lo tanto, ya después de la compresión Gzip o Brotli. Cuanto menor sea el tamaño de los datos HTML, mejor.

Recomendamos un tamaño de hasta 20 kB. Esto influye en métricas de carga como FCP o LCP.

Número de nodos DOM#

Evolución del número de nodos DOM para cada página a lo largo del tiempo. Un árbol DOM complejo complica el trabajo del JavaScript, por lo que puede afectar métricas como TBT o INP.

Recomendamos un máximo de 1,500 nodos DOM por página, lo cual a veces es un objetivo ambicioso, pero es importante aspirar a ello.

Volumen de datos CSS#

Evolución del volumen de datos de los archivos CSS para cada página a lo largo del tiempo. Se trata del estado tras la compresión Gzip o Brotli en su servidor. CSS suele ser una fuente que bloquea la primera renderización y su tamaño tiene, por lo tanto, un impacto en métricas como FCP o LCP. Idealmente, mantenga el volumen de datos CSS por debajo de 50 kB.

Número de JS bloqueantes#

Evolución del número de archivos JS que bloquean la primera renderización. JavaScript no tiene que ser bloqueante, a diferencia de CSS.

Cuantos menos JS bloqueantes tenga, mejor para métricas como FCP o LCP.

Volumen de datos JS#

Evolución del volumen de datos de los archivos JS para cada página a lo largo del tiempo. Aquí se incluyen tanto los archivos que bloquean la primera renderización como los que no. El gráfico muestra el estado tras la compresión Gzip o Brotli en su servidor.

Cuanto más pequeño sea el JS, menos código habrá que procesar y ejecutar por el navegador. Esto influye en métricas de interacción como TBT o INP. El JS bloqueante también afecta a FCP y LCP, por lo tanto, a la primera renderización.

Volumen de datos JS de terceros#

Evolución del volumen de datos de los archivos JavaScript de terceros para cada página a lo largo del tiempo. Esta categoría incluye JS que se ejecuta fuera de su dominio principal, por lo que puede encontrar aquí también sus propios archivos ubicados fuera del dominio principal.

Aquí suele encontrarse el volumen de datos de código ajeno para componentes como herramientas de análisis, chats, pruebas A/B, publicidad, etc.

Este código también afecta métricas de interacción como TBT o INP. Por eso es importante mantenerlo lo más pequeño posible.

Volumen de datos de fuentes#

Evolución del volumen de datos de las fuentes para cada página a lo largo del tiempo. Las fuentes suelen ser un recurso necesario para renderizar el contenido y, por lo tanto, tienen un impacto en la métrica LCP.

Recomendamos mantener su volumen de datos por debajo de 50 kB.

Volumen de datos de imágenes#

Evolución del volumen de datos de las imágenes para cada página a lo largo del tiempo. Las imágenes suelen ser un recurso necesario para renderizar el contenido y, por lo tanto, pueden tener un impacto en la métrica LCP.

Recomendamos mantener su volumen de datos por debajo de 100 kB por página.

Volumen total de datos#

Evolución del volumen de datos de todos los archivos descargados para cada página a lo largo del tiempo. El volumen total de datos no tiene que afectar a las métricas y la experiencia del usuario, pero aun así recomendamos mantenerlo por debajo de 0,5 MB por página.

El seguimiento de los indicadores técnicos puede ser muy útil cuando decides enfocarte en alguna de las métricas mencionadas anteriormente o en algún tipo de página en particular.

¿Qué hacer si ves un empeoramiento en alguno de los indicadores técnicos?#

En primer lugar, digamos que no siempre tiene que ser un problema mayor. Asegúrate de si ves el mismo impacto en las métricas de usuario en el mismo período de tiempo (ver informes Vigilante, Páginas o Dominios).

A veces, el empeoramiento no estará bajo tu control, por ejemplo, en el caso de componentes de terceros. Aun así, vale la pena prestar atención a las terceras partes.

La mejora de los indicadores técnicos siempre es una buena noticia.

En el detalle de ejecución de la prueba de Lighthouse, puedes ver un contexto aún más amplio.

¿Aún ves un problema en el informe Técnico de tu lado y al mismo tiempo un empeoramiento que afecta a Core Web Vitals, es decir, ves un empeoramiento en los informes Vigilante o Dominios?

1. Encuentra el cambio específico en los gráficos. ¿A qué tipo de páginas se refiere? ¿Es el mismo para móvil y escritorio?
2. Al hacer clic en un valor específico en el gráfico, accedes a la prueba de Lighthouse, que te mostrará la medición específica del valor junto con otro contexto.
3. Pregunta a los desarrolladores, mercadólogos y otros miembros del equipo qué cambió en el período específico.

Nuestro artículo Cómo probamos y el Detalle de ejecución de la prueba con el monitoreo de PageSpeed.ONE ofrecen una guía completa.