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

Una introducción a las tecnologías 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 identifican con frecuencia las cargas lentas de páginas como una fuente importante de frustración (54% en un estudio de usuarios realizado por Google). Por lo tanto, no debería sorprender que las cargas de páginas más rápidas generen mejores resultados para una empresa. De hecho, si los visitantes se sienten frustrados incluso antes de interactuar con un sitio web, es muy poco probable que permanezcan el tiempo suficiente para apreciar su valor. De hecho, otro estudio de Google en 254 sitios de comercio electrónico, finanzas y viajes mostró que los sitios que se cargan en dos segundos o menos tenían un 15% más de tasas de conversión.

Acelera el procesamiento de imagen con contenido más grande (LCP)

Como dice el refrán, 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 diseñadas para captar aspectos fundamentales de la experiencia del usuario. En particular, la métrica Largest Contentful Paint (LCP) mide el rendimiento de carga de tus páginas, ya que informa 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 en un plazo de 2.5 segundos a partir del momento en que la página comienza a cargarse (es decir, el umbral de LCP bueno).

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

Cascada de carga de la página
Una cascada típica necesaria 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, que le brinda al navegador más sugerencias sobre qué recuperar a continuación, incluidos CSS, JavaScript, fuentes e imágenes. A medida que se muestran estas respuestas, el navegador también debe realizar algunos trabajos para evaluarlas y, finalmente, diseñar y pintar los componentes en la página. Sin embargo, la mayor parte del tiempo se dedica a esperar 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 dedica alrededor del 40% de la latencia visible para el usuario a esperar que el primer byte regrese del servidor.

El poder de la carga previa

Si se pudieran recuperar todos estos archivos de antemano, es decir, antes de que el usuario visite la página, esto proporcionaría un aumento masivo de la velocidad, lo que dejaría solo algunas tareas antes de mostrar la página: evaluar, calcular el diseño y pintar.

Cascada optimizada.
Con todos los recursos precargados, la cascada se optimiza perfectamente.

Teniendo en cuenta los datos compartidos anteriormente, también se podría recuperar previamente el recurso principal y, aun así, lograr una carga de página mucho más rápida. En el caso del mismo sitio, este tipo de técnica está disponible con primitivas como rel=prefetch. Sin embargo, en el caso de los escenarios entre sitios, no es tan sencillo.

Navegaciones entre sitios

Si bien la carga previa existe desde hace tiempo, se recomienda tener en cuenta una consideración adicional cuando se cargan páginas de un sitio mientras el usuario está en otro.

Supongamos que un sitio de referencia le indica al navegador que precargue una página de un sitio diferente. Obviamente, cuando el usuario haga clic en el vínculo a esta página recuperada previamente, disfrutará 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 sepa que podría haber estado interesado en un tema mientras lo buscaba en el sitio de referencia. Sin embargo, esto es un riesgo considerable, ya que las solicitudes de precarga llevarían la dirección IP del usuario y las cookies, si las hubiera, como cualquier otra solicitud normal.

Soluciones

Para habilitar la carga previa entre sitios que protege la privacidad, desarrollamos dos soluciones en los últimos 3 años: Private Prefetch Proxy y Signed Exchanges (SXG). También ejecutamos un experimento a gran escala para confirmar que la precarga entre orígenes ofrece beneficios de velocidad significativos. Específicamente, cuando analizamos los casos en los que Google pudo recuperar en caché de forma segura el HTML principal para la próxima navegación del usuario, observamos que la fracción de cargas de página con un LCP "bueno" aumentó en 14 puntos porcentuales.

Consideraciones clave

Si bien el proxy de precarga privada y el intercambio firmado resuelven el mismo caso de uso, cada tecnología presenta un conjunto diferente de compensaciones. Por lo tanto, la mejor opción depende de las necesidades específicas de tu sitio. Para ayudarte a comprender las compensaciones involucradas, en las siguientes secciones, se abordan dos consideraciones clave para habilitar la precarga entre sitios y elegir entre las dos tecnologías disponibles. También encontrarás más detalles en los artículos de análisis detallados de cada tecnología.

Visitantes recurrentes

La precarga entre sitios es fácil de habilitar para los usuarios que visitan tu sitio por primera vez. En el caso de los visitantes recurrentes, depende de la cantidad de personalización que se incluya en tu sitio. Esto se debe a que las solicitudes de precarga entre sitios no pueden incluir cookies por motivos de privacidad.

  • Para los visitantes nuevos, esta restricción no presenta ningún desafío, ya que no tienen cookies para empezar. Por lo tanto, puedes habilitar la precarga entre sitios para estos usuarios sin realizar ningún cambio en tu sitio.
  • Si deseas habilitar la carga previa entre sitios para los visitantes recurrentes y tu sitio se personaliza en función de las cookies, deberás cargar estos elementos personalizados de forma diferida después de que el usuario navegue. Esto funciona porque, durante la navegación, ya no se necesita la restricción de cookies, ya que el usuario eligió explícitamente visitar tu sitio web. Por lo tanto, durante la navegación, tu sitio tiene acceso a sus cookies como de costumbre. Para obtener orientación concreta, consulta estas prácticas recomendadas para la carga diferida.
    • Si actualmente codificas la personalización directamente en tu código HTML, puedes seguir haciéndolo cuando haya cookies y usar la carga diferida como estrategia de resguardo para las páginas recuperadas previamente.
    • Si tu sitio no se personaliza en función de las cookies o si la personalización no es fundamental, puedes publicar el mismo contenido para los visitantes recurrentes que para los visitantes nuevos.

Por el momento, el proxy de precarga privada solo está habilitado para los visitantes nuevos (vínculos sin cookies), y se está trabajando para expandir la cobertura a los visitantes recurrentes (vínculos con cookies). Por otro lado, el intercambio firmado ya admite la precarga entre sitios para los visitantes nuevos y recurrentes (con los enfoques descritos anteriormente).

Publicación de datos adicionales desde la recuperación previa

Si habilitas la carga previa entre sitios, es posible que se entreguen datos adicionales. De hecho, si un referente precarga tu página, pero el usuario no hace clic en el vínculo, esto representaría tráfico adicional para ti.

  • Para mitigar esto, se podría solicitar que el referente sea menos agresivo con sus solicitudes de carga previa. Del mismo modo, el referente o el navegador pueden mitigar esto enfocándose en recursos relativamente ligeros, pero críticos (por ejemplo, el recurso principal, el CSS crítico o los subrecursos de JavaScript). Esto es, en esencia, una compensación 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 el intercambio firmado para obtener más información). La desventaja de esto es que almacenar contenido en caché durante demasiado tiempo puede provocar que se muestre información más antigua a los usuarios. Esto es, en esencia, una compensación entre la entrega de datos adicionales y la actualización del contenido.

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

Cómo comenzar

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 también motive a otros referers populares a seguir el ejemplo y ayudar a que la Web sea mucho más rápida en todos los aspectos.

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