Todos os profissionais de marketing desejam sites envolventes. Nossos clientes querem bons sites.
Pesquisas mostram que queremos sites de renderização rápida, em menos de 3 segundos.
Google e Bing pontuam páginas sobre a rapidez com que são renderizadas e usadas como um fator de classificação.
Mas como a velocidade da página se relaciona com a obtenção de melhores resultados de pesquisa?
Brian Dean postou um vídeo de pequeno estudo anedótico que ele realizou para determinar como a velocidade da página afeta o page rank.
Esse tipo de estudo sempre atrai minha atenção porque a velocidade da página é uma paixão e especialidade minha.
Se você não sabe, Brian administra um site de SEO muito popular e um canal no YouTube, onde costuma compartilhar pesquisa aprofundada.
Essa pesquisa, combinada com sua capacidade de fornecer conteúdo, é a razão de seu site e seus vídeos serem tão populares.
Mas às vezes pesquisas e estudos são falhos.
Isso pode levar os seguidores a tomar decisões ruins que afetam seu sucesso online.
O estudo recente de Brian é falho.
Suas conclusões levarão muitos por um caminho de destruição. (reproduza um clipe de áudio sinistro aqui)
Brian notou que muitas páginas de alta classificação eram lentas. E se perguntou como eles poderiam classificar se a velocidade da página é importante?
Nos últimos anos, o Google e a Microsoft declararam que a velocidade da página é usada para classificar as páginas. Como as páginas lentas são classificadas, Brain queria ver se isso importava.
Sua pesquisa se concentrou em um pequeno estudo de caso de uma página. Ele mexeu em uma página em seu site .
Ele fez a página’carregar mais rápido’para ver como isso afetou a classificação da página.
Ele escolheu esta página porque ela está classificada na primeira página do Google para’Dicas de SEO’.
Este é um termo de pesquisa de baixo volume, mas tem uma competição super alta. Também é de interesse para mim, pois tenho uma página com mais de 20 dicas de SEO que quero mostrar nos resultados.
O método de pesquisa perdeu as principais métricas e mostra uma falta de conhecimento sobre como a velocidade da página é medida. Vou cobrir os pontos principais neste artigo e mostrar como sua pesquisa é falha.
Também fiz uma versão rápida da página para comparar.
Infelizmente, a maioria dos profissionais de marketing de pesquisa não entendem como a página a velocidade é medida. Ainda mais desenvolvedores perdem essas métricas também. Honestamente, os desenvolvedores parecem ignorar qualquer coisa relacionada à experiência do usuário. Mas essa é minha experiência pessoal de trabalho com desenvolvedores.
Portanto, preste atenção, vou demonstrar muitos erros comuns neste artigo.
Também dediquei um tempo para criar uma versão melhor otimizada de seu página. Eu medi a velocidade da página com a ferramenta Google PageSpeed Insights e WebPageTest.
Você deve colocar a velocidade da página como regra principal para suas páginas. Você também deve atingir 3 segundos ou menos no celular.
Mas o que significa uma boa pontuação ou tempo de velocidade da página?
Como você pode medir a velocidade da página?
Como você pode consertar seu site?
E a velocidade da página é importante?
Reviso as respostas a essas perguntas e muito mais. Também compartilharei correções para a página de Brian. No processo, você verá um erro comum que impede a maioria dos sites.
Também demonstro por que seus resultados são, na melhor das hipóteses, inconclusivos.
Se você quiser ver meu página otimizada, basta carregá-la para você .
O código-fonte está em GitHub .
Examinando a página de teste de Brian para uma linha de base
Brian escolheu a página de dicas de SEO porque ela teve uma pontuação baixa em Google PageSpeed Insights e WebPageTest .
Primeiro, deixe-me aplaudir sua escolha de também ls. O teste do Google PageSpeed Insights é muito bom e, claro, fácil de ler os resultados.
WebPageTest é a ferramenta de teste de velocidade de página definitiva porque é muito completa. Obviamente, é minha ferramenta de velocidade de página favorita.
Mas, usando essas ferramentas e procurando no nível superior, as pontuações não são onde você deseja se concentrar.
Você deve olhar para os detalhes de baixo nível e pensar como um navegador.
Como Brian melhorou a velocidade da página
Primeiro, vamos revisar algumas das principais coisas que Brian disse foram’melhorados’.
A primeira coisa que ele compartilhou foi que a página usa muitas imagens grandes. Existem muitas imagens. Ele está usando imagens responsivas, então elas não são fisicamente (dimensões) muito grandes.
Ele está usando o formato de imagem errado para muitos e eu irei tocar nisso mais tarde.
Quando eu analisou a página, requer mais de 600 imagens!
Vou direto ao assunto e compartilhar um spoiler, as imagens não são problema do Backlinko.
Ele apontou que a página é longa e páginas mais longas demoram mais para carregar.
Embora haja alguma verdade nisso, não é por isso que a página Backlinko’carrega lentamente’.
Eles cortaram parte do JavaScript frívolo, que ajuda o site a renderizar mais rápido.
Eles também reduziram a carga útil do CSS, novamente sempre uma boa ideia. E depois de limpar o CSS da página eu concordo. Eu removi quase 1 MB de CSS sozinho.
Eles também fizeram algumas coisas que realmente tornaram a página mais lenta, como remover o favicon. Escrevi sobre favicons e velocidade da página.
No final, a página marcou 100 no Google Page Speed Test, o que é incrível.
Mas, depois de algumas semanas, o esforço não mudou a agulha no ranking de pesquisa, o objetivo alvo.
Por quê?
Espere um pouco, vou chegar ao porquê em breve.
Primeiro, vamos ver alguns números.
Pontuação e recomendações do teste Page Speed do Backlinko
Não sei exatamente quais eram as pontuações da página antes do esforço. Mas Brian disse que eles reverteram tudo após o teste para ter uma página’lenta’.
Então, acreditando em sua palavra, posso executar o mesmo teste para obter alguns dados e descobrir como corrigir o falhas.
Primeiro, obtenho uma pontuação de 15 no Teste de Velocidade de Página, que é próxima ao que Brian compartilhou. Qualquer ferramenta de teste apresentará pequenas flutuações. Você deve sempre executar vários testes, em diferentes locais, dispositivos clientes e navegadores.
O primeiro número que se destaca para mim é a primeira dor de conteúdo. Este é o tempo que leva antes que um pixel significativo seja renderizado.
3,2 segundos é lento, mas não é o fim do mundo.
As outras vezes estão fora das tabelas, mal na superfície. Mas você precisa saber o que está sendo medido. E sim, eles são ruins por causa das imagens.
Em seguida, há uma série de avisos, que abordarei um pouco mais quando chegar ao que WebPageTest me diz.
Cada um desses avisos é devido a configuração incorreta URLs de imagens vermelhas, uma correção simples.
Um ponto-chave que o teste revela é’adiar imagens fora da tela’. Este é um ponto-chave que ajudará as páginas de Brian.
Se Backlinko imagens carregadas lentamente e outros recursos o uso de dezenas de imagens não atrasaria a página. Não importa quantos e quão grandes são os arquivos.
As imagens não carregariam até que o visitante as rolasse para a visualização. É assim que configuro todos os meus sites.
Também adio qualquer incorporação no YouTube. Eu tenho um pequeno script que injeta os scripts do YouTube quando o usuário deseja reproduzir o vídeo. Isso impede que cerca de 500kb de JavaScript do YouTube carreguem até o momento necessário.
Em vez disso, carrego a miniatura do vídeo como um espaço reservado. Quando clicado, ele alterna o código real do YouTube. Como a maioria dos leitores não assiste ao vídeo, isso os impede de sentir a pesada taxa do JavaScript.
Mas há mais coisas que podemos aprender com os detalhes que o WebPageTest nos diz.
Resultados WebPageTest
Fiz um teste usando o local principal em Washington DC. O teste usa uma conexão de Internet a cabo padrão e Chrome .
Portanto, desktop.
Você pode executar um WebPageTest em muitos locais ao redor do mundo. Você também pode usar diferentes combinações de navegador e muito mais. Eu mantive-o simples porque obtive os dados de que preciso neste teste.
À primeira vista, vejo coisas ruins, cara, coisas ruins.
Antes de mergulhar nos detalhes, é importante para esclarecer como medir a velocidade da página.
Muitos acham que a velocidade da página é o tempo que o navegador leva para’carregar’uma página do servidor.
É hora do primeiro byte. Este não é um problema comum hoje. Se você tiver gargalos do lado do servidor, isso pode matá-lo antes de começar.
Um bom momento para o primeiro byte é de 250-500 milissegundos.
Backlinko é bom neste departamento.
Em vez disso, acelere a página sobre a renderização do conteúdo e a interação. É por isso que WebaPageTest é a melhor ferramenta para medir a velocidade da página. Você obtém um conjunto profundo de detalhes para ver o que um usuário real experimenta.
Primeiro, 624 solicitações! Sério?
Isso deveria ser ilegal.
Imagens e recursos de carregamento lento resolverão a maior parte do problema.
Para o registro, conto 3 imagens que resolveriam ser carregado antecipadamente se a página carregar lentamente as imagens.
Se eu olhar para o número de imagens solicitadas em meu navegador, vejo 413. Apenas 588 solicitações.
A discrepância total de solicitação se deve a uma extensão de bloco de anúncios.
Imagens de carregamento lento devem reduza o impacto inicial em 410 solicitações!
Pontuação!
Você deve sempre tentar limitar o número de conexões HTTP para carregar uma página. As solicitações HTTP são caras de criar. É por isso que HTTP/2 é importante. Ele gerencia conexões HTTP de forma eficiente.
Uma observação lateral. As imagens não são o verdadeiro problema com a velocidade da página, sim o JavaScript.
O que é bloqueio versus não bloqueio?
Imagens não são uma operação de bloqueio. Eles são carregados em um thread separado.
O JavaScript é carregado no thread de IU principal. Ele bloqueia toda a renderização enquanto o script é carregado, avaliado e executado. Este é o principal motivo pelo qual você precisa evitar o excesso de JavaScript.
A página de Brian tem excesso de JavaScript.
A maioria das páginas sofre com isso hoje.
Comentário pessoal aqui: A maioria dos desenvolvedores está mais interessada em escrever mais código do que em fazer uma página carregar rapidamente. É por isso que as cargas úteis de JavaScript médias estão crescendo além de 5 MB, quando 20-50 kb bastam.
29 Solicitações de JavaScript, não o pior I tem visto. Mas carrega impressionantes 3,3 MB de JavaScript. Isso é como carregar 500 MB de imagens, pelo menos é o que vou relacionar também.
Muitos dos scripts eram duplicados. Solicitações desperdiçadas, largura de banda e processamento extra com ganho de 0.
Só para me gabar um pouco. Reduzi a carga útil do JavaScript para 4kb (há algumas ressalvas que abordarei mais tarde).
Um artigo como as dicas de SEO do Backlinko não precisa de muito JavaScript. Algumas dezenas de kilobytes devem bastar.
Eu sei, eu crio páginas como esta o tempo todo.
O efeito de terceiros
Se olhamos para o mapa de solicitação da página, ele não é terrível, comparado a muitos que eu analisei.
Existem 2 sistemas solares de script distintos que podem ser completamente eliminados.
Um, o grupo verde-azulado à esquerda, é o gânglio do script do YouTube. Aplicando minha abordagem de carregamento lento, eles são completamente removidos.
Em seguida, estão os scripts laranja, todos relacionados ao OptinMonster. É assim que Brian coleta e-mails para seu boletim informativo.
Eu odeio esses scripts de terceiros. Brian pode agilizar a forma do lead magnet escrevendo HTML simples, algumas linhas de JavaScript e CSS.
Eu mudei para usar algumas linhas com base no IntersectionObserver.
Enquanto eu limpava nesta página do meu teste encontrei blocos e blocos de scripts injetados, CSS e HTML do OptinMonster.
Dezenas de blocos foram duplicados, uma prática ruim. Este é um teste fácil para determinar a qualidade do código e a qualidade do OptinMonster é muito ruim.
Fiz uma triagem simples nos estilos inline do OptinMonster e consegui remover mais de 200kb de carga útil.
Uma rápida varredura em seu CSS foi uma lição de como não escrever CSS. Muitos erros tornaram óbvio que eles não se importam com a qualidade do produto.
Várias repetições de classe, estilos em linha, regras duplicadas e seletores altamente especificados. Eu poderia escrever um artigo de 5.000 palavras sobre como não escrever CSS usando o código deles.
Tantos códigos cheiram mal.
Embora o CSS não seja tão pesado quanto o JavaScript, ainda é uma chatice renderização de página.
Minhas páginas passam por uma etapa de otimização CSS que extrai apenas as regras CSS usadas pela página. Em seguida, ele alinha os estilos no documento HEAD. Como a maioria das páginas precisa de 1-5kb de CSS, isso pode ter um impacto perceptível na velocidade da página.
Além disso, só precisa ser executado quando o conteúdo da página é atualizado, não a cada solicitação.
Ao limpar a página, encontrei cerca de 1 MB de CSS. Eu reduzi isso para cerca de 35kb e ingressei no documento HEAD.
Vou observar, fiz uma limpeza rápida. Para torná-lo o mais pequeno possível, eu começaria do zero, até mesmo o HTML. Com toda a honestidade, eu poderia reduzir a carga útil combinada de HTML e CSS para menos de 100 kb.
Ainda havia dezenas, senão centenas de estilos inline declarados nos elementos. Esta é uma prática horrível e deve ser evitada por vários motivos.
Como observação. Quando você usa um terceiro, está terceirizando seu sucesso com a qualidade dele.
No caso de Brian, ele leva um duro golpe com esse terceiro. Em última análise, ele paga por isso trabalhando mais para construir uma marca ou simplesmente sangrando receita adicional.
Isso é comum quando você assina um serviço de terceiros. Eles normalmente fornecem código de baixa qualidade. Isso reduz sua capacidade de converter visitantes em clientes mais do que ajudam.
Escrever código vanilla eliminaria algumas dezenas de solicitações e dependências externas. Também reduz o tamanho da marcação e CSS de forma mensurável.
Você ainda pode coletar e-mails. Se o back-end do OptinMonster valer a pena, você deve ser capaz de fornecer as informações para sua API. Seu front-end não vale a pena usar.
Eu adicionei algumas linhas de JavaScript para mostrar seu formulário de lead e postar o e-mail de volta em uma API.
Sim, de verdade, página de produção, eu colocaria um pouco mais de esforço no roteiro do pop-up. Mas acrescentaria um punhado de linhas JavaScript, não megabyte.
Lembre-se de que estou tentando trabalhar dentro dos limites de uma página existente.
De volta ao conteúdo de carregamento lento.
O artigo não usa 413 imagens, isso seria incrível.
A maioria das imagens são pequenas fotos de comentaristas. Cada vez que um comentário é adicionado, o sistema de comentários do Backlinko busca a foto do gravatar.
Um toque legal de personalização!
Mas adiciona peso e a maioria dos visitantes não se preocupa com os comentários.
Em vez disso, toda a seção de comentários deve ser carregada lentamente.
Claro, o spider do mecanismo de pesquisa não lerá esses comentários. Mas estou no acampamento. Os comentários não agregam valor ao SEO. Sei que alguns estudos afirmam que sim, mas duvido.
Acredito que os artigos com grandes cadeias de comentários tenham uma classificação melhor porque têm bons sinais de classificação. Os comentários são um produto natural.
Eu poderia fazer um discurso fora do assunto aqui, então vou poupá-lo para ficar focado em tornar suas páginas melhores.
Se você deseja um bom exemplo de comentários de carregamento lento, não procure além do YouTube. Os comentários não são carregados por padrão, você deve rolar para baixo para acionar sua carga. Siga esse exemplo.
Eu configurei isso na minha versão da página.
Como cerca de 95% das imagens na página são imagens do Gravatar, todos esses pedidos vão embora!
HTML limpo
Antes de prosseguir, quero dizer algo sobre HTML limpo. Mesmo depois de limpar a página, o HTML tinha 241kb. Isso é muito grande, mesmo para um artigo de 10.000 palavras.
Isso se deve ao HTML aninhado e aos estilos embutidos. Não mudei a estrutura HTML para este teste.
Eu olhei para ver se havia alguma triagem rápida a ser realizada. O aninhamento me assustou, já que esse é um tipo de esforço de conserto rápido.
Das áreas, me preocupo com a profundidade do HTML é a última coisa. O HTML é processado muito rapidamente pelos navegadores. Sim, o Backlinko poderia remover cerca de 50% da marcação, mas seria um esforço monumental sem apenas começar do zero.
Se você deseja um pedido para corrigir problemas, siga esta lista:
- JavaScript
- Reduza o número de solicitações HTTPS
- Recursos de carregamento lento
- CSS
- imagens
- HTML
Otimização de imagem
A última coisa que irei apontar é otimizar imagens.
Eu disse antes que imagens não eram o principal problema. Vou manter essa afirmação.
Quando você vê imagens gerenciadas tão mal quanto as do Backlinko, é difícil não trabalhar nelas.
Com base em meu WebPageTest executado, cerca de 25 MB da carga útil de 35 MB são imagens.
Minha versão começa com 157kb e termina com 8,7MB, sem contar as fotos do Gravatar.
Uma ressalva.
Há um arquivo gif animado usado na página que pesa quase 10 MB. Não incluí isso no meu total.
Não modifiquei esse arquivo ainda. Eu posso no futuro. Mas me preocupei que isso quebrasse a animação.
No entanto, recomendo mudar para um vídeo, que será menor.
A animação não agrega valor à mensagem. Mudar para um jpg mostrando parte deste infográfico seria ainda melhor.
Pelo que posso dizer, Brian pode não saber que o formato de imagem jpg existe. Ele usa apenas arquivos PNG.
Portable Network Graphics (PNG) é um formato de imagem para arte de linha ou ilustrações. Pode ou não ser mais eficiente do que GIFs, mas é péssimo para fotografias.
Muitas imagens que a página de destino carrega são fotos ou são melhores usando jpg. O formato PNG os torna muito grandes.
Vou demonstrar com uma única imagem:
Como um PNG, o tamanho do arquivo é 408kb. Otimizar o PNG reduz o tamanho do arquivo para 280kb.
Mas alterar o formato para jpg reduz o tamanho do arquivo para 72kb. Isso é uma economia de 336kb!
Agora, vamos dimensionar isso para todas as imagens. Presumindo economias semelhantes para todas as 413 imagens, Brian poderia reduzir a carga útil (desktop) em 35 MB ou mais!
É claro que algumas imagens devem ser PNG ou GIF. Posso jogar e ver se consigo um número preciso.
Eu escrevi um script de nó simples para comparar as duas versões localmente. Ele atualiza o HTML para fazer referência à versão de tamanho de arquivo menor.
Todos esses itens acionáveis devem ser aplicados pela maioria dos sites. Olhar para a cascata da página manteria a página abaixo do limite de 3 segundos.
Mas há mais uma coisa que se destaca.
Fazendo referência adequada às dependências da página
Observou todo o amarelo na cachoeira?
Those are typically network requests without a Cache-Control header.
Not in this case!
Backlinko has image requests that generate a 301 redirect response.
Why?
The site references the images using the CDN origin instead of the images on backlinko.com. The CDN domain has an auto redirect (301 status code) to backlinko.com.
This means there is an extra, expensive, network request and hop back to the site. I count about 85. Those references need to change to use the backlinko.com domain, not the CDN alias.
You want to reference everything on your domain, not an external domain when you can. HTTP connections are expensive to create.
Brian is using HTTP/2, which everyone should be utilizing. This optimizes the connection to the origin.
Its one of the many reasons why all sites should use a content delivery network service. They all support HTTP/2, a more optimized delivery protocol.
Final optimizations I made were to use intersectionObserver to lazy load the comments. It uses a simple fetch call that sets the comments to the innerHTML of the comment wrapper.
I also displayed one of his pop-ups as the user scrolls the second H2 (sub heading) into view. It is visible for 10 seconds.
For a real, production version my pop-up code would be a little more sophisticated. But not much more code required.
After I performed my triage on the page my version was fully loaded in 1.06 seconds. The speed index is 513 or.513 seconds.
The initial payload is less than 147kb before unzipping the text assets. 423kb after unzipping those files.
There are 11 initial requests.
I also did not include Google analytics code or tracking pixels. On my site the analytics code is the biggest drag to pages loading. However the script is loaded asynchronously.
As for tracking pixels I use just the pixel, not the slow scripts most sites use.
There are dozens of other optimizations Brian could make on his site. I did the big ones staring me in the face.
My version scored 100 in the Google page speed test.
Of course my version is not ranked, nor am I looking to have it rank. So I can’t test that part. But I can speculate.
The Baseline-Does Page Speed Affect SEO Rank?
The simple answer is, it’s complicated.
But, what Brian did to speed up his page did not really speed it up! At least not in the way actual page speed is measured.
You see Brian was looking at total time for all assets to load. Not time to render or first interaction.
It is the time to first interaction that really matters.
Why?
As I mentioned earlier JavaScript blocks or locks the UI. Images don’t.
Backlinko loads a lot of images on its pages. They add real value to the content. At least the images in the article.
But they do not slow the rendering process.
If you look at the Speed Index, it is a key metric for actual page speed, it is not bad. Speed Index measures how much of the visible page rendering over time.
It focuses on when above the fold pixels are rendered using some basic calculus.
In my test it was 3 seconds, not bad.
All the optimizations Brian made affect time after this point. Not what search engines are looking for.
If the user can scroll the page, it is interactive. If the page is locked while scripts are being evaluated that is bad.
But an image loading 10’page down taps’away from the initial view is not’disrupting’the page’s usability.
This is why Brian’s effort had a minimal impact.
Now if Brian’s updates had moved the time to interaction needle closer to 1 second there might have been a tangible movement in ranking.
I think there is more we can learn.
Evaluating the Competition
This leads me to a final chapter in this saga.
How does the competition fare?
I mean Brian did this study because he routinely sees slow paging ranking high.
Why?
Lets look at the remaining top 10’seo tips’results.
HubSpot-4.6s speed index GoinesWriter-9.252s speed index AHrefs-2.954s speed index Neil Patel-1.211s speed index OptinMonster (Ironic I know)-1.59s speed index Search Engine Journal-2.851s speed index Entrepreneur-2.963s speed index Databox-4.319s speed index
I will note the AHrefs article has over 75 tips, the most of any article on page one. Yet the page is the smallest, 650kb!
They also do not support user comments, just an observation.
Why?
They lazy load content, a primary recommendation I made in this article!
By the way, I can see a few low hanging fruits to improve the AHrefs page even more 😉.
For the record I have a rather long article on SEO Tips myself. My page has more tips than Brian’s and might even be longer. It also loads way faster.
It sports a 1.3s speed index score and is fully loaded in 2.15 seconds.
The initial payload size is 196kb, even better than AHrefs 😋.
It is not even listed in the top 100 for’seo tips’in the Google results!
Why?
Most likely because I don’t have any competitive backlinks coming to the article.
This is a very competitive keyword. The serps are owned by some big names throwing domain authority around. These articles also tend to have very strong backlink profiles.
At the same time, traffic is limited. Maybe 3000 global searches per month. But it has business value so effort is put into those first page rankings.
This means it is difficult to move those listings.
I mean the first result, as I write this article, is the GoinesWriter article. It has 9+ second speed index score, the worst of the bunch!
But I think the site has other signals that overpower everything else. This could be backlinks, direct traffic, social signals (do those really matter?), etc.
In other words, there are over 200 known ranking factors (according to Backlinko). The GoinesWriter article has other things going for it.
Brian does need to improve the user experience by improving page speed. He could cut the actual page render time by a second or more.
This might, after a month or so move him up one or two positions.
In the end applying these optimizations will save visitors bandwidth. It will also reduce Backlinko’s server load and monthly bandwidth charges.
Getting more links would move the needle more.
I have a theory. If you want more backlinks make a faster page!
You see, page speed can be measured and it is a single signal.
But it does not stand alone. Page Speed affects most of the remaining signals because it changes visitor behavior.
Visitor behavior is expensive to measure.
If you give them a good user experience they will behave more favorably. This lifts your site and page profile in the eyes of search engines.
Brain gave it 2 weeks. This was not enough to change Google’s page profile. My gut tells me they keep a running average profile for your page. The page has some decent age on it thus an established history.
A two week anomaly may not be enough to move the needle.
Also consider the page gets 150 weekly page views. I bet a decent amount are direct due to Brian’s brand engagement. This also reduces some signals to the search engine.
150 page views is not many. Not enough to generate enough real data to move a needle over 2 weeks.
If there were 1500 a week then you would be at a level that might matter in a 2 week span.
I know having fast pages are a key reason why my site ranks well for thousands of keywords. But I am not naïve in thinking it is the only reason.
For now, backlinks are still king. Google and Microsoft guidelines are key to creating quality content and user experience.
As I complete this article Brian’s page has moved to #2 on Bing and #6 on Google. I suspect this is due to increased links and page views due to his page speed study.
Happy customers translates to better search rankings, which of course brings more visitors. It is a wonderful cycle.
Summary
Every site can and should improve page speed. Even me!
But sometimes it is not the problem.
In Brian’s small case study there are many factors at play. The level of competition for this low volume keyword make it tough to move the needle.
His pages do not reach time to first interaction in a terrible time frame. Compared to the other top ten results the Backlinko site is within tolerance.
The test page has around 200 backlinks. I did not do a formal backlink profile compared to the competition. It might be weak compared to the top results.
Unfortunately, Brain has shared that page speed does not seem to be a ranking factor.
This is wrong.
Brian did not measure his existing time to first interaction. Instead focused on the wrong metric, final load time, and fixed the wrong page issues.
Or more accurately, did not correct issues the right way.
It pays to understand how a browser renders content. You also need to know what search engines mean by page speed.
Once you understand things like the critical rendering path and how different assets are processed you can design your pages to load super fast.
Fast pages make visitors happy. Happy visitors convert to happy customers, at least eventually. And that is what we really want.
Search engines know what people want and they reward you for matching those signals.
Page speed is the foundation of good user experience and collectively that impacts your page authority.
My optimized version can be studied here.
Note: As I go to publish Brian has updated the article header. My numbers are based on the target page the day I first watched his video.
