Nos últimos anos, cada vez mais plataformas para otimização de projetos frontend oferecem opções de auto-hospedagem ou proxy de recursos de terceiros. A Akamai permite definir para URLs criados de forma independente. O Cloudflare possui a tecnologia Edge Workers. O Fasterzine pode URLs nas páginas de modo que elas apontem para recursos de terceiros que estão no domínio principal do site.
Se você sabe que os serviços de terceiros usados em seu projeto não mudam com muita frequência, e que o processo de entrega deles aos clientes pode ser melhorado, você provavelmente está pensando em proxy para esses serviços. Com essa abordagem, você pode "aproximar" esses recursos dos usuários e obter um controle mais completo sobre seu caching no lado do cliente. Isso, além disso, protege os usuários contra problemas causados pela "queda" de um serviço de terceiros ou degradação de seu desempenho.
Bom: aumento de desempenho
A auto-hospedagem de recursos de terceiros melhora o desempenho de maneira bastante óbvia. O navegador não precisa consultar o DNS mais uma vez, não precisa estabelecer uma conexão TCP e realizar uma negociação TLS em um domínio diferente. O impacto da auto-hospedagem de recursos de terceiros sobre o desempenho pode ser visto comparando os dois gráficos a seguir.
Recursos de terceiros são carregados de fontes externas (extraído )
Recursos de terceiros são armazenados junto com outros materiais do site (extraído )
A situação é ainda melhorada pelo fato de que o navegador usará as capacidades de multiplexação e priorização de dados da conexão HTTP/2, que já está estabelecida com o domínio principal.
Se não hospedar recursos de terceiros, como eles serão carregados de um domínio diferente do principal, não será possível priorizá-los. Isso levará a uma competição entre eles pela largura de banda do cliente. Isso pode resultar em um tempo de carregamento de materiais críticos para a formação da página muito maior do que o tempo que poderia ser alcançado em circunstâncias ideais. apresentação sobre priorização HTTP/2, na qual tudo isso é muito bem elucidado.
Pode-se supor que o uso de atributos em links para recursos externos preconnect ajudará a resolver o problema. No entanto, se houver muitos desses links para diferentes domínios, isso pode, na verdade, sobrecarregar a linha de comunicação no momento mais crucial.
Se hospedar recursos de terceiros de forma independente - você pode controlar exatamente como esses recursos são entregues ao cliente. Ou seja, estamos falando do seguinte:
- É possível garantir a aplicação de um algoritmo de compressão de dados mais adequado para cada navegador (Brotli/gzip).
- É possível aumentar o tempo de cache dos recursos, que geralmente, mesmo nos provedores mais conhecidos, não é particularmente grande (por exemplo, o valor correspondente para a tag GA está definido em 30 minutos).
Você pode até aumentar o indicador TTL para o recurso, por exemplo, para um ano, incluindo os materiais correspondentes em sua estratégia de gerenciamento de cache (hashes de URL, versionamento e assim por diante). Vamos falar sobre isso mais adiante.
▍Proteção contra interrupções em serviços de terceiros ou sua desativação
Outro aspecto interessante da auto-hospedagem de recursos de terceiros é que ela ajuda a mitigar os riscos associados a interrupções nos serviços de terceiros. Suponha que a solução de terceiros que você está usando para realizar testes A/B seja implementada como um script bloqueador carregado no cabeçalho da página. Este script é carregado lentamente. Se o script não conseguir ser carregado, a página ficará vazia. Se levar muito tempo para carregar, a página aparecerá com um grande atraso. Ou, suponha que um projeto use uma biblioteca que é carregada de um recurso CDN de terceiros. Imagine que esse recurso falhou ou foi bloqueado em algum país. Tal situação levará a uma interrupção na lógica do site.
Para saber como seu site funciona na falta de um determinado serviço externo, você pode usar a seção SPOF em .
Seção SPOF em webpagetest.org
▍E quanto a problemas com o cache de materiais nos navegadores? (dica: isso é um mito)
Pode-se pensar que o uso de CDNs públicas leva automaticamente a um melhor desempenho dos recursos, uma vez que esses serviços têm redes de qualidade e estão distribuídos pelo mundo. Contudo, as coisas são um pouco mais complicadas.
Suponha que temos vários sites diferentes: website1.com, website2.com, website3.com. Todos esses sites utilizam a biblioteca jQuery. A conectamos a eles através de um CDN, por exemplo — googleapis.com. Poder-se-ia esperar que o navegador fizesse o download e armazenasse em cache a biblioteca uma vez e, em seguida, a utilizasse em todos os três sites. Isso poderia reduzir a carga na rede. Talvez isso economize em algum lugar e ajude a melhorar o desempenho dos recursos. Na prática, no entanto, a situação é diferente. Por exemplo, no Safari, existe uma funcionalidade chamada : no cache, são usados chaves duplas, baseadas na origem do documento e na origem do recurso externo. um bom artigo sobre esse assunto.
Pesquisas antigas e , assim como um estudo mais recente de Pola Calvano, mostram que os recursos não são armazenados em caches de navegadores por tanto tempo quanto poderíamos esperar: "Há uma grande disparidade entre o tempo de cache de recursos próprios e de terceiros do projeto. Isso se refere a CSS e fontes web. Especificamente, o tempo de cache de 95% das fontes próprias excede uma semana, enquanto o tempo de cache de 50% das fontes de terceiros é inferior a uma semana! Isso dá aos desenvolvedores web boas razões para hospedar arquivos de fontes por conta própria!".
Como resultado, se você hospedar materiais de terceiros, não perceberá os problemas de desempenho causados pelo cache do navegador.
Agora que analisamos os pontos fortes da hospedagem autônoma de recursos externos, vamos discutir como distinguir uma boa implementação dessa abordagem de uma ruim.
Ruim: o diabo está nos detalhes
Mover recursos externos para seu próprio domínio não pode ser feito automaticamente, sem garantir o cache correto desses recursos.
Um dos principais problemas aqui é o tempo de armazenamento em cache. Por exemplo, informações sobre versões são incluídas nos nomes de scripts externos mais ou menos assim: jquery-3.4.1.js. Esse arquivo não será alterado no futuro, o que não causará problemas com seu cache.
Mas, se não houver um esquema de versionamento ao trabalhar com arquivos, os scripts armazenados em cache, cujo conteúdo muda com o nome do arquivo inalterado, podem ficar desatualizados. Isso pode se tornar um problema sério, pois, por exemplo, não permite aplicar correções de segurança automaticamente nos scripts, que devem ser feitas o mais rápido possível para que os clientes as recebam. O desenvolvedor terá que se esforçar para atualizar esses scripts no cache. Além disso, isso pode causar falhas no desempenho do aplicativo, pois o código usado no cliente a partir do cache difere da versão mais recente do código, para a qual a parte do servidor do projeto foi projetada.
Na verdade, quando se fala em materiais frequentemente atualizados (gerenciadores de tags, soluções para testes A/B), o armazenamento em cache por meio de CDN é uma tarefa que, embora viável, é muito mais complexa. Serviços como Commanders Act, soluções de gerenciamento de tags, utilizam webhooks ao publicar novas versões. Isso permite organizar a limpeza do cache na CDN ou, melhor ainda, possibilitar a atualização do hash ou versão da URL.
▍Entrega adaptativa de materiais aos clientes
Além disso, ao falar sobre cache, é preciso considerar que as configurações de cache usadas na CDN podem não ser adequadas para alguns recursos de terceiros. Por exemplo, esses recursos podem usar a tecnologia de sniffing do agente do usuário (user agent sniffing, adaptive serving) para fornecer versões de materiais otimizadas especificamente para determinados navegadores. Essas tecnologias, para determinar as capacidades do navegador, dependem de expressões regulares ou de um banco de dados que contém informações sobre os cabeçalhos HTTP. User-Agent. Ao descobrir com qual navegador estão lidando, eles enviam materiais projetados para ele.
Aqui vale a pena lembrar de dois serviços. O primeiro é googlefonts.com. O segundo é polyfill.io. O serviço Google Fonts fornece, para um determinado recurso, diferentes códigos CSS, dependendo das capacidades do navegador (oferecendo links para recursos woff2, utilizando unicode-range).
Aqui estão os resultados de algumas solicitações ao Google Fonts, realizadas a partir de diferentes navegadores.
Resultado da solicitação para Google Fonts, realizada a partir do Chrome
Resultado da solicitação para Google Fonts, realizada a partir do IE10
O Polyfill.io fornece ao navegador apenas os polyfills necessários. Isso é feito por motivos de desempenho.
Por exemplo, vamos observar o que acontece se realizarmos a seguinte solicitação a partir de diferentes navegadores:
Em resposta a essa solicitação, realizada a partir do IE10, virão 34 KB de dados. Já a resposta a ela, realizada a partir do Chrome, será vazia.
Maléfico: algumas considerações sobre privacidade
Este ponto é o último em ordem, mas não em importância. Trata-se do fato de que a hospedagem independente de recursos de terceiros no domínio principal do projeto ou em seu subdomínio pode comprometer a privacidade dos usuários e impactar negativamente o projeto web principal.
Se seu sistema de CDN estiver configurado incorretamente, pode acabar que você estará enviando cookies do seu domínio para um serviço de terceiros. Se não houver uma filtragem adequada a nível de CDN, seus cookies de sessão, que em condições normais não podem ser acessados em JavaScript (com o atributo httponly), podem ser enviados para um host externo.
É exatamente isso que pode acontecer com rastreadores como Eulerian ou Criteo. Rastreadores de terceiros podem ter configurado um identificador único em cookies. Se estivessem incluídos nos materiais dos sites, poderiam ler o identificador como quisessem durante a interação do usuário com diferentes recursos web.
Hoje em dia, a maioria dos navegadores inclui proteção contra esse comportamento dos rastreadores. Como resultado, agora os rastreadores utilizam a tecnologia , se disfarçando como scripts próprios de diversos projetos. Mais especificamente, os rastreadores oferecem aos proprietários de sites adicionar em suas configurações um CNAME para algum domínio, cujo endereço geralmente parece um conjunto aleatório de caracteres.
Embora não seja recomendável tornar os cookies do site acessíveis a todos os subdomínios (por exemplo — *.website.com), isso é feito em muitos sites. Nesse caso, esses cookies são automaticamente enviados para o rastreador externo disfarçado. Como resultado, já não se pode falar em privacidade.
Além disso, o mesmo acontece com os cabeçalhos HTTP , que são enviados apenas ao domínio principal, uma vez que podem ser utilizados para criação do usuário. Certifique-se de que o serviço de CDN que você está usando filtre corretamente esses cabeçalhos.
Resultados
Se você planeja implementar em breve o self-hosting de recursos de terceiros — deixe-me dar algumas dicas:
- Hospede suas bibliotecas JS, fontes e arquivos CSS mais importantes. Isso reduzirá o risco de falhas do site ou diminuição de sua performance devido à indisponibilidade de um recurso vital por conta de um serviço de terceiros.
- Antes de armazenar em cache recursos de terceiros na CDN, assegure-se de que há um sistema de versionamento nos nomes dos arquivos ou que você consiga controlar o ciclo de vida desses recursos, limpando o cache da CDN manualmente ou automaticamente ao publicar uma nova versão do script.
- Preste muita atenção nas configurações da CDN, proxy e cache. Isso o ajudará a evitar o envio de cookies do seu projeto ou cabeçalhos
Client-Hintspara serviços de terceiros.
Prezados leitores! Você hospeda em seus servidores materiais de terceiros que são extremamente importantes para o funcionamento de seus projetos?
Fonte: habr.com
