Nos últimos anos, cada vez mais plataformas para otimizar projetos front-end oferecem oportunidades de auto-hospedagem ou proxy de recursos de terceiros. Akamai permite que você defina para URLs autogerados. Cloudflare possui tecnologia Edge Workers. Fasterzine pode URLs nas páginas para que apontem para recursos de terceiros localizados 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 poderia ser melhorado, então provavelmente você está pensando em usar proxy para tais serviços. Com essa abordagem, você pode aproximar esses recursos de seus usuários e obter controle mais completo sobre seu cache no lado do cliente. Além disso, isso permite proteger os usuários de problemas causados pela “travamento” de um serviço de terceiros ou degradação de seu desempenho.
Bom: melhor desempenho
A auto-hospedagem dos recursos de outra pessoa melhora o desempenho de uma forma muito óbvia. O navegador não precisa acessar o DNS novamente, não precisa estabelecer uma conexão TCP e realizar um handshake TLS em um domínio de terceiros. Você pode ver como a auto-hospedagem dos recursos de outra pessoa afeta o desempenho comparando as duas figuras a seguir.
Recursos de terceiros são baixados de fontes externas (retirados de )
Os recursos de terceiros são armazenados no mesmo local que o restante dos materiais do site (retirados de )
A situação também é melhorada pelo fato de o navegador utilizar a capacidade de multiplexar e priorizar dados da conexão HTTP/2 já estabelecida com o domínio principal.
Se você não hospedar recursos de terceiros, como eles serão carregados de um domínio diferente do principal, eles não poderão ser priorizados. Isso fará com que eles concorram entre si pela largura de banda do cliente. Isso pode resultar em tempos de carregamento de conteúdo crítico para a construção de uma página que é muito mais longo do que seria possível em circunstâncias ideais. fale sobre priorização HTTP/2 que explica tudo isso muito bem.
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 domínios diferentes, isso poderá sobrecarregar a linha de comunicação no momento mais crucial.
Se você mesmo hospedar recursos de terceiros, poderá controlar exatamente como esses recursos serão fornecidos ao cliente. Ou seja, estamos falando sobre o seguinte:
- Você pode garantir que seja usado o algoritmo de compactação de dados que melhor se adapta a cada navegador (Brotli/gzip).
- Você pode aumentar o tempo de armazenamento em cache para recursos que normalmente não são particularmente longos, mesmo com os provedores mais conhecidos (por exemplo, o valor correspondente para a tag GA é definido como 30 minutos).
Você pode até estender o TTL de um recurso para, digamos, um ano, incorporando conteúdo relevante em sua estratégia de gerenciamento de cache (hashes de URL, controle de versão, etc.). Falaremos sobre isso abaixo.
▍Proteção contra interrupções no funcionamento de serviços de terceiros ou seu desligamento
Outro aspecto interessante da auto-hospedagem de recursos de terceiros é que ela permite mitigar os riscos associados a interrupções de serviços de terceiros. Vamos supor que a solução de teste A/B de terceiros que você está usando seja implementada como um script de bloqueio que é carregado na seção principal da página. Este script carrega lentamente. Se o script correspondente não for carregado, a página ficará vazia. Se demorar muito para carregar, a página aparecerá com um grande atraso. Ou suponha que o projeto use uma biblioteca baixada de um recurso CDN de terceiros. Vamos imaginar que esse recurso falhou ou foi bloqueado em um determinado país. Tal situação levará a uma violação da lógica do site.
Para saber como seu site funciona quando algum serviço externo está indisponível, você pode usar a seção SPOF em .
Seção SPOF em webpagetest.org
▍E quanto a problemas com cache de materiais em navegadores? (dica: é um mito)
Você pode pensar que o uso de CDNs públicos levaria automaticamente a um melhor desempenho dos recursos, uma vez que esses serviços têm redes de qualidade bastante alta e são distribuídos em todo o mundo. Mas na verdade tudo é um pouco mais complicado.
Digamos que temos vários sites diferentes: website1.com, website2.com, website3.com. Todos esses sites usam a biblioteca jQuery. Nós o conectamos a eles usando um CDN, por exemplo - googleapis.com. Você pode esperar que o navegador baixe e armazene a biblioteca em cache uma vez e, em seguida, use-a em todos os três sites. Isso pode reduzir a carga na rede. Talvez isso permita que você economize dinheiro em algum lugar e ajude a melhorar o desempenho dos recursos. Do ponto de vista prático, tudo parece diferente. Por exemplo, o Safari tem um recurso chamado : o cache usa chaves duplas com base na origem do documento e na origem do recurso de terceiros. bom artigo sobre este assunto.
estudos antigos и , bem como mais recentes Paul Calvano, mostram que os recursos não são armazenados nos caches do navegador pelo tempo que poderíamos esperar: “Há uma lacuna séria entre o tempo de armazenamento em cache dos recursos próprios de um projeto e de terceiros. Estamos falando de CSS e fontes da web. Ou seja, 95% das fontes nativas têm uma vida útil de cache de mais de uma semana, enquanto 50% das fontes de terceiros têm uma vida útil de cache inferior a uma semana! Isso dá aos desenvolvedores da web um motivo convincente para hospedar eles próprios arquivos de fontes!”
Como resultado, se você hospedar conteúdo de outras pessoas, não notará nenhum problema de desempenho causado pelo cache do navegador.
Agora que cobrimos os pontos fortes da auto-hospedagem de terceiros, vamos falar sobre como diferenciar uma boa implementação dessa abordagem de uma ruim.
O ruim: o diabo está nos detalhes
A movimentação de recursos de terceiros para o seu próprio domínio não pode ser feita automaticamente sem garantir que esses recursos sejam armazenados em cache adequadamente.
Um dos principais problemas aqui é o tempo de armazenamento em cache. Por exemplo, as informações de versão estão incluídas em nomes de scripts de terceiros como este: jquery-3.4.1.js. Esse arquivo não será alterado no futuro e, como resultado, não causará problemas com seu cache.
Mas se algum esquema de controle de versão não for usado ao trabalhar com arquivos, os scripts em cache, cujo conteúdo muda enquanto o nome do arquivo permanece inalterado, podem ficar desatualizados. Isso pode ser um problema sério, pois, por exemplo, não permite a adição de patches de segurança automatizados aos scripts que os clientes precisam receber o mais rápido possível. O desenvolvedor terá que fazer um esforço para atualizar tais scripts no cache. Além disso, isso pode causar falhas no aplicativo devido ao fato de o código do cache usado no cliente ser diferente da versão mais recente do código para o qual a parte do servidor do projeto foi projetada.
É verdade que se falamos de materiais que são atualizados com frequência (gerenciadores de tags, soluções para testes A/B), então armazená-los em cache usando ferramentas CDN é uma tarefa que pode ser resolvida, mas é muito mais complexa. Serviços como o Commanders Act, uma solução de gerenciamento de tags, usam webhooks ao publicar novas versões. Isso permite forçar uma liberação de cache no CDN ou, melhor ainda, forçar uma atualização de hash ou URL.
▍Entrega adaptativa de materiais aos clientes
Além disso, quando falamos em cache, precisamos levar em consideração o fato de que as configurações de cache utilizadas na CDN podem não ser adequadas para alguns recursos de terceiros. Por exemplo, esses recursos podem usar tecnologia de detecção de agente de usuário (serviço adaptativo) para servir navegadores específicos com versões de conteúdo otimizadas especificamente para esses navegadores. Essas tecnologias dependem de expressões regulares ou de um banco de dados de informações de cabeçalho HTTP para descobrir os recursos do navegador. User-Agent. Depois de saberem com qual navegador estão lidando, eles fornecem materiais projetados para ele.
Aqui você pode lembrar dois serviços. O primeiro é googlefonts.com. O segundo é polyfill.io. O serviço Google Fonts fornece, para um determinado recurso, vários códigos CSS, dependendo das capacidades do navegador (fornecendo links para recursos woff2 usando unicode-range).
Aqui estão os resultados de algumas consultas do Google Fonts feitas em diferentes navegadores.
Resultado da consulta do Google Fonts do Chrome
Resultado da consulta do Google Fonts executada no IE10
Polyfill.io fornece ao navegador apenas os polyfills necessários. Isso é feito por motivos de desempenho.
Por exemplo, vamos dar uma olhada no que acontece se você executar a seguinte solicitação em navegadores diferentes:
Em resposta a tal solicitação executada no IE10, serão recebidos 34 KB de dados. E a resposta, executada no Chrome, estará vazia.
Irritado: algumas considerações sobre privacidade
Este ponto é o último da ordem, mas não menos importante. A questão é que a auto-hospedagem de recursos de terceiros no domínio principal do projeto ou em seu subdomínio pode comprometer a privacidade dos usuários e afetar negativamente o projeto web principal.
Se o seu sistema CDN não estiver configurado corretamente, você poderá enviar os cookies do seu domínio para um serviço de terceiros. Se a filtragem adequada não for organizada no nível do CDN, então seus cookies de sessão, que normalmente não podem ser usados em JavaScript (com o httponly), pode ser enviado para um host estrangeiro.
Isto é exatamente o que pode acontecer com rastreadores como Eulerian ou Criteo. Rastreadores de terceiros podem ter definido um identificador exclusivo no cookie. Se fizessem parte dos materiais do site, poderiam ler o identificador a seu critério enquanto o usuário estivesse trabalhando com diferentes recursos da web.
Hoje em dia, a maioria dos navegadores inclui proteção contra esse tipo de comportamento do rastreador. Como resultado, os rastreadores agora usam tecnologia , disfarçando-se de seus próprios roteiros para vários projetos. Ou seja, os rastreadores oferecem aos proprietários de sites a adição de um CNAME às configurações de um determinado domínio, cujo endereço geralmente se parece com um conjunto aleatório de caracteres.
Embora não seja recomendado disponibilizar cookies de sites para todos os subdomínios (por exemplo - *.website.com), muitos sites fazem isso. Neste caso, esses cookies são enviados automaticamente para um rastreador de terceiros disfarçado. Como resultado, não podemos mais falar sobre privacidade.
Além disso, a mesma coisa acontece com cabeçalhos HTTP , que são enviados apenas para o domínio principal, pois podem ser usados para criar do utilizador. Certifique-se de que o serviço CDN usado filtre esses cabeçalhos corretamente.
Resultados de
Se você está planejando implementar a auto-hospedagem de recursos de terceiros em breve, deixe-me dar alguns conselhos:
- Hospede suas bibliotecas JS, fontes e arquivos CSS mais importantes. Isso reduzirá o risco de falha do site ou degradação do desempenho devido à indisponibilidade de um recurso vital para o site devido à falha de um serviço de terceiros.
- Antes de armazenar recursos de terceiros em cache em uma CDN, certifique-se de que algum tipo de sistema de controle de versão seja usado ao nomear seus arquivos ou que você possa gerenciar o ciclo de vida desses recursos redefinindo manual ou automaticamente o cache da CDN ao publicar uma nova versão do o roteiro.
- Tenha muito cuidado com suas configurações de CDN, servidor proxy e cache. Isso permitirá que você evite que seu projeto ou cabeçalhos recebam cookies
Client-Hintsserviços terceirizados.
Caros leitores! Você hospeda em seus servidores materiais de outras pessoas que são extremamente importantes para o funcionamento de seus projetos?
Fonte: habr.com