En los últimos años, cada vez más plataformas para la optimización de proyectos frontend ofrecen opciones para la auto-alojamiento o el proxy de recursos externos. Akamai permite establecer para URLs creadas de forma autónoma. Cloudflare tiene la tecnología Edge Workers. Fasterzine puede las URLs en las páginas de manera que apunten a recursos externos que se encuentran en el dominio principal del sitio.
Si sabe que los servicios externos utilizados en su proyecto no cambian con frecuencia y que el proceso de entrega a los clientes puede mejorarse, seguramente está considerando el proxy de tales servicios. Con este enfoque, puede "acercar" esos recursos a los usuarios y obtener un control más completo sobre su almacenamiento en caché del lado del cliente. Esto, además, permite proteger a los usuarios de los inconvenientes causados por la "caída" del servicio externo o por la degradación de su rendimiento.
Bueno: aumento del rendimiento
El auto-alojamiento de recursos externos mejora el rendimiento de manera bastante obvia. El navegador no necesita hacer una consulta adicional al DNS, no tiene que establecer una conexión TCP y realizar un apretón de manos TLS en un dominio externo. El impacto del auto-alojamiento de recursos externos en el rendimiento se puede observar comparando los dos siguientes gráficos.
Los recursos externos se cargan desde fuentes externas (tomado )
Los recursos externos se almacenan junto con otros materiales del sitio (tomado )
La situación mejora aún más, ya que el navegador utilizará las capacidades de multiplexión y priorización de la conexión HTTP/2 que ya se ha establecido con el dominio principal.
Si no aloja recursos externos, ya que se cargarán desde un dominio diferente al principal, no se podrán priorizar. Esto hará que compitan entre sí por el ancho de banda del cliente. Esto puede llevar a que el tiempo de carga de materiales críticos para la formación de la página sea mucho mayor que el tiempo alcanzable en un escenario ideal. una presentación sobre la priorización HTTP/2, en la que se explica todo esto muy bien.
Se puede suponer que el uso de atributos en enlaces a recursos externos preconnect ayudará a resolver el problema. Sin embargo, si hay demasiados enlaces a diferentes dominios, esto puede, de hecho, sobrecargar la línea de comunicación en el momento más crítico.
Si se alojan recursos de terceros de manera independiente, se puede controlar cómo se entregan exactamente esos recursos al cliente. En particular, se trata de lo siguiente:
- Se puede asegurar la aplicación de un algoritmo de compresión de datos, el más adecuado para cada navegador (Brotli/gzip).
- Se puede aumentar el tiempo de caché de los recursos, que generalmente, incluso entre los proveedores más conocidos, no es muy alto (por ejemplo, el valor correspondiente para las etiquetas de GA está establecido en 30 minutos).
Incluso se puede extender el indicador TTL para un recurso, por ejemplo, hasta un año, incorporando los materiales correspondientes en su estrategia de gestión de caché (hashes de URL, versionado, etc.). Hablaremos de esto más adelante.
▍Protección contra interrupciones en los servicios de terceros o su desactivación
Otro aspecto interesante del alojamiento independiente de recursos de terceros es que permite mitigar los riesgos asociados con las interrupciones en los servicios de terceros. Supongamos que la solución de terceros que utiliza para realizar pruebas A/B se implementa en forma de un script bloqueante que se carga en la sección de encabezado de la página. Este script se carga lentamente. Si no se puede cargar el script correspondiente, la página estará vacía. Si la carga del script demora mucho tiempo, la página aparecerá con gran retraso. O, supongamos que en el proyecto se utiliza una biblioteca que se carga desde un recurso CDN externo. Imaginemos que este recurso ha fallado o ha sido bloqueado en algún país. Tal situación llevará a una interrupción en la lógica de funcionamiento del sitio.
Para conocer cómo funciona su sitio en condiciones de inaccesibilidad de un servicio externo, puede utilizar la sección SPOF en .
La sección SPOF en webpagetest.org
▍¿Y qué pasa con los problemas de almacenamiento en caché de los materiales en los navegadores? (pista: es un mito)
Se podría pensar que el uso de CDNs públicos mejorará automáticamente el rendimiento de los recursos, ya que estos servicios cuentan con redes de calidad y están distribuidos por todo el mundo. Pero, en realidad, la situación es un poco más compleja.
Supongamos que tenemos varios sitios diferentes: website1.com, website2.com, website3.com. En todos estos sitios se utiliza la biblioteca jQuery. La conectamos a ellos usando un CDN, por ejemplo, googleapis.com. Se podría esperar que el navegador la cargue y la almacene en caché una vez, para luego usarla en todos los tres sitios. Esto podría reducir la carga en la red. Tal vez permita ahorrar en algunos lugares y ayude a mejorar el rendimiento de los recursos. Sin embargo, desde un punto de vista práctico, todo se ve diferente. Por ejemplo, Safari implementa una característica llamada : en la caché se utilizan claves dobles, basadas en la fuente del documento y en la fuente del recurso externo. un buen artículo sobre este tema.
Investigaciones antiguas y , así como más recientes de Paul Calvano, muestran que los recursos no se almacenan en las cachés de los navegadores tanto tiempo como podríamos esperar: 'Hay una brecha significativa entre el tiempo de almacenamiento en caché de los recursos propios y los externos del proyecto. Se refiere a los CSS y a las fuentes web. En concreto, el tiempo de almacenamiento en caché del 95% de las fuentes propias supera la semana, mientras que el tiempo de almacenamiento en caché del 50% de las fuentes externas es de menos de una semana. Esto brinda a los desarrolladores web razones sólidas para alojar los archivos de fuentes por sí mismos.'
Como resultado, si aloja materiales de terceros, no notará problemas de rendimiento causados por el almacenamiento en caché del navegador.
Ahora que hemos explorado las ventajas del autoalojo de recursos externos, hablemos sobre cómo distinguir una buena implementación de este enfoque de una mala.
Malo: el diablo está en los detalles
Mover recursos externos a su propio dominio no se puede hacer automáticamente sin asegurar un correcto almacenamiento en caché de dichos recursos.
Uno de los principales problemas aquí es el tiempo de almacenamiento en caché. Por ejemplo, la información sobre versiones se incluye en los nombres de los scripts externos de la siguiente manera: jquery-3.4.1.js. Este archivo no cambiará en el futuro, por lo que esto no causará ningún problema con su almacenamiento en caché.
Pero si no se aplica algún esquema de versionado al trabajar con archivos, los scripts en caché, cuyo contenido cambia con el mismo nombre de archivo, pueden quedar obsoletos. Esto puede convertirse en un problema serio, ya que, por ejemplo, no permite aplicar correcciones de seguridad a los scripts automáticamente, las cuales deben ser implementadas por los clientes lo más pronto posible. El desarrollador tendrá que esforzarse para actualizar esos scripts en la caché. Además, esto puede causar fallos en la aplicación, debido a que el código utilizado en el cliente desde la caché es diferente de la versión actualizada de código en la que se basa la parte del servidor del proyecto.
Sin embargo, cuando hablamos de materiales que se actualizan con frecuencia (gestores de etiquetas, soluciones de A/B testing), el almacenamiento en caché para los CDN es una tarea que, aunque se puede resolver, es mucho más compleja. Servicios como Commanders Act, soluciones para la gestión de etiquetas, utilizan webhooks al publicar nuevas versiones. Esto permite organizar la invalidación de la caché en el CDN o, mejor aún, la posibilidad de provocar la actualización del hash o versión del URL.
▍Entrega adaptable de materiales a los clientes
Además, cuando hablamos de almacenamiento en caché, también debemos considerar que las configuraciones de caché utilizadas en el CDN pueden no ser adecuadas para ciertos recursos externos. Por ejemplo, estos recursos pueden utilizar la tecnología de detección del agente de usuario (user agent sniffing, adaptive serving) para entregar a navegadores específicos versiones de materiales optimizadas específicamente para esos navegadores. Estas tecnologías, para averiguar las capacidades del navegador, se basan en expresiones regulares o en una base de datos que recopila información sobre los encabezados HTTP. User-Agent. Al saber qué navegador están tratando, les entregan materiales diseñados para él.
Aquí se pueden recordar dos servicios. El primero es googlefonts.com. El segundo es polyfill.io. El servicio Google Fonts proporciona, para un recurso dado, diferentes códigos CSS que dependen de las capacidades del navegador (proporcionando enlaces a recursos woff2, utilizando unicode-range).
Estos son los resultados de un par de consultas a Google Fonts realizadas desde diferentes navegadores.
Resultado de la consulta a Google Fonts, realizada desde Chrome
Resultado de la consulta a Google Fonts, realizada desde IE10
Polyfill.io proporciona al navegador solo los polyfills que necesita. Esto se hace por razones de rendimiento.
Por ejemplo, veamos qué sucederá si se realiza la siguiente consulta desde diferentes navegadores:
En respuesta a tal consulta, realizada desde IE10, se enviarán 34 KB de datos. En cambio, la respuesta a la misma consulta realizada desde Chrome será vacía.
Maligno: algunas consideraciones sobre la privacidad
Este punto es el último en orden, pero no en importancia. Se trata de que alojar recursos de terceros en el dominio principal del proyecto o en su subdominio puede poner en riesgo la privacidad de los usuarios y afectar negativamente al proyecto web principal.
Si su sistema CDN no está configurado correctamente, todo puede acabar con el envío de las cookies de su dominio a un servicio externo. Si no se organiza una filtración adecuada a nivel de CDN, sus cookies de sesión, que normalmente no se pueden usar en JavaScript (con el atributo httponly), pueden ser enviadas a un host externo.
Esto puede ocurrir con rastreadores como Eulerian o Criteo. Los rastreadores de terceros podrían establecer un identificador único en las cookies. Si estaban incluidos en los materiales de los sitios, podían leer el identificador a su antojo mientras el usuario interactuaba con diferentes recursos web.
Hoy en día, la mayoría de navegadores incluyen protección contra este tipo de comportamiento de los rastreadores. Como resultado, los rastreadores ahora utilizan la tecnología , ocultándose bajo sus propios scripts de varios proyectos. En particular, los rastreadores sugieren a los propietarios de sitios que añadan en su configuración un CNAME para un dominio, cuya dirección suele parecer un conjunto aleatorio de caracteres.
Aunque no se recomienda hacer que las cookies del sitio web estén disponibles para todos los subdominios (por ejemplo — *.website.com), esto se hace en muchos sitios. En tal caso, dichas cookies se envían automáticamente a un rastreador externo disfrazado. Como resultado, ya no se puede hablar de privacidad.
Además, lo mismo ocurre con los encabezados HTTP , que solo se envían al dominio principal, ya que pueden ser utilizados para crear del usuario. Asegúrese de que el servicio CDN que utiliza filtre correctamente dichos encabezados.
Resultados
Si planea implementar en breve el autoalojamiento de recursos de terceros, permítame darle algunos consejos:
- Aloje sus bibliotecas JS, fuentes y archivos CSS más importantes. Esto reducirá el riesgo de que su sitio se caiga o su rendimiento disminuya debido a que un recurso vital se vuelve inaccesible por culpa de un servicio externo.
- Antes de almacenar en caché recursos de terceros en el CDN, asegúrese de que se esté utilizando algún sistema de versionado para nombrar sus archivos, o que puede gestionar el ciclo de vida de estos recursos, ya sea manualmente o restableciendo automáticamente la caché del CDN al publicar una nueva versión del script.
- Preste mucha atención a la configuración del CDN, proxy y caché. Esto le permitirá evitar el envío de cookies de su proyecto o encabezados
Client-Hintsa servicios de terceros.
¡Estimados lectores! ¿Está alojando en sus servidores materiales de otros que son extremadamente importantes para el funcionamiento de sus proyectos?
Fuente: habr.com
