Vea la carga de su sitio a través de los ojos de su visitante
Obtenga una buena idea de lo que sus visitantes experimentan realmente cuando visitan su sitio web.
¿Notas algo cargando lentamente o fuera de lugar? Esto puede ayudarlo a identificar retrasos importantes y problemas de conversión que experimentan sus visitantes.
Captura de pantalla que muestra el resultado de una prueba de rendimiento web de DebugBear, octubre de 2022 La tira de película de la línea de tiempo muestra el progreso de renderizado del sitio web a lo largo del tiempo.
Por ejemplo, esta página comienza a mostrarse después de 0,7 segundos y la imagen principal se muestra después de 1,3 segundos.
El sitio web está completamente renderizado, también conocido como Visualmente completo, cuando el widget de chat se muestra después de 3,7 segundos.
Captura de pantalla de DebugBear que muestra el progreso de representación de un sitio web a lo largo del tiempo, octubre de 2022 Dentro de la herramienta, también puede ver una grabación de video del proceso de renderizado.
Esta es una excelente manera de demostrar el impacto de los problemas de rendimiento a los clientes u otros miembros de su equipo.
Captura de pantalla que muestra una grabación de video de un sitio web parcialmente renderizado en DebugBear, octubre de 2022 Pruebe los cambios de velocidad del sitio al ver sus estadísticas de carga reales
Supongamos que ha estado optimizando su sitio web y quiere saber si esos cambios tendrán un impacto.
Esta herramienta ejecuta una "prueba de laboratorio" en un entorno óptimo para descubrir si está optimizando su sitio correctamente.
Cuando pruebe su sitio, obtendrá una "Puntuación de laboratorio" oficial, que es un resumen de seis métricas de rendimiento que provienen de la puntuación de rendimiento de la herramienta Lighthouse de Google:
- Primera pintura con contenido (10% de la puntuación general).
- Índice de velocidad (10%).
- Mayor pintura con contenido (25%).
- Tiempo para Interactivo (10%).
- Tiempo total de bloqueo (30%).
- Cambio de diseño acumulativo (15%).
Con estos datos, descubrirá cuán útil fue su última ronda de optimizaciones y qué es posible que deba cambiar.
A estas alturas, probablemente te estés preguntando qué necesitas cambiar. Aprendamos cómo optimizar su sitio usando cada métrica clave de la Descripción general de métricas.
Cómo optimizar la velocidad del sitio web
Ejecutar una prueba de velocidad es la primera parte del viaje de optimización de su sitio web.
Una vez que tenga sus métricas, necesitará saber cómo interpretarlas y qué hacer para corregirlas.
En el área Resumen de métricas del informe de velocidad de su sitio web, verá las métricas clave en las que nos centraremos para ayudarlo a acelerar su sitio:
- Primera pintura con contenido: esto se puede acelerar reparando la velocidad de comunicación del servidor.
- Pintura con contenido más grande : esto se puede acelerar optimizando los medios y los recursos.
Además, puede usar la cascada de solicitudes para ver cuánto tardan las solicitudes y cómo afecta eso a esas métricas.
Cómo acelerar la primera pintura con contenido (FCP)
Comencemos por hacer que su sitio web se muestre antes a sus visitantes; abordaremos First Contentful Paint, primero.
¿Qué es la primera pintura con contenido?
First Contentful Paint mide qué tan pronto comienza a aparecer el contenido de una página después de que su visitante navega a esa página.
Es importante que su contenido clave aparezca rápidamente para evitar que su visitante abandone su sitio web. Cuanto más rápido un usuario abandona su sitio web, más rápido aprende Google que la experiencia de la página puede ser mala.
Pero, ¿cómo sabe exactamente qué está causando que su sitio web se cargue lentamente?
¿Cómo descubre qué problemas del servidor están ralentizando su sitio web? Vamos a averiguar.
¿Por qué mi primera pintura con contenido tarda tanto?
Su FCP puede verse afectado por la velocidad de conexión del servidor, las solicitudes del servidor, los recursos de bloqueo de procesamiento y más.
Parece mucho, pero hay una manera fácil de ver exactamente qué está ralentizando su FCP : la cascada de solicitudes.
Esta útil herramienta muestra qué solicitudes realiza su sitio web y cuándo comienza y finaliza cada solicitud.
Por ejemplo, en esta captura de pantalla, primero vemos una solicitud del documento HTML y luego dos solicitudes para cargar las hojas de estilo a las que se hace referencia en el documento.
Captura de pantalla que muestra datos de depuración para la métrica First Contentful Paint en DebugBear, octubre de 2022 ¿Por qué ocurre la primera pintura con contenido después de 0,6 segundos? Podemos desglosar lo que está sucediendo en la página para entender esto.
Comprender lo que sucede antes de una primera pintura con contenido
Antes de que las primeras piezas de contenido puedan cargarse en su página web, el navegador de su usuario primero debe conectarse a su servidor y recuperar el contenido.
Si este proceso lleva mucho tiempo, el usuario tardará mucho en ver su sitio web.
Su objetivo es saber qué está pasando antes de que su sitio web comience a cargarse para que pueda identificar problemas y acelerar la experiencia.
Carga de página, parte 1: el navegador crea una conexión de servidor
Antes de solicitar por primera vez un sitio web desde un servidor, el navegador de su visitante necesita establecer una conexión de red con ese servidor.
Esto normalmente toma tres pasos:
- Comprobación de registros DNS para buscar la dirección IP del servidor en función del nombre de dominio.
- Establecer una conexión de servidor confiable (conocida como conexión TCP).
- Establecer una conexión de servidor segura (conocida como conexión SSL).
Estos tres pasos los realiza el navegador, uno tras otro. Cada paso requiere un viaje de ida y vuelta desde el navegador de su visitante hasta el servidor de su sitio web.
En este caso, se tarda alrededor de 251 milisegundos en establecer la conexión con el servidor.
Captura de pantalla de DebugBear que muestra los viajes de ida y vuelta de la red utilizados para establecer una conexión de servidor, octubre de 2022 Parte 2 de carga de la página: el navegador solicita el documento HTML (el tiempo hasta el primer byte ocurre aquí)
Una vez que se establece la conexión con el servidor, el navegador de su visitante puede solicitar el código HTML que contiene el contenido de su sitio web. Esto se llama una solicitud HTTP.
En este caso, la solicitud HTTP tarda 102 milisegundos. Esta duración incluye tanto el tiempo invertido en el viaje de ida y vuelta de la red como el tiempo invertido en esperar a que el servidor genere una respuesta.
Después de 251 milisegundos para crear la conexión y 102 milisegundos para realizar la solicitud HTTP, el navegador de su visitante finalmente puede comenzar a descargar la respuesta HTML.
Este hito se denomina Tiempo hasta el primer byte (TTFB). En este caso, eso sucede después de un total de 353 milisegundos.
Una vez que la respuesta del servidor está lista, el navegador de su visitante dedica un tiempo adicional a descargar el código HTML. En este caso, la respuesta es bastante pequeña y la descarga solo toma 10 milisegundos adicionales.
Captura de pantalla de DebugBear que muestra los diferentes componentes de una solicitud HTTP, octubre de 2022 Carga de la página, parte 3: su sitio web carga recursos adicionales que bloquean el renderizado
Los navegadores no procesan ni muestran las páginas inmediatamente después de cargar el documento. En cambio, generalmente hay recursos adicionales de bloqueo de procesamiento.
La mayoría de las páginas se verían mal sin ningún estilo visual, por lo que las hojas de estilo CSS se cargan antes de que la página comience a mostrarse.
Cargar las 2 hojas de estilo adicionales en este ejemplo de prueba de velocidad de sitio web lleva 137 milisegundos.
Tenga en cuenta que estas solicitudes no requieren una nueva conexión al servidor. Los archivos CSS se cargan desde el mismo dominio que antes y pueden reutilizar la conexión existente.
Captura de pantalla de DebugBear que muestra la carga de recursos adicionales de bloqueo de procesamiento después del documento HTML, octubre de 2022 Carga de página Parte 4: el navegador muestra la página
Finalmente, una vez que se hayan cargado todos los recursos necesarios, el navegador de su visitante puede comenzar a mostrar la página. Sin embargo, hacer este trabajo también requiere una cierta cantidad de tiempo de procesamiento, en este caso, 66 milisegundos. Esto se indica mediante el marcador naranja de tareas de la CPU en la vista en cascada.
Captura de pantalla de DebugBear que muestra los pasos que van desde la carga del documento HTML hasta la representación de la página web, octubre de 2022 Ahora entendemos por qué ocurre el FCP después de 632 milisegundos:
- 364 milisegundos para la solicitud de documento HTML.
- 137 milisegundos para cargar las hojas de estilo.
- 66 milisegundos para renderizar la página.
- 65 milisegundos para otros trabajos de procesamiento.
El otro trabajo de procesamiento incluye trabajos pequeños como ejecutar scripts en línea o analizar el código HTML y CSS una vez que se descarga. Puede ver esta actividad como pequeñas líneas grises justo debajo de la tira de película de renderizado.
Cómo optimizar la primera pintura con contenido (FCP)
Ahora que comprende lo que conduce a la representación de su sitio web, puede pensar en cómo optimizarlo.
- ¿Puede el servidor responder a la solicitud HTML más rápidamente?
- ¿Se pueden cargar recursos a través de la misma conexión en lugar de crear una nueva?
- ¿Hay solicitudes que se pueden eliminar o cambiar para que ya no bloqueen el procesamiento?
Ahora que las partes iniciales de su sitio web se están cargando antes, es hora de concentrarse en hacer que el sitio completo se cargue más rápido.
Cómo acelerar la pintura con contenido más grande (LCP) con las recomendaciones de DebugBear
Hay muchas maneras de acelerar su LCP.
Para hacerlo más fácil, DebugBear nos brinda excelentes próximos pasos dentro de su sección de Recomendaciones.
Echemos un vistazo a algunos ejemplos de las recomendaciones y aprendamos cómo acelerar el LCP de este sitio web.
Recomendación 1: iniciar solicitudes de imágenes LCP desde el documento HTML
Si el elemento de contenido más grande de su página es una imagen, la mejor práctica es asegurarse de que la URL esté directamente contenida en el documento HTML inicial. Esto ayudará a que comience a cargarse lo antes posible.
Sin embargo, esta mejor práctica no siempre se usa y, a veces, el navegador tarda mucho tiempo en descubrir que necesita descargar la imagen principal.
En el siguiente ejemplo, el contenido más grande, que es una imagen, se agrega a la página mediante JavaScript. Como resultado, el navegador necesita descargar y ejecutar un script de 200 kilobytes antes de descubrir la imagen y comenzar a descargarla.
Captura de pantalla de DebugBear que muestra una cadena de solicitud secuencial que conduce a una solicitud de imagen, octubre de 2022 Cómo solucionarlo: dependiendo del sitio web, hay dos soluciones posibles.
Solución 1: si está utilizando JavaScript para cargar de forma diferida una imagen grande, optimice el tamaño de la imagen y elimine el script de carga diferida o reemplácelo con el atributo loading=”lazy” moderno, que no requiere JavaScript.
Solución 2: en otros casos, la renderización del lado del servidor evitaría tener que descargar la aplicación de JavaScript antes de que la página pueda renderizarse. Sin embargo, esto a veces puede ser complejo de implementar.
Recomendación 2: asegúrese de que las imágenes LCP se carguen con alta prioridad
Después de cargar el código HTML de una página, los navegadores de sus visitantes pueden descubrir que, además de su imagen principal, es posible que sea necesario cargar una gran cantidad de recursos adicionales, como hojas de estilo.
El objetivo aquí es asegurarse de que su imagen principal más grande se cargue para cumplir con el requisito de pintura más grande con contenido de Google.
Otros recursos, como scripts de análisis de terceros, no son tan importantes como su imagen principal.
Además, la mayoría de las imágenes a las que se hace referencia en el HTML de su sitio estarán en la parte inferior de la página una vez que se haya renderizado la página. Algunos pueden estar completamente ocultos en un encabezado de navegación anidado.
Debido a esto, los navegadores establecen inicialmente la prioridad de todas las solicitudes de imágenes en Baja. Una vez que se ha renderizado la página, el navegador descubre qué imágenes son importantes y cambia la prioridad. Puede ver un ejemplo de eso en la captura de pantalla a continuación, como lo indica el asterisco en la columna de prioridad.
Captura de pantalla de DebugBear que muestra una imagen LCP que se carga con una prioridad inicial baja, octubre de 2022 La cascada muestra que, si bien el navegador conocía la imagen desde el principio, no comenzó a descargarla, como lo indica la barra gris.
Cómo solucionarlo: para resolver esto, puede usar una nueva función del navegador llamada sugerencias de prioridad. Si agrega el atributo fetchpriority=”high” a un elemento img, el navegador comenzará a cargar la imagen desde el principio.
Recomendación 3: no oculte el contenido de la página usando CSS
A veces, puede ver una cascada de solicitudes y todos los recursos de bloqueo de procesamiento se han cargado, pero aún así, no aparece el contenido de la página. ¿Que esta pasando?
Las herramientas de prueba A/B a menudo ocultan el contenido de la página hasta que se hayan aplicado variaciones de prueba a los elementos de contenido de la página. En esos casos, el navegador ha renderizado la página pero todo el contenido es transparente.
¿Qué puede hacer si no puede eliminar la herramienta de prueba A/B?
Cómo solucionarlo: compruebe si puede configurar la herramienta para ocultar solo el contenido afectado por las pruebas A/B. Alternativamente, puede verificar si hay una manera de hacer que la herramienta de prueba A/B se cargue más rápido.
Captura de pantalla de DebugBear que muestra una tira de película renderizada donde el contenido está oculto por una herramienta de prueba A/B, octubre de 2022 Supervise la velocidad de su sitio con DebugBear
¿Quieres probar continuamente tu sitio web? Pruebe nuestra herramienta de monitoreo paga con una prueba gratuita de 14 días.
De esa manera, puede verificar si sus optimizaciones de rendimiento están funcionando y recibir alertas sobre cualquier regresión de rendimiento en su sitio.
Captura de pantalla que muestra las tendencias de velocidad del sitio para un sitio web en DebugBear, octubre de 2022 
Captura de pantalla que muestra los datos de Core Web Vitals en DebugBear, octubre de 2022