Nos últimos anos, cada vez son máis as plataformas de optimización de proxectos front-end que ofrecen oportunidades de autoaloxamento ou proxy de recursos de terceiros. Akamai permíteche configurar para URL xerados por si mesmo. Cloudflare ten tecnoloxía Edge Workers. Fasterzine pode URL nas páxinas para que apunten a recursos de terceiros situados no dominio principal do sitio.
Se sabes que os servizos de terceiros que se usan no teu proxecto non cambian con moita frecuencia e que o proceso de entrega dos mesmos aos clientes podería mellorarse, entón probablemente estea pensando en proxy. Con este enfoque, podes achegar estes recursos aos teus usuarios e obter un control máis completo sobre a súa caché no lado do cliente. Isto, ademais, permítelle protexer aos usuarios dos problemas causados pola "falla" dun servizo de terceiros ou pola degradación do seu rendemento.
Bo: rendemento mellorado
O auto-aloxamento dos recursos doutra persoa mellora o rendemento dun xeito moi obvio. O navegador non precisa acceder de novo ao DNS, non é necesario establecer unha conexión TCP e realizar un apretón de contactos TLS nun dominio de terceiros. Podes ver como afecta o rendemento o autoaloxamento dos recursos doutra persoa comparando as dúas figuras seguintes.
Os recursos de terceiros descárganse de fontes externas (tomado de )
Os recursos de terceiros almacénanse no mesmo lugar que o resto dos materiais do sitio (tomado de )
A situación tamén se ve mellorada polo feito de que o navegador utilizará a capacidade de multiplexar e priorizar os datos da conexión HTTP/2 que xa se estableceu co dominio principal.
Se non aloxa recursos de terceiros, xa que se cargarán desde un dominio diferente do principal, non se poden priorizar. Isto fará que compitan entre si polo ancho de banda do cliente. Isto pode producir tempos de carga de contidos críticos para construír unha páxina que sexa moito máis longo do que sería posible en circunstancias ideais. falar sobre a priorización HTTP/2 que explica moi ben todo isto.
Pódese supoñer que o uso de atributos en ligazóns a recursos externos preconnect axudará a resolver o problema. Non obstante, se hai demasiadas ligazóns deste tipo a diferentes dominios, pode sobrecargar a liña de comunicación no momento máis crucial.
Se vostede mesmo aloxa recursos de terceiros, pode controlar exactamente como se dan estes recursos ao cliente. É dicir, estamos a falar do seguinte:
- Podes asegurarte de que se utiliza o algoritmo de compresión de datos que mellor se adapta a cada navegador (Brotli/gzip).
- Pode aumentar o tempo de almacenamento na caché dos recursos que normalmente non son especialmente longos, mesmo cos provedores máis coñecidos (por exemplo, o valor correspondente para a etiqueta GA está definido en 30 minutos).
Incluso pode ampliar o TTL dun recurso a, por exemplo, un ano incorporando contido relevante á súa estratexia de xestión de caché (hash de URL, versións, etc.). Disto falaremos a continuación.
▍Protección contra interrupcións no funcionamento dos servizos de terceiros ou a súa parada
Outro aspecto interesante do autoaloxamento de recursos de terceiros é que permite mitigar os riscos asociados ás interrupcións dos servizos de terceiros. Supoñamos que a solución de proba A/B de terceiros que está a usar está implementada como un script de bloqueo que se carga na sección de cabeceira da páxina. Este script cárgase lentamente. Se non se carga o script correspondente, a páxina estará baleira. Se tarda moito tempo en cargarse, a páxina aparecerá con moito atraso. Ou, supoña que o proxecto usa unha biblioteca descargada dun recurso CDN de terceiros. Imaxinemos que este recurso sufriu un fallo ou quedou bloqueado nun determinado país. Tal situación levará a unha violación da lóxica do sitio.
Para saber como funciona o teu sitio cando algún servizo externo non está dispoñible, podes usar a sección SPOF sobre .
Sección SPOF en webpagetest.org
▍E os problemas coa caché de materiais nos navegadores? (suxestión: é un mito)
Poderías pensar que o uso de CDN públicos levaría automaticamente a un mellor rendemento dos recursos, xa que estes servizos teñen redes de bastante alta calidade e distribúense por todo o mundo. Pero en realidade todo é un pouco máis complicado.
Digamos que temos varios sitios diferentes: website1.com, website2.com, website3.com. Todos estes sitios usan a biblioteca jQuery. Conectámolo a eles mediante unha CDN, por exemplo, googleapis.com. Podes esperar que o navegador descargue e almacene a biblioteca unha vez, e despois utilízaa nos tres sitios. Isto podería reducir a carga na rede. Quizais isto che permita aforrar diñeiro nalgún lugar e axudarche a mellorar o rendemento dos recursos. Desde o punto de vista práctico, todo parece diferente. Por exemplo, Safari ten unha función chamada : A caché usa chaves duais baseadas na orixe do documento e na fonte do recurso de terceiros. bo artigo sobre este tema.
estudos antigos и , así como máis recentes Paul Calvano, mostran que os recursos non se almacenan nas cachés do navegador durante o tempo que poderíamos esperar: “Hai unha brecha seria entre o tempo de almacenamento na caché dos recursos propios dun proxecto e de terceiros. Estamos a falar de CSS e fontes web. É dicir, o 95 % das fontes nativas teñen unha vida útil de caché de máis dunha semana, mentres que o 50 % das fontes de terceiros teñen unha vida útil de caché de menos dunha semana. Isto dá aos desenvolvedores web unha razón convincente para aloxar ficheiros de fontes eles mesmos!
Como resultado, se aloxa contido doutras persoas, non notará ningún problema de rendemento causado pola memoria caché do navegador.
Agora que cubrimos os puntos fortes do autoaloxamento de terceiros, imos falar sobre como diferenciar unha boa implementación deste enfoque dunha mala.
The Bad: O demo está nos detalles
O traslado de recursos de terceiros ao teu propio dominio non se pode facer automaticamente sen garantir que tales recursos estean correctamente almacenados na memoria caché.
Un dos principais problemas aquí é o tempo de almacenamento na caché. Por exemplo, a información de versión inclúese en nomes de script de terceiros como este: jquery-3.4.1.js. Este ficheiro non cambiará no futuro e, como resultado, non causará ningún problema coa súa caché.
Pero se non se usa algún esquema de versións cando se traballa con ficheiros, os scripts almacenados na caché, cuxo contido cambia mentres o nome do ficheiro permanece inalterado, poden quedar obsoletos. Isto pode ser un problema grave, xa que, por exemplo, non permite engadir parches de seguridade automatizados aos scripts que os clientes necesitan recibir o máis rápido posible. O programador terá que facer un esforzo para actualizar estes scripts na caché. Ademais, isto pode provocar fallos na aplicación debido ao feito de que o código usado no cliente da caché é diferente da versión máis recente do código para a que está deseñada a parte do servidor do proxecto.
É certo que se falamos de materiais que se actualizan con frecuencia (xestores de etiquetas, solucións para probas A/B), almacenalos en caché mediante ferramentas CDN é unha tarefa que se pode resolver, pero é moito máis complexa. Servizos como Commanders Act, unha solución de xestión de etiquetas, usan webhooks ao publicar novas versións. Isto dálle a posibilidade de forzar un vaciado da caché no CDN ou, mellor aínda, a capacidade de forzar unha actualización de hash ou URL.
▍Entrega adaptativa de materiais aos clientes
Ademais, cando falamos de caché, hai que ter en conta o feito de que a configuración de caché utilizada no CDN pode non ser axeitada para algúns recursos de terceiros. Por exemplo, estes recursos poden utilizar a tecnoloxía de rastrexo de axente de usuario (servizo adaptativo) para servir navegadores específicos con versións de contido optimizadas especificamente para eses navegadores. Estas tecnoloxías dependen de expresións regulares, ou dunha base de datos de información de cabeceira HTTP, para descubrir as capacidades do navegador. User-Agent. Unha vez que saben con que navegador están a tratar, danlle materiais deseñados para iso.
Aquí podes lembrar dous servizos. O primeiro é googlefonts.com. O segundo é polyfill.io. O servizo Google Fonts proporciona, para un determinado recurso, varios códigos CSS, dependendo das capacidades do navegador (dando ligazóns a recursos woff2 usando unicode-range).
Aquí están os resultados dun par de consultas de Google Fonts feitas desde diferentes navegadores.
Resultado da consulta de Google Fonts de Chrome
Resultado da consulta de Google Fonts executada desde IE10
Polyfill.io dálle ao navegador só os polyfills que necesita. Isto faise por razóns de rendemento.
Por exemplo, vexamos o que ocorre se executas a seguinte solicitude desde diferentes navegadores:
En resposta a tal solicitude executada desde IE10, recibiranse 34 KB de datos. E a resposta a ela, executada desde Chrome, estará baleira.
Enfadado: algunhas consideracións de privacidade
Este punto é o último en orde, pero non menos importante. A cuestión é que o autoaloxamento de recursos de terceiros no dominio principal do proxecto ou no seu subdominio pode poñer en perigo a privacidade dos usuarios e afectar negativamente ao proxecto web principal.
Se o teu sistema CDN non está configurado correctamente, podes acabar enviando as cookies do teu dominio a un servizo de terceiros. Se non se organiza o filtrado adecuado a nivel de CDN, entón as cookies de sesión, que en condicións normais non se poden usar en JavaScript (coa httponly), pódese enviar a un host estranxeiro.
Isto é exactamente o que pode ocorrer con rastreadores como Eulerian ou Criteo. Os rastreadores de terceiros poden ter establecido un identificador único na cookie. Se formasen parte dos materiais do sitio, podían ler o identificador segundo o seu criterio mentres o usuario traballaba con diferentes recursos web.
Hoxe en día, a maioría dos navegadores inclúen protección contra este tipo de comportamento do rastreador. Como resultado, os rastreadores agora usan tecnoloxía , disfrazados de guións propios para varios proxectos. É dicir, os rastreadores ofrecen aos propietarios dos sitios engadir un CNAME á súa configuración para un determinado dominio, cuxo enderezo adoita parecer un conxunto aleatorio de caracteres.
Aínda que non se recomenda poñer as cookies de sitios web dispoñibles para todos os subdominios (por exemplo, *.website.com), moitos sitios fan isto. Neste caso, tales cookies envíanse automaticamente a un rastreador de terceiros disfrazado. Como resultado, xa non podemos falar de ningunha privacidade.
Ademais, ocorre o mesmo coas cabeceiras HTTP , que se envían só ao dominio principal, xa que se poden usar para crear usuario. Asegúrate de que o servizo CDN que utilizas filtra estes encabezados correctamente.
Resultados de
Se planeas implementar pronto o autoaloxamento de recursos de terceiros, permíteme darche algúns consellos:
- Aloxa as túas bibliotecas JS, fontes e ficheiros CSS máis importantes. Isto reducirá o risco de fallo do sitio ou de degradación do rendemento debido a que un recurso vital para o sitio non está dispoñible por culpa dun servizo de terceiros.
- Antes de almacenar na caché recursos de terceiros nunha CDN, asegúrese de que se utiliza algún tipo de sistema de control de versións ao nomear os seus ficheiros ou de que pode xestionar o ciclo de vida destes recursos restablecendo manualmente ou automaticamente a caché da CDN ao publicar unha nova versión de o guión.
- Teña moito coidado coa súa configuración de CDN, servidor proxy e caché. Isto permitirache evitar que o teu proxecto ou cabeceiras se envíen cookies
Client-Hintsservizos de terceiros.
Queridos lectores! Aloxa nos seus servidores materiais alleos que son moi importantes para o funcionamento dos seus proxectos?
Fonte: www.habr.com