Otimização é o que temos que considerar no início

Antes de entrarmos no assunto, gostaria de agradecer ao fotógrafo pela imagem das montanhas enevoadas (foto acima) utilizada pelo site que discutiremos aqui.

Antes de explorar as ferramentas para otimizar aplicativos, examinaremos a estrutura do projeto. O site deste blog é meu portfólio construído usando HTML puro, CSS e JavaScript. Imagine construir uma interface do usuário sem React ou Angular. Isso é possível nos dias de hoje?

Alguns de vocês dirão que é uma perda de tempo, o que é verdade. Mas, como o site é estático com várias páginas, decidi que essa era uma ótima chance de evitar abstrações de alto nível e sair aprendendo tudo sobre métricas de desempenho na web e SEO.

A oportunidade valeu a pena por dois motivos:

• evitar a abstração significa conhecer o que está sob o capô,
• análise cronológica das ferramentas e entendimento das demandas.

Primeiras coisas primeiro

Antes de abordarmos questões sérias, vamos começar um incêndio com uma tarefa simples. A otimização da imagem é o mais importante, pois é uma das coisas que o Lighthouse mais penaliza. Por que esse é o caso? A Lighthouse está testando a primeira carga simulando uma rede 3G lenta, pois ainda é a rede mais comum no mundo.

O download de 1 MB pode levar até 3 segundos, e se tivermos imagens de alta resolução? Os usuários provavelmente desistirão de navegar no site, pois leva 50ms para saber se eles gostam ou não . Curiosidade, é o mais fácil de resolver. A solução é converter todas as imagens para o formato WebP .

Livre-se de coisas irrelevantes na primeira carga!

As duas coisas mais influentes que formam a pontuação são o Largest Contentful Paint — LCP e o Total Blocking Time — TBT (que carregam 50% da classificação de desempenho).

A maior pintura de conteúdo é um dos principais indicadores vitais da Web que avalia a velocidade de exibição. Isso pode ser resolvido seguindo os Padrões de Vitais da Web . Para TBT, precisamos de algum trabalho extra.

O Tempo Total de Bloqueio é o intervalo de tempo em que a página não pode responder à interação. Tem que ser inferior a 50ms. JavaScript é uma linguagem de thread único e temos que tomar cuidado para não sobrecarregar o thread principal. O problema de sobrecarga foi resolvido usando Web Workers para cache de fontes, imagens, HTML, CSS e JS — tudo o que é estático.

Outras coisas razoáveis ​​são limpar o código CSS desnecessário e separá-lo em vários arquivos. Também temos que remover o código JS não utilizado, mas não será possível sem o bundler. Felizmente, neste caso, o código JS não o afeta muito.

Vamos começar a testar com o Farol!

Se quisermos hospedar um site no Google com alto índice , duas coisas devem ser levadas em consideração:

• Otimização para mecanismos de busca – SEO
• Acessibilidade.

O Google presta muita atenção à disponibilidade de conteúdo ( lema. Acessível a todos ) para todos que navegam na web, independentemente de isso incluir pessoas com deficiências temporárias ou permanentes. Não há correspondência para contar sobre a solução, pois haverá informações claras para corrigir problemas.

Reforce a sua segurança!

Outra estatística significativa está sob a rubrica Melhores Práticas. Talvez a característica mais importante se o tipo de aplicativo envolve integração com vários serviços externos (por exemplo, processadores de pagamento). Neste caso, devemos dar especial atenção aos seguintes pontos:

O site tem que ser HTTPS

Alguns serviços de integração não funcionam sem uma conexão segura, como Stripe API .

Como este é um site pessoal sem provedor externo, exceto o provedor de serviço de e-mail, não precisamos implementar todos os protocolos de segurança aqui apresentados. Mas, considerando que queremos cumprir todos os protocolos , assim o faremos.

O site está hospedado no Netlify (como parte de um plano de hospedagem gratuito ). A única coisa que você precisa pagar é um domínio. Depois de comprar um domínio, você deve apontar os servidores de nomes (NS) da Netlify para o domínio adquirido - crie um registro NS no provedor do domínio.

Outra solução pronta fornecida via Netlify é o certificado SSL atribuído automaticamente ao seu domínio. Isso pode economizar muito tempo, pois a instalação da certificação SSL pode ser demorada.

Evite usar bibliotecas com riscos de segurança

Dado que muitas das soluções de software atuais dependem de serviços de terceiros, devemos cuidar de sua qualidade. Muitos bugs abertos em bibliotecas de código aberto nos dizem que devemos pensar duas vezes antes de incorporá-los ao nosso sistema.

Quando escolhemos APIs que não apresentam riscos críticos de segurança, nosso trabalho não para por aí. Periodicamente, temos que verificar se a versão atual do serviço ainda está sem riscos de segurança e, se necessário, atualizar as versões.

Existe uma ferramenta prática que documenta os riscos de segurança de software. Basta digitar o domínio e obteremos todas as informações sobre o tipo de risco e a versão do software encontrado.

O site do National Institute for Standards and Technology (NIST) é um recurso útil para todos os riscos de segurança registrados. Às vezes, não precisamos retirar as ameaças e atualizar a versão porque talvez não usemos a parte do serviço com risco.

Integre a Política de Segurança de Conteúdo (CSP)

CSP é a política de segurança mais eficaz contra Cross-Site Scripting ( XSS ) e injeção de dados. Com a configuração CSP 'perfeita', os visitantes do seu site estão protegidos contra códigos mal-intencionados.

Com o CSP, você controla os recursos fornecidos no site. Em termos simples, CSP é uma string com diretivas para o navegador baixar recursos (HTML, CSS, JS, imagens, vídeos etc.) apenas de fontes confiáveis ​​definidas na política. Um exemplo de uma boa política de CSP é o seguinte:

Content-Security-Policy = "
 default-src 'none'; 
 base-uri 'self'; 
 style-src 'self' https://fonts.googleapis.com; 
 script-src https://*.googleapis.com https://*.gstatic.com *.google.com https://*.ggpht.com *.googleusercontent.com blob:; 
 form-action 'self'; img-src 'self' https://*.googleapis.com https://*.gstatic.com *.google.com *.googleusercontent.com data:; 
 connect-src 'self' https://*.googleapis.com *.google.com https://*.gstatic.com data: blob:; 
 font-src 'self' data: https://fonts.gstatic.com; 
 object-src 'none'; 
 media-src 'none'; 
 frame-src *.google.com; 
 child-src 'self'; 
 worker-src 'self' blob:; 
 frame-ancestors 'none'; 
 manifest-src https://alenvlahovljak.com/manifest.json
"

Adicionar cabeçalho Strict-Transport-Security

A política Strict Transport Security é uma orientação para o navegador evitar carregar o site usando HTTP e converter automaticamente todas as tentativas de acesso ao site usando apenas solicitações HTTPS. Um exemplo de configuração padrão é o seguinte:

Strict-Transport-Security = "max-age=31536000; includeSubDomains; preload"

Tente isso na guia Rede no modo de navegação anônima. Primeiro, o navegador solicita uma página HTTP e, em seguida, a política HSTS evoca outra solicitação por meio de um redirecionamento interno (307) para solicitar uma página HTTPS. Depois disso, recarregue a página e você verá apenas uma solicitação (200) para o HTTPS.

Com a diretiva de pré-carregamento , o site solicita a inclusão do domínio na lista de pré-carregamento do HSTS. A lista de pré-carregamento contém uma lista de todos os sites marcados como fontes confiáveis ​​por padrão. Em outras palavras, ele nunca solicitará HTTP, mas o HTTPS para sempre, pois o domínio é codificado no mecanismo do navegador. A maioria dos principais navegadores (Chrome, Firefox, Safari, Edge) possui listas de pré-carregamento HSTS.

Existe um site no qual você pode solicitar manualmente a inclusão na lista de pré-carregamento do HSTS do Chrome.

X-XSS-Proteção

X-XSS-Protection é uma política que impede o carregamento quando ataques XSS são detectados. Essa proteção é desnecessária principalmente em navegadores modernos, nos quais os sites implementam um CSP forte. Mas, no caso de navegadores mais antigos (Internet Explorer, é claro) que não estão implementando a política CSP Nível 2 , é recomendável, e é apenas uma linha de código:

X-XSS-Protection = "1; mode=block"

X-Frame-Options é um cabeçalho de segurança que informa ao navegador se o site pode ser apresentado em um iframe. O clickjacking é um exemplo de ataque que consome esse problema de segurança. Sites maliciosos podem induzir os usuários a clicar em links em seu site, mesmo que pareçam não estar em seu site.

X-Content-Type-Options é um cabeçalho que informa ao navegador para não carregar scripts e folhas de estilo, a menos que o servidor indique o tipo MIME correto por meio do cabeçalho Content-Type. Sem ele, o navegador pode executar o sniffing MIME (adivinhar o tipo MIME observando os bytes do recurso), o que pode levar a um ataque XSS.

Ambos os cabeçalhos podem ser configurados da seguinte forma:

X-Frame-Options = "SAMEORIGIN"
X-Content-Type-Options = "nosniff"

Isso foi praticamente tudo de mim. Vou deixar links para algumas ferramentas úteis que podem ajudá-lo a configurar seu(s) site(s) e ajudá-lo a investigar novos cabeçalhos (como Permissions-Policy ) chegando aos navegadores. Aqui está a lista de ferramentas:

• webhint (uma ferramenta de linting para a web),
• VulDB (banco de dados de todos os problemas de segurança do software registrado),
• CSP-Fiddler-Extension (configure o CSP para as necessidades do seu site),
• DNS SPY (validar registros DNS),
• Laboratórios SSL (validar SSL),
• Observatório da Mozilla (validar cabeçalhos).

Aqui está um exemplo de script para injetar em um site desprotegido (sem CSP). Nada de ruim vai acontecer, não se preocupe — se você não considera o Harlem Shake uma coisa ruim.