En los últimos años, cada vez más plataformas para optimizar proyectos front-end ofrecen oportunidades para el autohospedaje o el proxy de recursos de terceros. Akamai le permite configurar para URL autogeneradas. Cloudflare tiene tecnología Edge Workers. lata más rápida URL de páginas para que apunten a recursos de terceros ubicados en el dominio principal del sitio.
Si sabe que los servicios de terceros utilizados en su proyecto no cambian con mucha frecuencia y que el proceso de entrega a los clientes podría mejorarse, entonces probablemente esté pensando en utilizar dichos servicios como proxy. Con este enfoque, puede acercar estos recursos a sus usuarios y obtener un control más completo sobre su almacenamiento en caché en el lado del cliente. Esto, además, le permite proteger a los usuarios de problemas causados por la "caída" de un servicio de terceros o la degradación de su rendimiento.
Bueno: rendimiento mejorado
El autohospedaje de los recursos de otra persona mejora el rendimiento de una manera muy obvia. El navegador no necesita acceder a DNS nuevamente, no necesita establecer una conexión TCP y realizar un protocolo de enlace TLS en un dominio de terceros. Puede ver cómo el autohospedaje de los recursos de otra persona afecta el rendimiento comparando las dos figuras siguientes.
Los recursos de terceros se descargan de fuentes externas (tomado de )
Los recursos de terceros se almacenan en el mismo lugar que el resto de los materiales del sitio (tomado de )
La situación también mejora por el hecho de que el navegador utilizará la capacidad de multiplexar y priorizar datos de la conexión HTTP/2 que ya se ha establecido con el dominio principal.
Si no aloja recursos de terceros, dado 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 provocar que los tiempos de carga del contenido fundamental para crear una página sean mucho más largos de lo que se podría lograr en circunstancias ideales. charla sobre priorización HTTP/2 que explica muy bien todo esto.
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, se puede sobrecargar la línea de comunicación en el momento más crucial.
Si usted mismo aloja recursos de terceros, puede controlar cómo exactamente se entregan estos recursos al cliente. Es decir, estamos hablando de lo siguiente:
- Puedes asegurarte de que se utiliza el algoritmo de compresión de datos que mejor se adapta a cada navegador (Brotli/gzip).
- Puede aumentar el tiempo de almacenamiento en caché de recursos que normalmente no son particularmente largos, incluso con los proveedores más conocidos (por ejemplo, el valor correspondiente para la etiqueta GA se establece en 30 minutos).
Incluso puede extender el TTL de un recurso a, digamos, un año incorporando contenido relevante en su estrategia de administración de almacenamiento en caché (hashes de URL, control de versiones, etc.). Hablaremos de esto a continuación.
▍Protección contra interrupciones en el funcionamiento de servicios de terceros o su cierre
Otro aspecto interesante del autohospedaje de recursos de terceros es que le permite mitigar los riesgos asociados con las interrupciones de los servicios de terceros. Supongamos que la solución de pruebas A/B de terceros que está utilizando está implementada como un script de bloqueo que se carga en la sección principal de la página. Este script se carga lentamente. Si el script correspondiente no se carga, la página estará vacía. Si tarda mucho en cargarse, la página aparecerá con un gran retraso. O supongamos que el proyecto utiliza una biblioteca descargada de un recurso CDN de terceros. Imaginemos que este recurso experimentó un fallo o fue bloqueado en un determinado país. Tal situación conducirá a una violación de la lógica del sitio.
Para saber cómo funciona su sitio cuando algún servicio externo no está disponible, puede utilizar la sección SPOF en .
Sección SPOF en webpagetest.org
▍¿Qué pasa con los problemas con el almacenamiento en caché de materiales en los navegadores? (pista: es un mito)
Se podría pensar que el uso de CDN públicas conduciría automáticamente a un mejor rendimiento de los recursos, ya que estos servicios tienen redes de calidad bastante alta y están distribuidos en todo el mundo. Pero en realidad todo es un poco más complicado.
Digamos que tenemos varios sitios diferentes: sitio web1.com, sitio web2.com, sitio web3.com. Todos estos sitios utilizan la biblioteca jQuery. Lo conectamos con ellos mediante una CDN, por ejemplo: googleapis.com. Puede esperar que el navegador descargue y almacene en caché la biblioteca una vez y luego la use en los tres sitios. Esto podría reducir la carga en la red. Quizás esto le permita ahorrar dinero en alguna parte y le ayude a mejorar el rendimiento de los recursos. Desde un punto de vista práctico, todo parece diferente. Por ejemplo, Safari tiene una función llamada : La caché utiliza claves duales según la fuente del documento y la fuente del recurso de terceros. buen artículo sobre este tema.
estudios antiguos и , así como más recientes Paul Calvano, muestran que los recursos no se almacenan en las cachés del navegador durante tanto tiempo como podríamos esperar: “Existe una brecha importante entre el tiempo de almacenamiento en caché de los recursos propios y de terceros de un proyecto. Estamos hablando de CSS y fuentes web. Es decir, el 95 % de las fuentes nativas tienen una vida útil de caché de más de una semana, mientras que el 50 % de las fuentes de terceros tienen una vida útil de caché de menos de una semana. ¡Esto les da a los desarrolladores web una razón convincente para alojar ellos mismos los archivos de fuentes!
Como resultado, si aloja el contenido de otras personas, no notará ningún problema de rendimiento causado por el almacenamiento en caché del navegador.
Ahora que hemos cubierto los puntos fuertes del autohospedaje de terceros, hablemos de cómo distinguir una buena implementación de este enfoque de una mala.
Lo malo: el diablo está en los detalles
Mover recursos de terceros a su propio dominio no se puede realizar automáticamente sin asegurarse de que dichos recursos estén almacenados en caché correctamente.
Uno de los principales problemas aquí es el tiempo de almacenamiento en caché. Por ejemplo, la información de la versión se incluye en nombres de scripts de terceros como este: jquery-3.4.1.js. Dicho archivo no cambiará en el futuro y, como resultado, no causará ningún problema con su almacenamiento en caché.
Pero si no se utiliza algún esquema de control de versiones al trabajar con archivos, los scripts almacenados en caché, cuyo contenido cambia mientras el nombre del archivo permanece sin cambios, pueden quedar obsoletos. Esto puede ser un problema grave, ya que, por ejemplo, no permite agregar parches de seguridad automatizados a los scripts que los clientes deben recibir lo más rápido posible. El desarrollador deberá hacer un esfuerzo para actualizar dichos scripts en la memoria caché. Además, esto puede causar fallas en la aplicación debido al hecho de que el código utilizado en el cliente desde el caché difiere de la última versión del código para el cual está diseñada la parte del servidor del proyecto.
Es cierto que si hablamos de materiales que se actualizan con frecuencia (administradores de etiquetas, soluciones para pruebas A/B), almacenarlos en caché utilizando herramientas CDN es una tarea que se puede resolver, pero es mucho más compleja. Servicios como Commanders Act, una solución de gestión de etiquetas, utilizan webhooks al publicar nuevas versiones. Esto le brinda la posibilidad de forzar un vaciado de caché en la CDN o, mejor aún, la capacidad de forzar una actualización de hash o URL.
▍Entrega adaptativa de materiales a clientes
Además, cuando hablamos de almacenamiento en caché, debemos tener en cuenta el hecho de que la configuración de almacenamiento en caché utilizada en la CDN puede no ser adecuada para algunos recursos de terceros. Por ejemplo, dichos recursos pueden utilizar tecnología de rastreo de agentes de usuario (servicio adaptativo) para ofrecer a navegadores específicos versiones de contenido optimizadas específicamente para esos navegadores. Estas tecnologías se basan en expresiones regulares o una base de datos de información de encabezado HTTP para determinar las capacidades del navegador. User-Agent. Una vez que saben con qué navegador están tratando, le entregan materiales diseñados para ello.
Aquí puedes recordar dos servicios. El primero es googlefonts.com. El segundo es polyfill.io. El servicio Google Fonts proporciona, para un determinado recurso, varios códigos CSS, dependiendo de las capacidades del navegador (proporcionando enlaces a recursos woff2 usando unicode-range).
Estos son los resultados de un par de consultas de Google Fonts realizadas desde diferentes navegadores.
Resultado de la consulta de Google Fonts desde Chrome
Resultado de la consulta de Google Fonts ejecutada desde IE10
Polyfill.io le proporciona al navegador sólo los polyfills que necesita. Esto se hace por motivos de rendimiento.
Por ejemplo, echemos un vistazo a lo que sucede si ejecuta la siguiente solicitud desde diferentes navegadores:
En respuesta a dicha solicitud ejecutada desde IE10, se recibirán 34 KB de datos. Y la respuesta, ejecutada desde Chrome, estará vacía.
Enojado: algunas consideraciones de privacidad
Este punto es el último en orden, pero no el menos importante. La cuestión es que el autohospedaje de recursos de terceros en el dominio principal del proyecto o en su subdominio puede poner en peligro la privacidad de los usuarios y afectar negativamente al proyecto web principal.
Si su sistema CDN no está configurado correctamente, puede terminar enviando las cookies de su dominio a un servicio de terceros. Si no se organiza un filtrado adecuado a nivel de CDN, entonces las cookies de sesión, que normalmente no se pueden utilizar en JavaScript (con el httponly), puede enviarse a un servidor extranjero.
Esto es exactamente lo que puede pasar con trackers como Eulerian o Criteo. Es posible que los rastreadores de terceros hayan establecido un identificador único en la cookie. Si formaran parte de los materiales del sitio, podrían leer el identificador a su discreción mientras el usuario trabajaba con diferentes recursos web.
Hoy en día, la mayoría de los navegadores incluyen protección contra este tipo de comportamiento de seguimiento. Como resultado, los rastreadores ahora utilizan tecnología. , haciéndose pasar por sus propios guiones para varios proyectos. Es decir, los rastreadores ofrecen a los propietarios de sitios agregar un CNAME a su configuración para un determinado dominio, cuya dirección generalmente parece un conjunto aleatorio de caracteres.
Aunque no se recomienda que las cookies de los sitios web estén disponibles para todos los subdominios (por ejemplo, *.website.com), muchos sitios lo hacen. En este caso, dichas cookies se envían automáticamente a un rastreador externo encubierto. Como resultado, ya no podemos hablar de privacidad.
Además, ocurre lo mismo con las cabeceras HTTP. , que se envían únicamente al dominio principal, ya que se pueden utilizar para crear usuario. Asegúrese de que el servicio CDN que utiliza filtre estos encabezados correctamente.
resultados
Si planea implementar pronto el autohospedaje 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 fallas del sitio o degradación del rendimiento debido a que un recurso vital para el sitio no esté disponible debido a fallas de un servicio de terceros.
- Antes de almacenar en caché recursos de terceros en una CDN, asegúrese de que se utilice algún tipo de sistema de control de versiones al nombrar sus archivos, o de que pueda administrar el ciclo de vida de estos recursos restableciendo manual o automáticamente la caché de la CDN al publicar una nueva versión de la secuencia de comandos.
- Tenga mucho cuidado con la configuración de su CDN, servidor proxy y caché. Esto le permitirá evitar que su proyecto o encabezados reciban cookies.
Client-Hintsservicios de terceros.
Estimados lectores! ¿Alojas en tus servidores materiales de otras personas que son extremadamente importantes para el funcionamiento de tus proyectos?
Fuente: habr.com