Nos últimos anos, mais e mais plataformas para otimizar projetos front-end oferecem oportunidades para hospedagem ou proxy independentes de recursos de terceiros. O Akamai permite definir
parâmetros específicos para URLs geradas automaticamente. O Cloudflare possui a tecnologia Edge Workers. O Fasterzine pode
reescrever URLs nas páginas para que aponte para recursos de terceiros localizados no domínio principal do site.
Se você souber que os serviços de terceiros usados no seu projeto não mudam com muita frequência e que o processo de entrega aos clientes pode ser aprimorado, provavelmente você pensa em fazer um proxy desses serviços. Com essa abordagem, você pode "aproximar" esses recursos dos usuários e obter mais controle sobre o armazenamento em cache no lado do cliente. Além disso, isso permite proteger os usuários contra problemas causados pela "queda" de um serviço de terceiros ou pela degradação de seu desempenho.
Bom: aumento da produtividade
A hospedagem automática dos recursos de outras pessoas melhora o desempenho de uma maneira muito óbvia. O navegador não precisa acessar o DNS novamente, não precisa estabelecer uma conexão TCP e executar um handshake TLS em um domínio de terceiros. Como a hospedagem independente dos recursos de outras pessoas afeta o desempenho pode ser vista comparando as duas figuras a seguir.
Recursos de terceiros são baixados de fontes externas (extraídas daqui )Recursos de terceiros são armazenados no mesmo local que o restante dos materiais do site (extraídos daqui )A situação também é melhorada pelo fato de o navegador usar os recursos de multiplexação e priorização de dados de conexão HTTP / 2, já estabelecidos com o domínio principal.
Se você não hospedar recursos de terceiros, como eles serão baixados de um domínio diferente do principal, eles não poderão ser priorizados. Isso os levará a competir entre si pela largura de banda do cliente. Isso pode levar ao fato de que o tempo de carregamento dos materiais críticos para a formação da página será muito maior do que o tempo possível em um conjunto ideal de circunstâncias.
Aqui está uma palestra sobre priorização de HTTP / 2 que explica tudo isso muito bem.
Pode-se supor que o uso de atributos de
preconnect em links para recursos externos ajudará na solução do problema. No entanto, se houver muitos desses links para vários domínios, isso poderá, de fato, sobrecarregar a linha de comunicação no momento mais crucial.
Se você hospedar recursos de terceiros por conta própria, poderá controlar como esses recursos são fornecidos ao cliente. Ou seja, estamos falando sobre o seguinte:
- Você pode garantir que o algoritmo de compactação de dados mais adequado para cada navegador (Brotli / gzip) seja aplicado.
- Você pode aumentar o tempo de armazenamento em cache dos recursos, que geralmente não são muito grandes, mesmo para os provedores mais conhecidos (por exemplo, o valor correspondente para a tag GA é definido como 30 minutos).
Você pode até estender o TTL para um recurso, por exemplo, até um ano, incluindo os materiais apropriados em sua estratégia de gerenciamento de cache (hashes de URL, controle de versão e assim por diante). Falaremos sobre isso abaixo.
▍ Proteção contra interrupções na operação de serviços de terceiros ou de sua desconexão
Outro aspecto interessante da hospedagem independente de recursos de terceiros é que isso permite reduzir os riscos associados a interrupções na operação de serviços de terceiros. Suponha que sua solução de terceiros para teste A / B seja implementada como um script de bloqueio carregado na seção de cabeçalho da página. Este script carrega lentamente. Se o script correspondente falhar ao carregar, a página estará vazia. Se demorar muito tempo para carregá-lo, a página aparecerá com um longo atraso. Ou suponha que o projeto use uma biblioteca carregada de um recurso CDN de terceiros. Imagine que esse recurso travou ou foi bloqueado em um determinado país. Tal situação levará a uma violação da lógica do site.
Para descobrir como seu site funciona em condições de inacessibilidade de algum serviço externo, você pode usar a seção SPOF em
webpagetest.org .
Seção SPOF em webpagetest.org▍ E os problemas de armazenamento em cache nos navegadores? (dica: isso é um mito)
Você pode pensar que o uso de CDNs disponíveis ao público levará automaticamente a um melhor desempenho de recursos, pois esses serviços têm redes razoavelmente boas e são distribuídos em todo o mundo. Mas tudo, de fato, é um pouco mais complicado.
Suponha que tenhamos vários sites diferentes: website1.com, website2.com, website3.com. Todos esses sites usam a biblioteca jQuery. Nós o conectamos a eles usando a CDN, por exemplo, googleapis.com. Você pode esperar que o navegador baixe e armazene em cache a biblioteca uma vez e use-a ao trabalhar com os três sites. Isso pode reduzir a carga na rede. Talvez isso economize dinheiro em algum lugar e ajude a melhorar a produtividade dos recursos. Do ponto de vista prático, tudo parece diferente. Por exemplo, o Safari implementa um recurso chamado
Intelligent Tracking Prevention : o cache usa chaves duplas com base na origem do documento e na fonte de um recurso de terceiros.
Aqui está um bom artigo sobre este tópico.
As pesquisas antigas do
Yahoo e do
Facebook , bem como as
pesquisas mais recentes
de Paul Calvano, mostram que os recursos não são armazenados nos caches do navegador pelo tempo que esperávamos: “Existe uma lacuna séria entre o tempo de armazenamento em cache de nossos próprios e de terceiros recursos do projeto. É sobre CSS e fontes da web. Ou seja, o prazo de armazenamento em cache de 95% de suas próprias fontes excede uma semana, enquanto o prazo de armazenamento em cache de 50% das fontes de terceiros é inferior a uma semana! Isso dá aos desenvolvedores da Web um bom motivo para hospedar arquivos de fonte automaticamente! ”
Como resultado, se você hospedar materiais de outras pessoas, não perceberá problemas de desempenho causados pelo cache do navegador.
Agora que examinamos os pontos fortes dos recursos de terceiros com hospedagem automática, vamos falar sobre como distinguir uma boa implementação dessa abordagem de uma má.
Mau: o diabo está nos detalhes
Mover recursos de terceiros para seu próprio domínio não pode ser executado automaticamente sem cuidar do armazenamento em cache correto desses recursos.
Um dos principais problemas aqui é o tempo de armazenamento em cache. Por exemplo, as informações da 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; como resultado, não causará problemas no cache.
Porém, se um determinado esquema de versão não for aplicado ao trabalhar com arquivos, os scripts em cache, cujo conteúdo muda quando o nome do arquivo é inalterado, podem ficar desatualizados. Isso pode se tornar um problema sério, pois, por exemplo, não permite introduzir automaticamente correções de segurança nos scripts que os clientes devem receber o mais rápido possível. O desenvolvedor precisará fazer um esforço para atualizar esses scripts no cache. Além disso, isso pode causar falhas no aplicativo devido ao fato de o código usado no cliente do cache diferir da versão mais recente do código para o qual a parte do servidor do projeto foi projetada.
É verdade que, se falarmos sobre materiais atualizados com freqüência (gerenciadores de tags, soluções para testes A / B), o armazenamento em cache usando a CDN é uma tarefa que pode ser resolvida, mas já é muito mais complicada. Serviços como o Commanders Act, soluções de gerenciamento de tags, usam ganchos da web para publicar novas versões. Isso torna possível organizar uma liberação de cache na CDN ou, ainda melhor, a capacidade de chamar uma atualização de hash ou versão de URL.
Delivery Entrega adaptável de materiais aos clientes
Além disso, quando falamos sobre armazenamento em cache, também devemos levar em consideração o fato de que as configurações de armazenamento em cache usadas na CDN podem não ser adequadas para alguns recursos de terceiros. Por exemplo, esses recursos podem usar a tecnologia de detecção de agente do usuário, serviço adaptável, para fornecer a navegadores específicos versões de materiais otimizados especificamente para esses navegadores. Essas tecnologias, para descobrir os recursos do navegador, dependem de expressões regulares ou de um banco de dados que coleta informações sobre o cabeçalho HTTP do
User-Agent do
User-Agent . Ao saberem com qual navegador estão lidando, eles fornecem materiais projetados para ele.
Aqui você pode se lembrar de dois serviços. O primeiro é o googlefonts.com. O segundo é polyfill.io. O serviço Google Fonts fornece, para alguns recursos, vários códigos CSS, dependendo dos recursos do navegador (fornecendo links para recursos woff2 usando o
unicode-range ).
Aqui estão os resultados de algumas consultas do Google Fonts feitas em diferentes navegadores.
Resultado da consulta de fontes do ChromeResultado da consulta do Google Fonts feito no IE10O Polyfill.io fornece ao navegador apenas os polyfills necessários. Isso é feito por razões de desempenho.
Por exemplo, veja o que acontece se você executar a seguinte solicitação em diferentes navegadores:
https://polyfill.io/v3/polyfill.js?features=defaultEm resposta a uma solicitação feita a partir do IE10, 34 Kb de dados serão fornecidos. E a resposta, feita no Chrome, estará vazia.
Irritado: algumas considerações de privacidade
Este item é o último em ordem, mas não é importante. O ponto é 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 afetar adversamente o projeto principal da Web.
Se o seu sistema CDN não estiver configurado corretamente, pode acabar enviando cookies do seu domínio para um serviço de terceiros. Se a filtragem adequada não estiver organizada no nível da CDN, os cookies da sessão, que em condições normais não podem ser usados no JavaScript (com o atributo
httponly ), poderão ser enviados para um host
httponly .
É exatamente isso que pode acontecer com rastreadores como Eulerian ou Criteo. Rastreadores de terceiros podem definir um identificador exclusivo nos cookies. Se eles fizessem parte dos materiais dos sites, poderiam ler o identificador a seu critério durante o trabalho do usuário com diferentes recursos da web.
Atualmente, a maioria dos navegadores inclui proteção contra esse comportamento dos rastreadores. Como resultado, os rastreadores agora usam a tecnologia
CNAME Cloaking , disfarçando-se como seus próprios scripts para vários projetos. Ou seja, os rastreadores oferecem aos proprietários do site que adicionam CNAME às configurações de domínio para um determinado domínio, cujo endereço geralmente se parece com um conjunto aleatório de caracteres.
Embora não seja recomendável que os cookies do site sejam acessíveis a todos os subdomínios (por exemplo, * .website.com), muitos sites fazem isso. Nesse caso, esses cookies são automaticamente enviados para o rastreador de terceiros disfarçado. Como resultado, você não pode mais falar sobre privacidade.
Além disso, o mesmo acontece com os cabeçalhos HTTP
Client-Hints , que são enviados apenas para o domínio principal, pois podem ser usados para criar uma
impressão digital digital do usuário. Verifique se o serviço CDN que você está usando filtra corretamente esses cabeçalhos.
Sumário
Se você pretende introduzir em breve hospedagem independente de recursos de terceiros, deixe-me dar algumas dicas:
- Hospede suas bibliotecas JS, fontes e arquivos CSS mais importantes. Isso reduzirá o risco de uma falha no site ou uma diminuição no seu desempenho como resultado do fato de que o recurso vital para o site funcionar não estava disponível devido a um serviço de terceiros.
- Antes de armazenar em cache recursos de terceiros em uma CDN, certifique-se de usar um sistema de controle de versão ao nomear seus arquivos ou de controlar o ciclo de vida desses recursos, limpando manualmente ou automaticamente o cache da CDN ao publicar uma nova versão do script.
- Tenha muito cuidado com as configurações de CDN, servidor proxy, cache. Isso permitirá que você impeça o envio de cookies do seu projeto ou cabeçalhos de
Client-Hints para serviços de terceiros.
Caros leitores! Você publica em seus servidores materiais de outras pessoas que são extremamente importantes para seus projetos?
