PRPL es un acrónimo que describe un patrón utilizado para cargar páginas web y sean interactivos y más rápidos:
- Precarga los recursos de detección tardía.
- Renderiza la ruta inicial lo antes posible.
- Almacena previamente en caché los recursos restantes.
- Carga de forma diferida otras rutas y recursos no críticos.
En esta guía, aprenderás cómo encaja cada una de estas técnicas, pero que aun así se puede y se usan de forma independiente para lograr resultados de rendimiento.
Audita tu página con Lighthouse
Ejecutar Lighthouse para identificar oportunidades de mejora alineadas con el PRPL técnicas:
- Presiona `Control + Mayúsculas + J` (o `Command + Option + J` en Mac) para abrir Herramientas para desarrolladores.
- Haz clic en la pestaña Lighthouse.
- Selecciona las casillas de verificación Rendimiento y App web progresiva.
- Haz clic en Ejecutar auditorías para generar un informe.
Para obtener más información, consulta Descubre oportunidades de rendimiento con Lighthouse.
Precarga los recursos críticos
Lighthouse muestra la siguiente auditoría con errores si se analiza un recurso determinado y recuperación tardía:
Precargar
es una solicitud de recuperación declarativa que le indica al navegador que solicite un recurso que, de lo contrario, el escáner de precarga del navegador no podría detectar, como una imagen a la que hace referencia la propiedad background-image. Agrega una etiqueta <link> con rel="preload" al encabezado de tu documento HTML para precargar los recursos descubiertos con retraso:
<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é. De este modo, el navegador podrá recuperarlos cuando sea necesario.
Para obtener más información sobre la precarga de recursos críticos, consulta el Precarga recursos críticos.
Renderiza la ruta inicial lo antes posible
Lighthouse proporciona una advertencia si hay recursos que retrasan First Paint. el momento en que tu sitio renderiza píxeles en la pantalla:
Para mejorar First Paint, Lighthouse recomienda integrar JavaScript y
postergando el resto usando
async:
además de intercalar las principales CSS que se usan en la mitad superior de la página. Esto mejora el rendimiento
a través de la eliminación de recorridos de ida y vuelta al servidor para recuperar elementos que bloquean la renderización.
Sin embargo, el código intercalado es más difícil de mantener desde la perspectiva del desarrollo y
el navegador no puede almacenarse
en caché de forma separada.
Otro enfoque para mejorar First Paint es renderizar en el servidor la imagen El código HTML de tu página. Esto muestra el contenido inmediatamente al usuario mientras las secuencias de comandos aún se están recuperando, analizando y ejecutando. Sin embargo, esto puede aumentar 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 la entrada del usuario.
No hay una única solución correcta para reducir la primera pintura en tu de la aplicación y solo debes considerar los estilos de incorporación y las aplicaciones si los beneficios superan las desventajas en tu aplicación. Puedes para obtener más información sobre estos dos conceptos en los siguientes recursos.
Prealmacenar elementos en caché
Al actuar como un proxy, los service workers pueden recuperar recursos directamente desde la caché en lugar del servidor en visitas repetidas. Esto no solo les permite a los usuarios usar tus aplicación cuando están sin conexión, pero también acelera los tiempos de carga de la página en 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 que los que puede proporcionan. Por ejemplo: Workbox proporciona una conjunto de herramientas que te permiten crear y mantener un service worker elementos almacenados en caché. Para obtener más información sobre los service workers y la confiabilidad sin conexión, consulta la guía del service worker en la ruta de aprendizaje sobre confiabilidad.
Carga diferida
Lighthouse muestra una auditoría con errores si envías demasiados datos a través de la red.
Esto incluye todos los tipos de recursos, pero las cargas útiles grandes de JavaScript debido al tiempo que le lleva al navegador analizarlas y compilarlas. Lighthouse también muestra una advertencia sobre 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 la aplicación, divide todo el paquete y los fragmentos de carga diferida a pedido.
Cuando hayas dividido tu paquete, precarga los fragmentos que tengan más (consulta la guía Precargar elementos críticos). La precarga garantiza que más recursos importantes se recuperen y descarguen antes el navegador.
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 que no son críticas.
Si cargas muchas imágenes en tu página web, aplaza todas las que se encuentren en la mitad inferior de la página. fuera del viewport del dispositivo, cuando se carga una página (consulta Cómo usar tamaños diferidos para imágenes de carga diferida).
Próximos pasos
Ahora que entiendes algunos de los conceptos básicos detrás del patrón PRPL, continúa a la siguiente guía de esta sección para obtener más información. Es importante recordar que no todas las técnicas necesitan ser en conjunto. Cualquier esfuerzo que se realice en relación con cualquiera de los siguientes puntos proporcionará mejoras de rendimiento notables.
- Precarga los recursos críticos.
- Renderiza la ruta inicial lo antes posible.
- Almacena previamente en caché los recursos restantes.
- Carga de forma diferida otras rutas y recursos no críticos.
Obtén más información sobre los patrones PRPL.