Colocar o CSS crítico inline “acima da borda” em páginas web é uma técnica de otimização para fazer com que sites carreguem incrivelmente rápido. Mas realmente funciona? Basicamente, um site se constitui de uma ou mais páginas web (inter)ligadas por um domínio, links, recursos comumente usados e cache do navegador. Páginas web não são sites; sites não são páginas web. Otimizações que aliviam a “carga útil” (payload) de uma página web podem aumentar a carga do site como um todo.
Qual é a diferença entre a otimização de páginas web e de web sites? Como os arquivos são armazenados em cache pelo navegador? Quando se deve projetar para as primeiras visitas e quando se deve “alavancar” o cache do navegador? Qual é a carga de um site e como ele é afetado por técnicas de desempenho inline? Neste artigo, veja a reposta para estas perguntas e algumas considerações a repeito.
Colocar o CSS crítico inline diretamente no HTML “acima da dobra” melhora o tempo de carregamento da primeira página visitada, mas, a media em que o visitante vai passando por várias páginas, as otimizações destinadas a fazer a primeira impressão mais rápida podem retardar visitas subseqüentes.
Critical CSS faz seu site carregar incrivelmente rápido — especialmente em mobile.
Folhas de Estilo bloqueiam a renderização. Até que o navegador tenha solicitado, recebido, baixado e analisado as folhas de estilo, uma página permanecerá em branco. Ao reduzir a quantidade de CSS que o navegador tem que processar, é possível ter uma página renderizada muito, muito mais rapidamente.
Infelizmente, é bastante tedioso determinar manualmente qual CSS deve ser considerado crítico para uma página. Esta ferramenta remove esse sofrimento automatizandoo processo para você.
Tudo verdade. Bem… Quase tudo. O CSS crítico foca tanto na otimização de páginas web que perde foco ao otimizar sites. Se é possível concordar que um site é uma série de páginas web, também é possível concordar que otimizar para uma única página não é o mesmo que otimizar para todo o site. Páginas não são sites, então é preciso decidir qual será o foco antes de começar a otimizar.
A primeira visita a um site é através de uma página web. Nessa primeira visita, os navegadores fazem cache de recursos externos (assets). Os recursos em cache não precisam ser baixados novamente em visitas subseqüentes. Aproveitar o cache do navegador é uma ótima maneira de otimizar sites, mas não otimiza o tempo de carregamento da primeira visita. De fato, o carregamento de assets reduz a carga inicial. Usar estilos inline não relacionados ao cache do navegador é uma ótima maneira de otimizar a primeira visita, mas de nenhuma maneira otimiza a experiência de navegação do site por inteiro.
Pergunte-se a si mesmo: você está construindo uma única página web na qual as pessoas visitarão uma só vez e nunca retornar ou construindo um site com várias páginas para a maioria dos visitantes ficar usando por um tempo? O conteúdo do site será atualizado com freqüência? Espera-se que os visitantes retornem à página dentro de um curto período de tempo? Independentemente do que as pessoas estão fazendo no site agora, pergunte a si mesmo o que você quer que eles façam e projete para isso!
Usar CSS inline
O custo:
- Não é possível aproveitar o cache do navegador
- HTML mais pesado
- “Payload” do site mais pesado
A recompensa:
- Tempos mais rápidos de carregamento da página visitada
- Sem solicitações HTTP de bloqueio
- Nenhuma latência na recuperação de arquivos em cache
Se a intenção é desenvolver uma experiência “one page” e a única preocupação de desempenho é em relação à primeira vez em que a página carrega, CSS inline faz total sentido. Caso contrário, se a ideia é atualizar essa página ou estimular/prover visitas a outras página do site dentro de um curto período de tempo, CSS inline enviará bytes excessivos em cada solicitação de página subseqüente. Se se mantiver inline apenas o “CSS crítico” — como os primeiros 14kb de CSS ou algo assim — para renderização “acima da dobra”, a quantidade de peso que se está adicionando ao HTML não é tanto assim — especialmente se o GZIP estiver habilitado, isso não diminuirá o tempo do first byte em visitas posteriores.
CSS crítico evita uma solicitação HTTP de bloqueio ao mover estilos em folhas CSS externas diretamente para o HTML; há um “pedágio” que todos os estilos inline devem pagar. Inline CSS evita o cache do navegador e não pode entregar o hiper-desempenho obtido quando os assets são armazenados em cache. Sim, isso melhora o tempo de carregamento percebido na primeira visita, mas este é o única parâmetro digno de preocupação?
Projetando para o sucesso
Há uma diferença entre a otimização de páginas web e a otimização de sites.Tuitar isso
Tuitar isso
Se é preciso um site no qual as pessoas cliquem em vários elementos, é preciso projetar um site para as pessoas clicarem; se é preciso um site cujo conteúdo é atualizado com freqüência, é preciso projetar um site cujo conteúdo é atualizado com freqüência. Design — no real sentido do termo — é sobre a solução de problemas, mas não é apenas problemas imediatos. É preciso dar um passo atrás e considerar os problemas que podem aparecer uma vez atingidas as metas do projeto. Desenvolvedores somos bons designers; somos planejadores. Bons planejadores resolvem problemas, então é preciso planejar!
Uma experiência incrível de site amigável
CSS crítico faz seu site carregar incrivelmente rápido — especialmente em mobile.
A ferramenta Critical CSS poderia ser mais precisa ao informar que faz páginas web carregarem incrivelmente rápido num primeiro acesso. Se a página é atualizada ou se visita outra página do site, na verdade Critical CSS aumenta o payload por não aproveitar o cache do navegador. Se é acessado um URL que usa algum endereço hash para pular para alguma parte da página “abaixo da dobra”, todo o ajuste de desempenho feito para o conteúdo “acima da dobra” aparecer mais rápido foi meio que sem sentido.
Considerando que a Critical CSS muitas vezes aumenta o payload do navegador dos sites, é um tanto que arrojada — para usar um eufemismo — a alegação de melhorar o desempenho mobile de web sites. Como citado, ao se colocar estilos inline há melhoras significativas do desempenho inicial de páginas, mas isso não melhora visitas de retorno a essas páginas ou visitas a outras páginas que fazem uso desses mesmos estilos inline.
Então, já ficou claro que há uma diferença entre a otimização de páginas web e a otimização de sites — deixando de lado a definição técnica de que até mesmo uma página às vezes pode ser um site. Mas como saber qual optar e se você é preciso trocar de uma técnica para outra?
Folhas de estilo externas são “bloqueadoras”, mas, depois da primeira requisição, elas são bastante “gentis”. Com cabeçalhos de cache (cache headers) adequados, arquivos em cache são armazenados no cache do navegador, onde podem ser solicitados novamente sem muita latência. Uma vez que o custo inicial é pago, é possível reentregar os mesmos dados em pedidos subseqüentes praticamente sem custos.
Ficam algumas perguntinhas para reflexão:
- Com 20KB do mesmo CSS crítico inline em 10 páginas diferentes, quantos KB de estilos são enviados?
- Quantas requisições HTTP são feitas para estilos inline?
- Para carregar 20KB dos mesmos CSS críticos de uma folha de estilos externa cacheável em 10 páginas diferentes, quantos KB de estilos são enviados?
- Quantas requisições HTTP são feitas para uma folha de estilos externa?
Aproveitando o cache do navegador
Se se está colocando inline uma média de ~20KB de CSS crítico em cada página e uma pessoa visita 10 páginas que fazem uso desses mesmos estilos, foram enviados 180KB de peso evitável. São ~20KB dos mesmos estilos não cacheados sendo baixados 10 vezes (uma vez para cada página) vs ~20KB de estilos “de bloqueio” sendo baixados uma única vez como parte de um CSS externo comum. O número de visualizações de página médias por pessoa deve ser levado em consideração ao planejar o método de entrega das CSS.
De vez em quando, carregar recursos de CDNs comuns é uma ótima maneira de aproveitar o cache do navegador. Com sorte, a pessoa já visitou outro site que usou a mesma versão dos mesmos frameworks e, quando eles chegam ao site pela primeira vez, esses grandes frameworks não precisam ser solicitados novamente. Um exemplo é o famoso HTML5 Boilerplate, que carregar jQuery a partir de uma CDN comum. Isso significa que todos os sites que utilizam o HTML5 Boilerplate podem se beneficiar da primeira tentativa de carregar a jQuery a partir de uma CDN comum — que já pode ser armazenado em cache no navegador do usuário.
Mas quais são as probabilidades reais de uma pessoa já ter um framework ou bliblioteca já em cache? Melhores que 0, e isso é tudo o que importa, já que não há nenhuma chance de eles estarem em algum tipo de pré-cache se não estiverem sendo carregadas a partir de CDNs comuns.
Não se esqueça do hash!
Em um esforço comprovado para acelerar as primeiras visitas, o CSS crítico esquece de uma coisa importante: o hash de localização.
A propriedade hash de localização permite que qualquer parte de uma página HTML seja diretamente vinculada. Não é seguro assumir que o topo de uma página será sempre a primeira coisa que uma pessoa irá ver. Hashs de locais para links em qualquer parte do site estão sendo usados? É possível que esta seja uma necessidade futura? Há ids em seções e cabeçalhos para que as pessoas possam fazer links diretamente para seções do site por conta própria?
“A dobra”?
Automatizadores de tarefas — como Gulp e Grunt — geralmente possuem módulos automatizados para determinar quais estilos são e não são críticos com base no que está e não está “acima da dobra”. O conceito é que, caso se olhe para o que é exibido no topo de um site em uma viewport de 1024×768, então é possível considerar todos os estilos utilizados nessa seção da página como “crítico” — e tudo o mais como “não-crítico”.
Se alguma vez houve uma “dobra”, o web design responsivo acabou com ela.
Os componentes visíveis dentro de uma viewport de desktop podem ser completamente diferentes dos visíveis em uma viewport mobile. Mas isso não é tudo: folhas de estilo são requisições que bloqueiam a renderização da página por uma razão.
CSS bloqueia a renderização por uma razão
Por padrão, os navegadores fazem cache da maioria das solicitações para folhas de estilo, imagens e arquivos JavaScript externos. A menos que esteja configurado de outra forma, os próprios dados HTML não serão armazenados em cache pelo navegador. Isso ocorre porque os navegadores sabem que o HTML que consomem pode se tornar desatualizado antes mesmo de ser consumido. Permitir que o HTML em si seja armazenado em cache no lado do cliente por um curto período de tempo (ex. 5 minutos) pode ser uma maneira inteligente de fazer com que um site pareça ultra-rápido enquanto é navegado.
Folhas de estilo são destinadas a carregar coisas que a página precisa imediatamente, e é por isso que elas são requisições “bloqueadoras”. Se um projeto usa frameworks como Foundation ou Bootstrap, o peso de CSS pode aumentar rapidamente. A partir daí, o que se segue são folhas de estilo pesadas, carregando em páginas que usam apenas uma pequena porcentagem de seus estilos. O problema principal não é que folhas de estilo externas foram projetadas para bloquear; folhas de estilo em geral foram projetadas para bloquear.
Importante ter em mente:
- HTML geralmente não é cacheado
- CSS externo geralmente é cacheado
Lembretes extras
Eis alguns lembretes extras para serem considerados quando o assunto de CSS inline surgir:
- Use gzip para as CSS
- Use datas de expiração bastante longas
- Sempre que possível, use pré-processadores de CSS
- Faça cache de HTML (não muito longo, somente alguns minutos)
Levando em consideração tais pontos, certamente a qualidade dos projetos web será incrementada. Pense também no seguinte: se o peso de CSS minificado está perto de 100KB, há alguma coisa que pode ser feita para aliviar o payload? Qual porcentagem dos estilos carregados estão sendo usados nas páginas?
Conclusão sobre CSS crítico “acima da borda”
Em relação ao uso ou não uso de CSS inline crítico “acima da borda”, não há uma resposta certa absoluta. Como um desenvolvedor web, cabe a você analisar o projeto em questão para tomar a decisão de usar ou não. Faça testes de desempenho. Teste os (possíveis) padrões de visitantes do site, bem como os que são desejados. Normalmente, os clientes querem sites em que as pessoas retornam e/ou navegam um pouco antes de sair. Pense duas vezes antes de “otimizar” com uma ferramenta que é incapaz de tirar proveito do cache do navegador.
Usar ou não CSS crítico inline “acima da borda”? A melhor resposta para dilemas em desenvolvimento web continua sendo “depende”.