Cómo acelerar el LCP con la carga previa entre sitios

Una introducción a las tecnologías que ya están disponibles

Kenji Baheux
Kenji Baheux
Michael Buettner
Michael Buettner
Devin Mullins
Devin Mullins

¿Por qué es importante la velocidad de carga de la página?

La mayoría de los usuarios suelen identificar las cargas de páginas lentas como una principal fuente de frustración (54% en un estudio de usuarios realizado por Google). Por lo tanto, no debería sorprendernos que las cargas de páginas más rápidas generen mejores resultados para las empresas. De hecho, si los visitantes se frustran incluso antes de interactuar con un sitio web, es muy poco probable que se queden el tiempo suficiente para apreciar su valor. De hecho, otro estudio de Google realizado en 254 sitios de comercio electrónico, finanzas y viajes mostró que los sitios que se cargan en dos segundos o menos tenían porcentajes de conversiones un 15% más altos.

Aceleración del Largest Contentful Paint (LCP)

Como se suele decir, no se puede mejorar lo que no se mide. En el caso de las experiencias del usuario en la Web, creemos que las Métricas web esenciales constituyen un conjunto sólido de métricas centradas en el usuario y diseñadas para captar aspectos fundamentales de la experiencia del usuario. En particular, el Largest Contentful Paint (LCP) mide el rendimiento de carga de tus páginas informando el tiempo que tarda en mostrarse el bloque de texto o imagen más grande que ve el usuario. Para proporcionar una buena experiencia del usuario, el LCP debe ocurrir dentro de los 2.5 segundos posteriores a que la página comienza a cargarse por primera vez (es decir, el buen umbral de LCP).

Veamos qué contribuye al LCP de una página típica.

Cascada de carga de la página.
Una cascada típica que se requiere para cargar una página web

Cuando un usuario visita una página, el navegador solicita el código HTML al servidor. El servidor responde con el código HTML, lo que proporciona al navegador más sugerencias sobre qué recuperar a continuación, como CSS, JavaScript, imágenes y fuentes. A medida que se vuelvan a mostrar estas respuestas, el navegador también deberá evaluarlas y, finalmente, diseñar y pintar los componentes de la página. Sin embargo, la mayor parte del tiempo se ocupa en que esos paquetes viajen del dispositivo al servidor y, luego, de vuelta al dispositivo. De hecho, nuestros datos (Chrome para Android; mediana) muestran que, por lo general, el navegador pasa alrededor del 40% de la latencia visible para el usuario a la espera de que el primer byte regrese del servidor.

El poder de la carga previa

Si se pudiera cargar previamente todos estos archivos, es decir, recuperarlos antes de que el usuario visite la página, esto proporcionaría un aumento masivo de la velocidad, lo que solo permitiría unas pocas tareas antes de mostrar la página: evaluar, calcular el diseño y pintar.

Cascada optimizada.
Con todos los recursos precargados, la cascada está optimizada a la perfección.

Dados los datos compartidos anteriormente, también se podría cargar previamente el recurso principal y, de todos modos, lograr una carga de la página significativamente más rápida. En el caso del mismo sitio, este tipo de técnica ya está disponible con primitivas como rel=prefetch. Sin embargo, en los casos que ocurren entre sitios, no es tan sencillo.

Navegaciones entre sitios

Si bien la carga previa existe por un tiempo, se garantiza una consideración adicional cuando se solicitan páginas de un sitio mientras el usuario está en otro.

Supongamos que un sitio de referencia le indica al navegador que realice una carga previa de una página desde otro sitio. Obviamente, cuando el usuario hace clic en el vínculo a esta página cargada previamente, disfrutaría de una mejor experiencia del usuario con una carga de página mucho más rápida. Sin embargo, ¿qué sucede si el usuario nunca hace clic en este vínculo? No esperarían que un sitio web vinculado supiera que pueden estar interesados en un tema mientras lo buscaban en el sitio de referencia. Sin embargo, este es un riesgo importante porque las solicitudes de carga previa llevarían la dirección IP del usuario, y cookies, si las hubiera, como cualquier otra solicitud normal.

Soluciones

Para habilitar la carga previa entre sitios que resguarde la privacidad, desarrollamos dos soluciones en los últimos 3 años: Private Prefetch Proxy y Intercambios firmados (SXG). También realizamos un experimento a gran escala para confirmar que la carga previa de origen cruzado ofrece beneficios de velocidad significativos. Concretamente, cuando analizamos instancias en las que Google pudo cargar previamente de forma segura el código HTML principal para la siguiente navegación del usuario, vimos que la fracción de cargas de página con un LCP "bueno" aumentó 14 puntos porcentuales.

Consideraciones clave

Si bien Private Prefetch Proxy y Signed Exchange resuelven el mismo caso de uso, cada tecnología presenta un conjunto diferente de ventajas y desventajas. Por lo tanto, la mejor opción depende realmente de las necesidades específicas de tu sitio. Para ayudarte a tener una idea de las compensaciones, las siguientes secciones abarcan dos consideraciones clave para habilitar la carga previa entre sitios y elegir entre las dos tecnologías disponibles. También encontrará más detalles en los artículos detallados de cada tecnología.

Visitantes recurrentes

La carga previa entre sitios es fácil de habilitar para los usuarios que visitan tu sitio por primera vez. En el caso de los visitantes recurrentes, esto depende del nivel de personalización que se destina a tu sitio. Esto se debe a que las solicitudes de carga previa entre sitios no pueden incluir cookies por motivos de privacidad.

  • Para los visitantes nuevos, esta restricción no presenta ningún desafío porque estos visitantes no tienen cookies desde el principio. Por lo tanto, puedes habilitar la carga previa entre sitios para estos usuarios sin ningún cambio en tu sitio.
  • Si quieres habilitar la carga previa entre sitios para los visitantes recurrentes y tu sitio está personalizado en función de cookies, deberás hacer una carga diferida de estos elementos personalizados después de que el usuario navegue. Esto funciona porque, durante la navegación, la restricción de cookies ya no es necesaria porque el usuario eligió visitar explícitamente su sitio web. Por lo tanto, en el momento de la navegación, tu sitio tiene acceso a las cookies como de costumbre. Si deseas obtener orientación concreta, consulta estas prácticas recomendadas para la carga diferida.
    • Si actualmente codificas la personalización directamente en tu HTML, puedes seguir haciéndolo cuando haya cookies y usar la carga diferida como estrategia de resguardo para las páginas cargadas previamente.
    • Si tu sitio no está personalizado en función de cookies o si la personalización no es fundamental, puedes elegir mostrarles a los visitantes recurrentes el mismo contenido que a los visitantes nuevos.

Por el momento, Private Prefetch Proxy solo está habilitado para los visitantes nuevos (vínculos sin cookies) con trabajo continuo a fin de expandir la cobertura a los visitantes recurrentes (vínculos con cookies). Por otro lado, el intercambio firmado ya admite la carga previa entre sitios, tanto para visitantes nuevos como para visitantes recurrentes (con los enfoques descritos anteriormente).

Entrega de datos adicionales de la carga previa

Habilitar la carga previa entre sitios puede generar entregas de datos adicionales. De hecho, si una URL de referencia carga previamente tu página, pero el usuario no hace clic en el vínculo, esto representaría más tráfico para ti.

  • Para mitigar esto, podrías solicitar que la URL de referencia sea menos agresiva con sus solicitudes de carga previa. De manera similar, la URL de referencia, o el navegador, puede mitigar esto si se enfoca en recursos relativamente ligeros, pero críticos (por ejemplo, recurso principal, CSS crítico o subrecursos de JavaScript). En esencia, se trata de un equilibrio entre los beneficios de velocidad y el tráfico adicional.
  • Como alternativa, se podría compensar este tráfico habilitando el almacenamiento en caché adicional (consulta esta sección sobre Intercambio firmado para obtener más información). La desventaja es que almacenar contenido en caché por mucho tiempo puede hacer que se muestre información más antigua a los usuarios. En esencia, se trata de un equilibrio entre la entrega de datos adicionales y la actualización del contenido.

Para tomar la mejor decisión aquí, pregúntate en qué punto de la escala variable entre la actualización máxima y la cantidad mínima de solicitudes adicionales se encuentra tu sitio. En última instancia, la respuesta a esta pregunta depende de las necesidades específicas de su empresa y sus usuarios.

Primeros pasos

Estas tecnologías se integraron en la Búsqueda de Google para que los sitios puedan comenzar a mejorar su LCP de inmediato. Esperamos que esto aliente a otros referentes populares a seguir el ejemplo y ayude a que la Web sea mucho más rápida en todos los ámbitos.

Si bien estas tecnologías resuelven el mismo caso de uso, ofrecen diferentes compensaciones en las consideraciones clave que se explicaron anteriormente. Incluso es posible que decidas comenzar con una tecnología y pasar a la otra a medida que evolucionen tus necesidades o apreciación de los beneficios. Consulta estos análisis detallados para descubrir qué tecnología es la mejor opción para tu situación particular: