O melhor é que o TinyPNG permite 500 imagens gratuitas por mês; portanto, para um site pequeno e médio, você quase sempre pode ficar dentro da cota gratuita!
# 2: Divisão de código e divisão de pacotes
Divisão de código – divisão de código em vários blocos e carregá-los lentamente quando necessário. Você sempre precisa disso no seu site
Divisão de pacote – A divisão de arquivos individuais gerados pela divisão de código mais abaixo em pacotes menores – melhora o cache nos navegadores, bem como o cache de bytecode nos navegadores.
Embora a divisão de pacotes possa ser desaprovada à medida que você aumenta as solicitações HTTP, o HTTP / 2 tem pouco ou nenhum impacto em várias solicitações até que os limites de simultaneidade atinjam – e a coisa boa sobre os limites de simultaneidade está no intervalo de centenas de solicitações. Se você não está realizando pedidos de HTTP (o que tenho certeza de que não está), você deve ser bom em dividir pacotes.
Para divisão de código e pacote configurável, você precisa integrar seu projeto a um pacote configurável de módulo, como parcel ou webpack. Depois de configurá-los corretamente, eles funcionam como mágica e podem realmente reduzir a carga no servidor e nos navegadores do cliente, armazenando em cache recursos e não fazendo o download de recursos desnecessários atualmente – como, por que você deseja enviar o código JS para /about rota quando estou no /feedback rota.
Você também deve minificar suas construções JS / CSS. Para o webpack, existem plugins como o UglifyJS disponíveis. Isso ajuda a reduzir o tamanho cortando espaços em branco, comentários, código de encurtamento etc. – o que acabaria por reduzir o tamanho do conteúdo.
# 3: não use serviços de hospedagem compartilhada
Se você é um desenvolvedor ou alguém com um conhecimento básico de como trabalhar com o bash, simplesmente não há razão para usar serviços de hospedagem compartilhada. Em quase todos os casos, você pode hospedar seus recursos estáticos gratuitamente em sites como as páginas do GitHub, ou pode optar por opções mais controladas, como hospedagem na nuvem. Quase todos esses players de hospedagem em nuvem como AWS, Google Cloud, DigitalOcean etc. fornecem tantos créditos gratuitos que, como usuário, você quase sempre pode consumir muitos de seus serviços gratuitamente por um longo tempo!
Nos casos em que a hospedagem compartilhada é mais barata do que alternativas como a hospedagem 5O DigitalOcean, esses servidores possuem recursos muito limitados alocados ao seu site, o que prejudica o desempenho geral do site. Shell preso, vCPUs compartilhados, RAM limitada, são algumas coisas para começar. Nós, desenvolvedores, sempre queremos estar no controle, e usar um IaaS ou um PaaS é sempre uma solução.
Embora você possa ir com qualquer provedor de nuvem de sua escolha, eu recomendaria o DigitalOcean – aquele que eu uso para codedamn atualmente. É muito simples de configurar, e você pode obter 100 $ créditos em nuvem gratuitos com este link.
A escolha de um provedor de nuvem realmente forneceria recursos e infraestrutura que aumentariam automaticamente o desempenho do servidor, portanto, um pouco o desempenho do site.
Assim como discutimos acima, o armazenamento em cache é extremamente importante para configurar corretamente. Os cabeçalhos de expiração HTTP informam ao navegador o que armazenar em cache e por quanto tempo. Os recursos em cache não são buscados nos servidores remotos, portanto, é de extrema importância não armazenar em cache os principais recursos do ponto de entrada, como index.html – o primeiro arquivo que você serve e também implementa o bloqueio de cache de forma adequada. Novamente, para empacotadores de módulo como o webpack, você pode implementar o bloqueio de cache tendo [contenthash] em nome dos pacotes emitidos. Ademais, isso exige que os navegadores nunca armazenem em cache o seu index.html ou qualquer outro arquivo HTML que você esteja usando como ponto de entrada no seu site. Como podemos conseguir isso?
Para veiculação de arquivo estático e cabeçalhos de expiração HTTP, use NGiNX. O NGiNX pode gerenciar tudo isso para você. Aqui está um exemplo de configuração recomendada para definir cabeçalhos de expiração HTTP:
Essa configuração simplesmente desativa o cache para text/html recursos e, para outros, define-o para o tempo máximo possível que o navegador pode manter o cache. Observe que essa configuração depende fortemente do fato de você ter seus mecanismos de impedimento de cache implementados no empacotador de módulo (como o [contenthash] nós conversamos acima)
# 5: Habilite a compactação Brotli
A compactação Brotli é um algoritmo de compactação projetado pelo Google, que é 20 a 25% mais eficiente que a bem conhecida compactação GZIP. A compactação de Brotli pode ser implementada em sites, novamente, usando o NGiNX. Vamos dar uma olhada em um exemplo do que acontece quando a compactação Brotli está ativada:
O primeiro tamanho do arquivo é 3,33 MB – sem compactação
Quando é compactado usando Brotli – o tamanho cai para 572KB
Quando é compactado usando GZIP – o tamanho cai para 783KB
Brotli economiza mais de 200 KB em comparação com o GZIP e mais de 2,5 MB em comparação com nenhuma compactação. E nem está funcionando no seu pico! Isso é mais de 82% de compactação! Muito legal!
É isso aí!
É basicamente isso! Sem entrar muito nos detalhes de como implementar essas técnicas específicas, abordamos algumas das coisas mais importantes a serem consideradas ao acelerar o site. Não entrei em detalhes específicos, pois sua milhagem pode variar de acordo com as configurações do servidor – mas o conceito geral permanece o mesmo.
Siga estas práticas recomendadas e deixe-me saber o que você pensa dizendo Olá no meu punho do twitter.
Se você gostou deste artigo, vamos nos encontrar nas mídias sociais. Aqui está o meu Instagram e Twitter. Sou super ativo e adoraria conversar! Vamos nos conectar.