Uma das primeiras coisas que recomendo aos meus clientes para acelerar os sites parecerá um paradoxo no início: você precisa colocar recursos estáticos em sua hospedagem, abrindo mão de uma infraestrutura CDN de terceiros. Neste post curto e, espero, muito simples, quero descrever as desvantagens de armazenar seus arquivos estáticos "de lado" e as vantagens incríveis de hospedá-los na minha hospedagem.
Do que estou falando?
É comum que os desenvolvedores cliquem no link para ativos estáticos, como bibliotecas ou plugins, localizados em sites e recursos da CDN. Um exemplo clássico é o jQuery.
Existem várias vantagens óbvias, mas meu objetivo mais adiante neste artigo é expor essa abordagem e mostrar que as desvantagens são muito mais prevalentes.
(Primeiro, considere os benefícios).
- Isso é conveniente. Isso requer muito pouco esforço para conectar arquivos. Copie a linha do código HTML e pronto. Fácil.
- Temos acesso à CDN. code.jquery.com é fornecido pelo StackPath, é uma CDN. Ao conectar-se ao conteúdo deste recurso, obtemos entrega com qualidade CDN, gratuitamente.
- Os arquivos do usuário já podem estar armazenados em cache. Se website-a.com vincular a code.jquery.com/jquery-3.3.1.slim.min.js e o usuário for daqui para website-b.com, que também vincula a code.jquery.com/jquery-3.3 .1.slim.min.js , o usuário terá esse arquivo no cache.
Risco: queda de velocidade e falhas
Não vou entrar em muitos detalhes neste post. Tenho um artigo completo sobre a viabilidade de terceiros e os riscos associados a atrasos e interrupções. Basta dizer que, se você tiver recursos críticos associados a provedores de terceiros, e se o provedor sofrer falhas e queda de velocidade ou indisponibilidade, isso é uma notícia bastante desagradável para você. Você também sofrerá com isso.
Se você tiver algum CSS de bloqueio de renderização ou JS síncrono hospedado em recursos de terceiros, prossiga e transfira-os para sua própria infraestrutura imediatamente. Os ativos críticos são valiosos demais para serem deixados em servidores de terceiros.
Risco: rescisão do serviço
Essa é uma ocorrência muito menos comum, mas o que acontece se o provedor decidir que precisa interromper o serviço? Foi exatamente o que o Rawgit fez em outubro de 2018, até o momento (no momento da redação), uma pesquisa grosseira no código do GitHub ainda fornece mais de um milhão de links para o serviço, que está sendo fechado no momento, e quase 20.000 sites existentes continuam sendo consulte-o.
Risco: vulnerabilidades de segurança
Outra coisa a prestar atenção é uma simples questão de confiança. Se trouxermos conteúdo de recursos de terceiros para nossa página, esperamos que os arquivos que recebemos sejam exatamente o que esperamos receber e que façam exatamente o que esperamos deles.
Imagine o dano que poderia ser causado se alguém pudesse obter o controle de um provedor como o code.jquery.com e começar a entregar conteúdo comprometido ou malicioso. É assustador pensar nisso!
Integridade do sub-recurso
Devemos prestar homenagem a todos os fornecedores de terceiros mencionados até agora neste artigo, eles estão fazendo de tudo para garantir a integridade do sub-recurso (Subresource Integrity - SRI). SRI é o mecanismo pelo qual o provedor fornece o hash (tecnicamente, um hash seguido pela codificação Base64) do arquivo específico que você espera e pretende usar. O navegador pode verificar se o arquivo que você recebeu é exatamente o que você solicitou.
<script src="https://code.jquery.com/jquery-3.4.1.slim.min.js" integrity="sha256-pasqAKBDmFT4eHoN2ndd6lN370kFiGUFyTiUHWhU7k8=" crossorigin="anonymous"></script>
Mais uma vez, se você definitivamente precisar conectar conteúdo estático a um recurso de terceiros, verifique se o SRI está ativo. Você pode conectar o SRI você mesmo.
Acerto de contas: negociações de rede
Um dos custos maiores e mais urgentes em que incorremos é o custo da abertura de novas conexões TCP. Cada novo recurso que precisamos visitar exige a abertura de uma conexão, o que pode ser muito caro: resolução DNS, handshake TCP, negociação TLS, tudo isso contribui, e a história fica pior à medida que a conexão atrasa.
Vou dar um exemplo extraído diretamente da página de introdução do Bootstrap. Eles instruem os usuários a anexar quatro arquivos.
Esses quatro arquivos estão localizados em três recursos diferentes, ou seja, precisamos abrir três conexões TCP. Quanto custa? Bem, com uma conexão bastante rápida, o conteúdo desses arquivos estáticos ao lado é 311ms ou 1,65x mais lento do que quando você os coloca em sua própria hospedagem.
Ao entrar em contato com três fontes diferentes para a manutenção de ativos estáticos, perdemos coletivamente os 805ms desnecessários para aprovações de rede.
OK, não é tão assustador, mas a Trainline, meu cliente, descobriu que quando o atraso era reduzido em 300ms, os visitantes pagavam 8 milhões de libras adicionais por ano. Esta é uma maneira muito fácil de ganhar 8 milhões.
Apenas movendo nossos recursos para o seu domínio, eliminamos completamente o custo de conexões adicionais.
Para uma conexão mais lenta, com um atraso maior, a história é muito pior. Para 3G, a versão de terceiros é mais lenta que a 1.765s. Eu pensei que era para tornar nosso site mais rápido.
Ao se conectar com um grande atraso, os custos totais da rede são monstruosos 5.037s. O que pode ser completamente evitado.
Mover arquivos para nossa própria infraestrutura reduz o tempo de download de 5.4s para 3.6s.
Se esse não é um bom motivo para hospedar seus recursos estáticos, não sei mais o que trazer.
Pré-conexão
Naturalmente, o ponto principal da minha apresentação aqui é que você não deve publicar nenhum recurso estático ao lado se conseguir fazer isso em sua hospedagem. No entanto, se suas mãos estiverem atadas de alguma forma, você poderá usar a pré-conexão Dica de Recurso para abrir proativamente uma conexão TCP com uma (s) fonte (s) específica (s):
Nota Mesmo se você usar a pré-conexão, a quantidade de tempo perdida diminuirá apenas um pouco: você ainda precisará abrir as conexões correspondentes e é improvável que os custos sejam justificados, especialmente para conexões lentas.
Acerto de contas: perda de priorização
O segundo acerto de contas vem na forma de otimização no nível do protocolo, que perdemos quando dividimos o conteúdo em domínios. Se você usa HTTP / 2, o que deve ser feito, você obtém acesso à priorização.
Todos os fluxos (portanto, recursos) com a mesma conexão TCP mantêm a prioridade, e o navegador e o servidor trabalham em conjunto para criar a árvore de dependência de todos esses fluxos priorizados, para que possamos retornar recursos críticos mais rapidamente e, possivelmente, atrasar a entrega dos menos importantes.
Nota Tecnicamente, devido à mesclagem de conexões HTTP / 2, as solicitações podem ser priorizadas entre si em domínios diferentes, desde que compartilhem o mesmo endereço IP.
Se distribuirmos nossos recursos por diferentes domínios, teremos que abrir várias conexões TCP exclusivas. Não podemos cruzar prioridades de referência para essas conexões, ou seja, perdemos a capacidade de entregar arquivos de uma certa maneira bem pensada.
Ao hospedar todo o conteúdo em uma hospedagem, podemos criar uma árvore de dependência mais complexa. Cada encadeamento possui seu próprio ID, pois eles pertencem à mesma árvore. Se fornecermos o máximo de conteúdo possível de um domínio, podemos permitir que o HTTP / 2 faça seu trabalho e priorize os ativos mais plenamente, na esperança de uma resposta mais rápida.
Armazenamento em cache
Em geral, os hosts de recursos estáticos parecem se sair muito bem ao definir diretivas de duração máxima de longa duração. Isso faz sentido, pois o conteúdo estático nos URLs com versão (como mencionado acima) nunca será alterado. Isso torna muito seguro e racional aplicar uma política de cache razoavelmente agressiva.
No entanto, esse nem sempre é o caso e, ao colocar seus recursos independentemente, você pode desenvolver muito mais estratégias de armazenamento em cache individuais.
Mito: Armazenamento em cache entre domínios
Mais interessante é a capacidade de cache de ativos entre domínios. Ou seja, se muitos sites apontam para a mesma versão do jQuery, localizada na CDN, certamente os usuários já possuem esse arquivo específico em seu computador. Algo como compartilhamento de recursos ponto a ponto. Esse é um dos argumentos mais comuns para o uso de um provedor de ativos estáticos de terceiros.
Infelizmente, não há evidências publicadas para apoiar essas alegações: não há razão para acreditar que isso seja verdade. Por outro lado, um estudo recente de Paul Calvano sugere que o oposto pode ser verdadeiro:
Há uma lacuna perceptível entre a idade do cache de recursos CSS e as fontes da web de primeiro e de terceiros. 95% das fontes de terceiros têm mais de uma semana, em comparação com 50% das fontes de terceiros com menos de uma semana. Isso fornece bons motivos para fontes da web auto-hospedadas.
Em geral, parece que o conteúdo de terceiros é armazenado em cache pior que o próprio.
Ainda mais importante, o Safari desativou completamente esse recurso devido a preocupações com abuso de privacidade; portanto, a tecnologia de cache compartilhado pode não funcionar no momento da redação deste artigo para 16% dos usuários em todo o mundo.
Em resumo, embora isso seja teoricamente bom, não há evidências de que o cache entre domínios seja de alguma forma eficiente.
Acesso CDN
Outro benefício generalizado de entrar em contato com um provedor de recursos estáticos é que ele provavelmente usará uma infraestrutura poderosa com recursos de CDN: distribuição global, escalabilidade, baixa latência e alta disponibilidade.
Como isso é absolutamente verdade, se você se importa com seu desempenho, deve executar seu próprio conteúdo a partir da CDN. Com o nível dos preços atuais de hospedagem, existem muito poucas desculpas para você não estar usando isso para seus recursos.
Em outras palavras: se você acha que precisa de uma CDN para o seu jQuery, precisará de uma CDN para tudo.
Hospede recursos estáticos em sua hospedagem
De fato, existem muito poucas razões para deixar seus recursos estáticos na infraestrutura de outra pessoa. Os benefícios possíveis costumam ser um mito e, mesmo que não, os compromissos simplesmente não valem a pena. Carregar recursos de diferentes fontes é muito mais lento. Nos próximos dias, gaste dez minutos auditando seus projetos e assuma o controle de todos os recursos estáticos de terceiros.