PRPL es un acrónimo que describe un patrón utilizado para cargar páginas web y volverse interactivas más rápidas:
- Precarga los recursos de detección tardía.
- Renderiza la ruta inicial lo antes posible.
- Almacenamiento previo en caché de los recursos restantes.
- Carga diferida de otras rutas y recursos que no son esenciales.
En esta guía, aprenderás cómo se combina cada una de estas técnicas, pero que aún se pueden usar de forma independiente para lograr resultados de rendimiento.
Cómo auditar tu página con Lighthouse
Ejecuta Lighthouse para identificar oportunidades de mejora alineadas con las técnicas de PRPL:
- Presiona "Control + Mayúsculas + J" (o "Comando + Opción + J" en Mac) para abrir DevTools.
- Haz clic en la pestaña Lighthouse.
- Selecciona las casillas de verificación Rendimiento y App web progresiva.
- Haz clic en Run Audits para generar un informe.
Para obtener más información, consulta Descubre oportunidades de rendimiento con Lighthouse.
Carga previamente recursos críticos
Lighthouse muestra la siguiente auditoría fallida si un recurso determinado se analiza y recupera tarde:
La carga previa es una solicitud de recuperación declarativa que le indica al navegador que solicite un recurso que, de otro modo, el escáner de carga previa del navegador no podría detectar, como una imagen a la que hace referencia la propiedad background-image
. Para precargar recursos descubiertos tardíamente, agrega una etiqueta <link>
con rel="preload"
al encabezado de tu documento HTML:
<link rel="preload" as="image" href="hero-image.jpg">
Si agregas una directiva <link rel="preload">
, se iniciará una solicitud para ese recurso y se almacenará en la caché. Luego, el navegador puede recuperarlo cuando sea necesario.
Para obtener más información sobre la precarga de recursos críticos, consulta la guía Precarga recursos críticos.
Renderiza la ruta inicial lo antes posible
Lighthouse proporciona una advertencia si hay recursos que retrasan First Paint, en el momento en que tu sitio renderiza píxeles en la pantalla:
Para mejorar First Paint, Lighthouse recomienda integrar JavaScript crítico y diferir el resto con async
, además de intercalar el CSS crítico que se usa en la mitad superior de la página. Esto mejora el rendimiento mediante la eliminación de los recorridos de ida y vuelta al servidor para recuperar elementos que bloquean el procesamiento.
Sin embargo, el código intercalado es más difícil de mantener desde una perspectiva de desarrollo y el navegador no puede almacenarlo en caché por separado.
Otro enfoque para mejorar First Paint es renderizar en el servidor el código HTML inicial de tu página. Esto muestra el contenido de inmediato al usuario mientras las secuencias de comandos aún se recuperan, analizan y ejecutan. Sin embargo, esto puede aumentar la carga útil del archivo HTML de forma significativa, lo que puede afectar el tiempo de carga o el tiempo que tarda tu aplicación en volverse interactiva y puede responder a las entradas del usuario.
No hay una sola solución correcta para reducir la primera pintura en tu aplicación, y solo debes considerar la incorporación de estilos y la renderización del servidor si los beneficios superan las compensaciones para tu aplicación. Puedes obtener más información sobre ambos conceptos con los siguientes recursos.
Prealmacenar elementos en caché
Cuando actúan como proxy, los service workers pueden recuperar recursos directamente desde la caché en lugar del servidor en visitas repetidas. Esto no solo permite que los usuarios usen tu aplicación cuando no tienen conexión, sino que también genera tiempos de carga de página más rápidos en las visitas repetidas.
Usa una biblioteca de terceros para simplificar el proceso de generación de un service worker, a menos que tengas requisitos de almacenamiento en caché más complejos de los que puede proporcionar una biblioteca. Por ejemplo, Workbox proporciona una colección de herramientas que te permiten crear y mantener un trabajador de servicio para almacenar en caché los recursos. Para obtener más información sobre los service workers y la confiabilidad sin conexión, consulta la guía de service worker en la ruta de aprendizaje sobre confiabilidad.
Carga diferida
Lighthouse muestra una auditoría fallida si envías demasiados datos a través de la red.
Esto incluye todos los tipos de recursos, pero las cargas útiles de JavaScript grandes son especialmente costosas debido al tiempo que tarda el navegador en analizarlas y compilarlas. Lighthouse también proporciona una advertencia para esto cuando corresponde.
Para enviar una carga útil de JavaScript más pequeña que contenga solo el código necesario cuando un usuario carga inicialmente tu aplicación, divide todo el paquete y los fragmentos de carga diferida a pedido.
Una vez que hayas logrado dividir el paquete, carga previamente los fragmentos que sean más importantes (consulta la guía Carga previamente los recursos críticos). La precarga garantiza que el navegador recupere y descargue los recursos más importantes con mayor rapidez.
Además de dividir y cargar diferentes fragmentos de JavaScript a pedido, Lighthouse también proporciona una auditoría para la carga diferida de imágenes no críticas.
Si cargas muchas imágenes en tu página web, aplaza todas las que estén debajo de la mitad inferior de la página o fuera del viewport del dispositivo cuando se cargue una página (consulta Cómo usar lazysizes para cargar imágenes de forma diferida).
Próximos pasos
Ahora que comprendes algunos de los conceptos básicos del patrón PRPL, sigue con la siguiente guía de esta sección para obtener más información. Es importante recordar que no todas las técnicas deben aplicarse juntas. Cualquier esfuerzo que se realice con cualquiera de las siguientes opciones proporcionará mejoras notables en el rendimiento.
- Precarga los recursos críticos.
- Renderiza la ruta inicial lo antes posible.
- Almacenamiento previo en caché de los recursos restantes.
- Carga diferida de otras rutas y recursos que no son esenciales.
Puedes obtener más información sobre los patrones PRPL.