Porque é que o teu site está lento e não é o servidor
A primeira resposta é quase sempre a errada
Alguém diz que o site está lento. A frase seguinte costuma ser "o servidor está lento" ou "precisamos de um plano de alojamento melhor". Já passei por essa conversa muitas vezes e o servidor foi a última coisa a arranjar. Uma página pode levar seis segundos com um servidor que responde em 120 milissegundos, e já medi isso.
Mede primeiro, e mede mais do que uma vez
Abre a página numa janela privada com o painel de rede aberto, faz um recarregamento forçado e escreve os números: tempo total, número de pedidos, bytes transferidos. Faz isto três vezes e olha para o padrão, não para uma leitura isolada. Se a página é rápida na tua máquina e lenta para quem se queixa, a diferença está nas condições: com sessão iniciada ou não, telemóvel ou computador, cache fria ou quente, um país ou outro.
Três números, não um
Um carregamento de página são três tempos empilhados.
- Tempo até ao primeiro byte: desde o pedido a sair do browser até ao primeiro byte da resposta a chegar. Isto é DNS, ligação, TLS, servidor web e a tua aplicação. É a única parte que pertence ao servidor.
- Tempo de render: desde o primeiro byte de HTML até o texto estar pintado. Isto é análise do HTML, CSS, scripts que bloqueiam e layout.
- Tempo de recursos: tudo o que vem depois. Imagens, tipos de letra, analytics, widgets de chat e tudo o mais que carrega tarde e mantém a thread principal ocupada.
Se o primeiro byte chega aos 150 milissegundos e o total são cinco segundos, nenhum upgrade de servidor vai ajudar. Se o primeiro byte demora três segundos, o problema é a aplicação e o resto é ruído.
O waterfall mostra-te a forma
O painel de rede lista todos os pedidos pela ordem em que começaram, com barras que mostram quando cada um correu. Três formas que vale a pena reconhecer:
- Um bloco comprido no topo sem mais nada a começar. Alguma coisa bloqueia, normalmente uma folha de estilos ou um script no head.
- Uma corrente, em que cada pedido só começa depois de o anterior terminar. Costuma ser um pedido feito de dentro de JavaScript que precisava da resposta anterior.
- Uma pilha de pedidos no fundo que ninguém pediu. Trackers, widgets, tipos de letra, vídeos.
Ordena a lista por tamanho e depois por duração. Na maioria das páginas uma imagem ou um script representa uma grande fatia do total, e encontrá-lo leva menos tempo do que ler sobre caching.
Só agora a aplicação
Se o problema for o tempo até ao primeiro byte, vale a pena abrir o slow query log e o profiler. Os achados habituais, por ordem de frequência: uma query dentro de um ciclo que corre uma vez por item de uma lista, um índice em falta numa coluna usada num where, uma query sem limite que constrói um array com tudo. Guardar em cache um desses resultados vale muitas vezes mais do que qualquer mudança no alojamento.
Tipos de letra e código dos outros
Os tipos de letra são um custo silencioso. Cada peso é outro ficheiro e outro pedido, e uma folha de estilos que carrega de um serviço de fontes bloqueia o render até responder. Com dois pesos alojados por ti, chega.
Os scripts de terceiros são o custo ruidoso. Um tag manager, um snippet de analytics, um widget de chat, um mapa, um vídeo. Cada um é um domínio novo ao qual o browser se tem de ligar e JavaScript que compete pela thread principal com o teu. A métrica que apanha isto é o interaction to next paint: o objetivo é 200 milissegundos ou menos no percentil 75, e um widget de chat pode comer quase tudo. O resto segue os mesmos limites, LCP em 2,5 segundos e CLS em 0,1, todos medidos no percentil 75 porque é essa parte do teu tráfego que dói.
Quando o servidor é mesmo a resposta
Há problemas de infraestrutura reais. Uma máquina que fica sem memória e começa a fazer swap. Mais workers do que a memória aguenta. Uma tabela com dez milhões de linhas e sem índice. Um alojamento partilhado que te limita nas horas de pico. Esses casos veem-se nos números: o tempo até ao primeiro byte sobe com o tráfego, e é mau em todas as páginas e não só numa. Quando os números são assim, o servidor é a resposta. Até lá, é o palpite mais caro que tens à mão.
A ordem que uso
- Mede três vezes e escreve os números.
- Divide o total em primeiro byte, render e recursos.
- Arranja a parte maior e mede outra vez.
- Muda uma coisa de cada vez e mantém o registo.
- Fala do servidor só quando o primeiro byte for a parte maior.
O que compensa, na minha experiência, são imagens exportadas em tamanho de impressão, tipos de letra de três domínios e um widget de chat que ninguém usa. Tudo isso é uma tarde de trabalho e nada envolve um plano de alojamento.
Tens um site WordPress que não para de se partir? Vê o que faço e como trabalho.