Cuando hablamos de rendimiento de front-end, pensamos en cosas como concatenación, minificación, almacenamiento en caché o gzip de activos en el servidor para que la página se cargue más rápido y los usuarios puedan completar sus objetivos lo más rápido posible.
La captación previa de recursos es otra técnica que mejora el rendimiento. Podemos usarlo para indicarle al navegador qué activos podría necesitar el usuario en el futuro, incluso antes de que los necesite.
Patrick Hamann explica:
La búsqueda previa es una forma de indicar al navegador los recursos que definitivamente se utilizarán en el futuro o que podrían usarse en el futuro; algunas sugerencias se aplican a la página actual, otras a posibles páginas futuras.
Como desarrolladores, conocemos nuestras aplicaciones mejor que el navegador. Podemos utilizar esta información para informar al navegador sobre los recursos principales.
Esta práctica de adivinar lo que necesitan los usuarios antes de que lo necesiten se ha denominado exploración previa. Sin embargo, no es solo una técnica, se divide en varias técnicas diferentes: dns-prefetch, subresource, el estandar prefetch, preconnect, y prerender.
Precarga de DNS
Esto notifica al cliente que hay activos que necesitaremos más adelante de una URL específica para que el navegador pueda resolver el DNS lo más rápido posible. Digamos que necesitamos un recurso, como una imagen o un archivo de audio, de la URL. example.com. En el <head> del documento que escribiríamos:
<link rel="dns-prefetch" href="https://example.com">Luego, cuando le solicitemos un archivo, ya no tendremos que esperar la búsqueda de DNS. Esto es particularmente útil si usamos código de terceros o recursos de redes sociales donde podríamos estar cargando un widget desde un <script>.
En su publicación épica de rendimiento de front-end, Harry Roberts sugiere usar esta técnica:
Esa simple línea le dirá a los navegadores compatibles que comiencen a buscar previamente el DNS para ese dominio una fracción antes de que sea realmente necesario. Esto significa que el proceso de búsqueda de DNS ya estará en marcha cuando el navegador acceda al elemento de secuencia de comandos que realmente solicita el widget. Simplemente le da al navegador una pequeña ventaja.
Esto puede parecer una mejora de rendimiento tan pequeña que no importa mucho, pero este no es necesariamente el caso: Chrome hace algo similar todo el tiempo. Preresolverá automáticamente el DNS (y, a veces, incluso preprogramará la página) si escribe solo una pequeña parte del dominio en la barra de URL, reduciendo así milisegundos cruciales de cada solicitud.
Preconectar
Al igual que el método de captación previa de DNS, la preconexión resolverá el DNS, pero también hará el protocolo de enlace de TCP y la negociación de TLS opcional. Se puede usar así:
<link rel="preconnect" href="https://css-tricks.com">Para obtener más información, Ilya Grigorik escribió una excelente publicación sobre esta útil sugerencia de recurso:
Los navegadores modernos hacen todo lo posible para anticipar qué conexiones necesitará el sitio antes de que se realice la solicitud real. Al iniciar “preconexiones” tempranas, el navegador puede configurar los sockets necesarios con anticipación y eliminar los costosos viajes de ida y vuelta de DNS, TCP y TLS de la ruta crítica de la solicitud real. Dicho esto, por más inteligentes que sean los navegadores modernos, no pueden predecir de manera confiable todos los objetivos de preconexión para todos y cada uno de los sitios web.
La buena noticia es que podemos, finalmente, ayudar al navegador; ¡Podemos decirle al navegador qué sockets necesitaremos antes de iniciar las solicitudes reales a través del nuevo envío de sugerencias de preconexión en Firefox 39 y Chrome 46!
Precarga
Si estamos seguros de que se requerirá un recurso específico en el futuro, podemos pedirle al navegador que solicite ese elemento y lo almacene en la memoria caché como referencia más adelante. Por ejemplo, una imagen o un script, o realmente cualquier cosa que el navegador pueda almacenar en caché:
<link rel="prefetch" href="https://css-tricks.com/prefetching-preloading-prebrowsing/image.png">A diferencia de la captación previa de DNS, en realidad estamos solicitando y descargando ese activo y almacenándolo en la caché. Sin embargo, esto depende de una serie de condiciones, ya que el navegador puede ignorar la captación previa. Por ejemplo, un cliente puede abandonar la solicitud de un archivo de fuente grande en una red lenta. Firefox solo precargará recursos cuando “el navegador esté inactivo”.
Como explica Bram Stein en su publicación sobre el tema, esto podría tener enormes beneficios de rendimiento para las fuentes web. Por el momento, los archivos de fuentes deben esperar a que se creen DOM y CSSOM antes de descargarlos. Pero, si los buscamos previamente, entonces ese cuello de botella se puede circunnavegar con facilidad.
Nota: aunque la búsqueda previa de activos solía ser un poco difícil de probar, Chrome y Firefox ahora mostrarán los recursos obtenidos previamente en el panel Red. Además, es útil recordar que no existe una restricción del mismo origen para la captación previa de enlaces.
Subrecursos (ver nota)
Otra técnica de captación previa ayuda a identificar los recursos que tienen la máxima prioridad y deben solicitarse antes de los elementos de captación previa. Por ejemplo, en Chrome y Opera podríamos agregar lo siguiente al head de nuestro documento:
<link rel="subresource" href="https://css-tricks.com/prefetching-preloading-prebrowsing/styles.css">Según los documentos de Chromium, funciona así:
“LINK rel = subresource” proporciona un nuevo tipo de relación de enlace con una semántica diferente de LINK rel = prefetch. Mientras que rel = prefetch proporciona una descarga de recursos de baja prioridad que se utilizará en las páginas siguientes, rel = subresource permite la carga temprana de recursos dentro de la página actual.
Entonces: si el activo es necesario para la página actual, o si se necesita lo antes posible, probablemente sea mejor usar subresource, de lo contrario, adhiérase a prefetch.
Notas importantes: Andy Davies aclara cómo funcionan realmente. También parece que se está eliminando de Chrome.
Preprocesamiento de páginas
Esta es la opción nuclear, ya que prerender nos da la capacidad de cargar preventivamente todos los activos de un determinado documento, así:
<link rel="prerender" href="https://css-tricks.com">Steve Souders escribió una gran explicación sobre esta técnica:
Esto es como abrir la URL en una pestaña oculta: se descargan todos los recursos, se crea el DOM, se distribuye la página, se aplica CSS, se ejecuta JavaScript, etc. href, luego la página oculta se cambia a la vista, lo que hace que parezca que se carga instantáneamente. La Búsqueda de Google ha tenido esta función durante años con el nombre de Páginas instantáneas. Microsoft anunció recientemente que usará de manera similar la reproducción previa en Bing en IE11.
¡Pero cuidado! Probablemente debería estar seguro de que el usuario hará clic en ese enlace; de lo contrario, el cliente descargará todos los activos necesarios para representar la página sin ningún motivo.
Souders continúa:
Al igual que con cualquiera de estos trabajos de anticipación, existe el riesgo de que la predicción sea incorrecta. Si el trabajo anticipatorio es costoso (por ejemplo, roba CPU de otros procesos, consume batería o desperdicia ancho de banda), entonces se justifica la precaución. Parece difícil anticipar a qué página irán los usuarios a continuación, pero existen escenarios de alta confianza:
- Si el usuario ha realizado una búsqueda con un resultado obvio, es probable que esa página de resultados se cargue a continuación.
- Si el usuario navegó a una página de inicio de sesión, es probable que la página de inicio de sesión sea la siguiente.
- Si el usuario está leyendo un artículo de varias páginas o un conjunto de resultados paginado, es probable que la página siguiente a la página actual sea la siguiente.
Por último, la API de visibilidad de página se puede utilizar para proteger contra la activación de scripts antes de que se muestren en la pantalla del usuario.
Bien, con esas consideraciones de diseño fuera del camino, podemos hablar sobre futuras adiciones a la especificación que también podrían ser de interés.
Opción futura: precarga
Una nueva especificación llamada precarga sugiere que a veces es mejor siempre descargar un activo, independientemente de si el navegador cree que es una buena idea o no. A diferencia de la captación previa de activos, que se pueden ignorar, la precarga de activos deber ser solicitado por el navegador.
<link rel="preload" href="https://css-tricks.com/prefetching-preloading-prebrowsing/image.png">Entonces, aunque la precarga no es compatible actualmente con ningún navegador en este momento, la idea detrás de ella es ciertamente interesante.
Terminando
Es difícil predecir lo que harán nuestros usuarios a continuación, y ciertamente requiere mucha planificación y pruebas. Pero definitivamente vale la pena perseguir los beneficios de rendimiento. Si estamos dispuestos a experimentar con estas técnicas de obtención previa, estamos seguros de que mejoraremos la experiencia del usuario de manera notable.
Más información sobre las técnicas de precarga, precarga y exploración previa
- Diapositivas de una charla de Ilya Grigorik llamada Preconnect, prerender, prefetch
- Preguntas frecuentes sobre la obtención previa de enlaces de MDN
- Especificaciones de precarga W3C
- Harry Roberts sobre la captación previa de DNS
- Captación previa de HTML5
- Precargar sugerencias para fuentes web