Neste episódio, estamos falando sobre desempenho na web. Como será o cenário de desempenho em 2021? Falei com o especialista Harry Roberts para descobrir.
Mostrar notas
Harry está realizando um workshop Web Performance Masterclass com Smashing em maio de 2021. Na época, de publicação, grandes descontos para madrugadores ainda estão disponíveis.
- Harry no Twitter
- Site de consultoria de Harry CSS Wizardry
- Vídeo do curso Tudo o que fiz para tornar o CSS Wizardry rápido incluindo 15% de desconto
- Perguntas para consultores e-book incluindo 15% de desconto
- Guia Web.dev para Web Vitals
- A batedeira de ovos OXO GoodGrips favorita de Drew 😉
Atualização semanal
- Tendências de Web Design 2021: O relatório escrito por Suzanne Scacca
- Usando aplicativos Grommet In React escritos por Fortune Ikechi
- Como construir uma API Node.js para Ethereum Blockchain escrito por John Agbanusi
- Como melhoramos o desempenho do SmashingMag escrito por Vitaly Friedman
- Quando dizer não aos projetos autônomos escrito por Becca Kennedy
Transcrição
Drew McLellan: Ele é um consultor independente Web Performance Engineer de Leeds, no Reino Unido. Em sua função, ele ajuda algumas das maiores e mais respeitadas organizações do mundo a oferecer experiências mais rápidas e confiáveis a seus clientes. Ele é um Google Developer Expert convidado, um Cloudinary Media Developer Expert, um desenvolvedor premiado e um palestrante internacional. Então, sabemos que ele sabe o que fazer quando se trata de performance na web, mas você sabia que ele tem 14 braços e sete pernas? Meus amigos sensacionais, por favor, dêem as boas-vindas a Harry Roberts. Oi Harry, como você está?
Harry Roberts: Ei, estou arrasando, muito obrigado. Obviamente, os 14 braços, sete pernas… ainda apresentando seus problemas usuais. Impossível comprar calças.
Drew: e bicicletas.
Harry: Sim. Bem, eu tenho três bicicletas e meia.
Drew: Eu queria falar com você hoje, não sobre bicicletas, infelizmente, embora isso já fosse divertido. Eu queria falar com você sobre o desempenho na web. É um assunto pelo qual estou pessoalmente apaixonado, mas é uma daquelas áreas em que me preocupo, quando tiro meus olhos da bola e me envolvo em algum tipo de outro trabalho e depois volto a fazer um pouco de trabalho performático, Tenho medo de que o conhecimento com que estou trabalhando fique desatualizado muito rápido… O desempenho da web está evoluindo tão rápido hoje em dia quanto eu percebo?
Harry: Isso é… Eu não estou dizendo isso apenas para ser legal com você, essa é uma pergunta muito boa porque tenho pensado muito nisso ultimamente e diria que há duas metades disso. Uma coisa que eu tentaria dizer aos clientes é que, na verdade, isso não acontece tão rápido. Predominantemente porque, e esse é o soundbite que sempre uso, pode apostar no navegador. Na verdade, os navegadores não têm permissão para mudar fundamentalmente a forma como funcionam, porque, é claro, há duas décadas de legado que eles precisam manter. Então, geralmente, se você aposta no navegador e sabe como esses componentes internos funcionam, e o TCP/IP que nunca muda… Então, certas coisas que são bem definidas, o que significa que as melhores práticas irão, em geral, sempre seja a melhor prática no que diz respeito aos fundamentos.
Harry: O que fica mais interessante é… O que estou vendo cada vez mais é que estamos perdendo o controle quando se trata de problemas de velocidade do site. Então, na verdade, criamos muitos problemas para nós mesmos. Então, o que isso significa realisticamente é desempenho… é a trave móvel, suponho. Quanto mais a paisagem ou a topografia da web muda, e a maneira como ela é construída e como trabalhamos, colocamos novos desafios a nós mesmos. Portanto, o advento de fazer muito mais trabalho no cliente apresenta problemas de desempenho diferentes do que estaríamos resolvendo cinco anos atrás, mas esses problemas de desempenho ainda dizem respeito à parte interna do navegador que, em geral, não mudou em cinco anos. Então, muito depende… E eu diria que há definitivamente dois lados claros para isso… Eu incentivo meus clientes a se apoiarem no navegador, nos padrões, porque eles não podem simplesmente ser alterados, os postes não realmente não se mova. Mas, é claro, isso precisa ser combinado com práticas de desenvolvimento mais modernas e, talvez um pouco mais interessantes. Então, você fica com seu… Bem, eu ia dizer”Um pé em ambos os campos”, mas com meus sete pés, eu teria que… quatro e três.
Drew: Você mencionou que os fundamentos não mudam e coisas como TCP/IP não mudam. Uma das coisas que mudaram em… eu digo”últimos anos”, isso provavelmente está voltando um pouco agora, mas é o HTTP, pois tínhamos esse protocolo HTTP estabelecido para comunicação entre clientes e servidores, e isso mudou e então temos H2, que é binário e diferente. E isso mudou muito o… Foi por questões de desempenho, foi para tirar algumas das limitações existentes, mas isso foi uma mudança e a maneira que tínhamos de otimizar para aquele protocolo mudou. Isso agora está estável? Ou vai mudar de novo, ou…
Harry: Então, uma coisa que eu gostaria de aprender mais é sobre a última metade da questão, a mudança novamente. Preciso pesquisar mais sobre o QUIC e o H3, mas está um pouco longe da esquina para ser útil para meus clientes. Quando se trata de H2, as coisas mudaram bastante, mas eu realmente acho que H2 é uma grande promessa falsa e acredito que foi apressado, o que é notável considerando que H1 foi lançado… E quero dizer 1.1, foi 1997, então temos muito tempo para trabalhar no H2.
Harry: Acho que o principal benefício são os desenvolvedores da web que entendem ou percebem que é ilimitado em solicitações de voo agora. Portanto, em vez de seis solicitações despachadas e/ou seis em vôo ao mesmo tempo, potencialmente ilimitadas, infinitas. Porém, traz problemas realmente interessantes porque… é muito difícil de descrever sem recursos visuais, mas você ainda tem a mesma quantidade de largura de banda disponível, esteja você executando H1 ou H2, o protocolo não torna sua conexão mais rápida. Portanto, é bem possível que você possa inundar a rede solicitando 24 arquivos de uma vez, mas você não tem largura de banda suficiente para isso. Então, você não fica realmente mais rápido porque só consegue gerenciar, talvez, uma fração disso de cada vez.
Harry: E também o que você precisa pensar é como os arquivos respondem. E esta é outra dica profissional que analiso em workshops de clientes etc. As pessoas olharão para uma cascata H2 e verão que, em vez das tradicionais seis solicitações de despacho, podem ver 24. Despachar 24 solicitações não é realmente útil. O que é útil é quando essas respostas são retornadas. E o que você notará é que pode despachar 24 solicitações, então seu lado esquerdo de sua cascata parece muito bom e íngreme, mas todos eles retornam de uma maneira bastante escalonada e sequencial porque você precisa limitar a quantidade de largura de banda para você não pode preencher todas as respostas ao mesmo tempo.
Harry: Bem, a outra coisa é se você cumprisse todas as respostas ao mesmo tempo, estaria intercalando as respostas. Então, à noite, você obtém os primeiros 10% de cada arquivo e os próximos 20%… 20% de um arquivo JavaScript é inútil. JavaScript não pode ser usado até que 100% dele tenha chegado. Então, o que você verá é, na verdade, a maneira como uma cachoeira H2 se manifesta quando você olha para a resposta… Parece muito mais com H1 de qualquer maneira, é muito mais escalonada. Então, H2, acho que foi exagerado, ou talvez os engenheiros não tenham sido levados a acreditar que existem limites sobre o quão eficaz poderia ser. Porque você verá pessoas fragmentando demais seus ativos e podem ter vinte… vamos manter o número 24. Em vez de ter dois grandes arquivos JS, você pode ter 24 pequenos pacotes. Eles ainda retornarão de forma bastante sequencial. Eles não chegarão todos ao mesmo tempo porque você não conseguiu aumentar a largura de banda.
Harry: E o outro problema é que cada solicitação tem uma quantidade constante de latência. Digamos que você esteja solicitando dois arquivos grandes e uma viagem de ida e volta de cem milissegundos e 250 milissegundos de download, ou seja, duas vezes 250 milissegundos. Se você multiplicar até 24 solicitações, ainda terá latência constante, que decidimos 100 milissegundos, então agora você tem 2.400 milissegundos de latência e 24 vezes… em vez de 250 milissegundos de download, digamos que são 25 milissegundos download, na verdade leva mais tempo porque a latência permanece constante e você apenas multiplica essa latência por mais solicitações. Então, verei clientes que terão lido que H2 é essa bala mágica. Eles vão se fragmentar… Oh! Eles não podiam simplificar o processo de desenvolvimento, não precisamos fazer empacotamento ou concatenação etc. E, no final das contas, vai acabar mais lento porque você conseguiu distribuir suas solicitações, o que era a promessa, mas sua latência permanece constante, então você na verdade acaba de obter n vezes mais latência no navegador. Como eu disse, é muito difícil, provavelmente inútil tentar explicar isso sem os recursos visuais, mas é notável como o H2 se manifesta em comparação com o que as pessoas esperam que ele possa fazer.
Drew: ainda existe benefício nesse processo de fragmentação, certo, obter o lote inteiro ainda leva a mesma quantidade de tempo, mas quando você conseguir 100% do primeiro 24º de volta, poderá começar a trabalhar nisso e você pode começar a executá-lo antes do final do dia 24.
Harry: Oh, cara, outra ótima pergunta. Então, absolutamente, se as coisas correrem corretamente e ela se manifestar em uma resposta mais parecida com H1, a ideia seria o arquivo um retorna primeiro, dois, três, quatro, e então eles podem ser executados na ordem em que chegam. Portanto, você pode realmente encurtar o tempo agregado garantindo que as coisas cheguem ao mesmo tempo. Se dermos uma olhada em uma página da web em vez de em cascata e você perceber que as solicitações estão intercaladas, isso é uma má notícia. Porque, como eu disse, 10% de um arquivo JavaScript é inútil.
Harry: Se o servidor fizer seu trabalho corretamente e enviar, enviar, enviar, enviar, enviar, ficará mais rápido. E você tem os benefícios indiretos de sua estratégia de cache pode ser mais granular. Tão irritante seria você atualizar o tamanho da fonte em seu widget selecionador de data. No mundo H1, você precisa armazenar em cache talvez 200 quilowatts do CSS do seu site. Enquanto agora, você apenas armazena em cache busto datepicker.css. Portanto, temos benefícios adicionais como esses, que são definitivamente muito valiosos.
Drew: Acho que, no cenário em que você magicamente recebia todos os seus pedidos de volta de uma vez, isso obviamente atrapalhava o cliente, não é?
Harry: Sim, potencialmente. E então o que realmente aconteceria é que o cliente teria que fazer uma carga de agendamento de recursos, então o que você acabaria com uma cascata onde todas as suas respostas retornariam ao mesmo tempo, então você teria uma lacuna bastante grande entre os chegada da última resposta e sua capacidade de execução. Então, idealmente, quando estamos falando sobre JavaScript, você gostaria que o navegador solicitasse todos eles na ordem de solicitação, basicamente a ordem em que você os definiu, o servidor para retorná-los todos na ordem correta para que o navegador possa executar na ordem correta. Porque, como você disse, se todos eles retornassem ao mesmo tempo, você acabaria de ter um enorme JavaScript para executar de uma vez, mas ainda precisa ser programado. Assim, você pode ter uma dúvida de até um segundo entre a chegada de um arquivo e sua utilidade. Então, na verdade, H1… Acho que, idealmente, o que você está procurando é a programação de solicitações H2, respostas de estilo H1, para que as coisas possam ser úteis à medida que chegam.
Drew: Então você está basicamente procurando uma cachoeira de resposta que pareça que você poderia esquiar por ela.
Harry: Sim, exatamente.
Drew: Mas você não precisaria de um pára-quedas.
Harry: Sim. E é muito difícil… Acho que dizer em voz alta parece muito trivial, mas dada a forma como o H2 foi vendido, acho bastante… nada desafiador porque isso faz meu cliente parecer… burro… mas é complicado explicar para eles… se você pensar em como o H1 funciona, não foi tão ruim assim. E se obtivermos respostas que se parecem com isso e”Oh sim, posso ver agora”. Eu tive que ensinar isso aos engenheiros de desempenho antes. Pessoas que fazem o que eu faço. Tive de ensinar aos engenheiros de desempenho que não nos importamos muito quando as solicitações são feitas, mas sim quando as respostas se tornam úteis.
Drew: Uma das razões pelas quais as coisas parecem progredir tão rapidamente, especialmente nos últimos cinco anos, é que o desempenho é um grande tópico para o Google. E quando o Google coloca peso em algo assim, ele ganha força. Porém, essencialmente, o desempenho é um aspecto da experiência do usuário, não é?
Harry: Oh, quero dizer… este é um podcast muito bom, eu estava pensando sobre isso meia hora atrás, garanto que estava pensando nisso meia hora atrás. Desempenho é acessibilidade aplicada. Você está garantindo ou aumentando as chances de alguém acessar seu conteúdo e acho que acessibilidade é sempre… Ah, são leitores de tela, certo? São pessoas sem visão. As decisões de construir um site em vez de um aplicativo… as decisões são o acesso a mais de um público. Então, sim, desempenho é acessibilidade aplicada, que é, portanto, a experiência do usuário. E essa experiência do usuário pode se resumir a”Alguém poderia experimentar seu site”ponto final. Ou poderia ser”Essa experiência foi deliciosa? Quando cliquei em um botão, ele respondeu em tempo hábil?”. Então, eu concordo 100% e acho que essa é uma grande razão pela qual o Google está colocando peso nisso, é porque afeta a experiência do usuário e se alguém vai confiar nos resultados de pesquisa, queremos tentar dar a essa pessoa um site que eles não vão odiar.
Drew: E é… tudo o que você pensa, todos os benefícios em que pensa, experiência do usuário, coisas como maior engajamento, é definitivamente verdade, não é? Não há nada que afaste o usuário de um site mais rapidamente do que uma experiência lenta. É tão frustrante, não é? Usando um site onde você sabe que talvez a navegação não seja tão clara e se você clicar em um link e pensar”É isso que eu quero? Não é?”E apenas o custo de fazer aquele clique, apenas esperar, e então você tem que clicar no botão voltar e depois esperar, e é só… você desiste.
Harry: Sim, e faz sentido. Se você for ao supermercado e perceber que está lotado de gente, você fará o mínimo. Você não vai gastar muito dinheiro lá, é como”Oh, eu só preciso de leite”, dentro e fora. Considerando que, se for uma experiência agradável, você tem”Oh, bem, enquanto estou aqui, verei se… Oh, sim, eles têm isso… Oh, vou cozinhar isso amanhã à noite”como queiras. Acho que ainda, três décadas na web, até mesmo as pessoas que constroem para a web lutam, porque é intangível. Eles lutam para realmente pensar que o que irritaria você em uma loja real iria irritá-lo online, e incomoda, e as estatísticas mostram que sim.
Drew: Acho que no início, estou pensando no final dos anos 90, mostrando minha idade aqui, quando estávamos construindo sites, pensávamos muito em performance, mas pensávamos em performance do ponto de vista de que as conexões que as pessoas estavam usando eram tão lentos. Estamos falando sobre dial-up, modems, através de linhas telefônicas, modems 28K, 56K, e houve uma tendência em um ponto com imagens de estilo que todas as outras linhas da imagem seriam apagadas com uma cor sólida para dar isso. Se você pode imaginar isso como olhar para a imagem através de uma veneziana. E fizemos isso porque ajudou na compressão. Porque a cada duas linhas o algoritmo de compressão poderia-
Harry: reduza em um ponteiro.
Drew: Sim. E então você reduziu significativamente o tamanho da sua imagem, embora ainda seja capaz de obter… E se tornou um elemento de design. Todo mundo estava fazendo isso. Acho que Jeffrey Zeldman foi um dos primeiros a usar essa abordagem. Mas o que estávamos pensando era principalmente em quão rápido poderíamos fazer as coisas acontecerem. Não para a experiência do usuário, porque não estávamos pensando sobre… Quer dizer, acho que era a experiência do usuário, porque não queríamos que as pessoas saíssem de nossos sites, essencialmente. Mas estávamos pensando em não otimizar as coisas para serem realmente rápidas, mas em evitar que elas sejam muito lentas, se isso fizer sentido.
Harry: Sim, sim.
Drew: E então, acho que à medida que velocidades como as linhas ADSL se tornaram mais predominantes, paramos de pensar nesses termos e passamos a simplesmente não pensar sobre isso. E agora estamos na situação em que estamos usando dispositivos móveis e eles têm conexões restritas e talvez CPUs mais lentas e estamos tendo que pensar sobre isso novamente, mas desta vez em termos de obter uma vantagem. Assim como o lado da experiência do usuário, pode trazer benefícios reais para os negócios em termos de custos e capacidade de lucrar. Não é?
Harry: Sim, tremendamente. Quero dizer, não tenho certeza de como formular. Não estou atirando no meu próprio pé aqui, mas uma coisa que eu tento e enfatizo para os clientes é que a velocidade do site vai lhe dar uma vantagem competitiva, mas é apenas uma coisa que pode lhe dar alguma vantagem competitiva. Se você tem um produto que ninguém quer comprar, não importa a velocidade do seu site. E da mesma forma, se alguém realmente quer o site mais rápido do mundo, você tem que deletar suas imagens, deletar seu CSS, deletar seu JavaScript, e então ver quantos produtos você conta, porque eu garanto que a velocidade do site não foi o fator. Mas estudos têm mostrado que há enormes benefícios em ser rápido, da ordem de milhões. Estou trabalhando com um cliente enquanto conversamos. Decidimos para eles que se pudessem renderizar uma determinada página um segundo mais rápido, ou melhor, seu maior conteúdo para pintura fosse um segundo mais rápido, vale 1,8 milhões por ano, o que é… esse é um número grande.
Drew: Isso quase pagaria sua taxa.
Harry: Ei! Sim, quase. Eu disse a eles:”Olha, depois de dois anos, tudo isso vai ser pago. Vocês vão empatar”. Eu gostaria. Mas sim, o aspecto voltado para o cliente… desculpe, o aspecto voltado para o cliente de se você tem um site E-Com, eles vão gastar mais dinheiro. Se você for um editor, eles lerão mais de um artigo ou verão mais minutos de conteúdo, ou o que quer que você faça que seja o KPI que você mede. Pode ser no site do Smashing, pode ser que eles não saltaram, eles realmente clicaram em mais alguns artigos porque tornamos isso muito fácil e rápido. E sites mais rápidos são mais baratos de operar. Se você definiu sua estratégia de cache, manterá as pessoas longe de seus servidores. Se você otimizar seus ativos, tudo o que tiver que vir de seu servidor terá muito menos peso. Muito mais barato de operar.
Harry: A questão é que há um custo para chegar lá. Acho que Scott Jehl provavelmente disse um dos mais… E eu ouvi dele primeiro, então vou presumir que ele veio com isso, mas o ditado é”É fácil fazer um site rápido, mas é difícil de fazer um site rápido”. E isso é tão sucinto. Porque o motivo pelo qual o desempenho da web pode ser empurrado para baixo na lista de coisas a fazer é porque você pode dizer a um cliente”Se eu tornar o seu site um segundo mais rápido, você ganhará 1,8 milhão a mais por ano”ou pode ser”Se você acabou de adicionar o Apple Pay ao seu checkout, vai ganhar cinco mil extras.”Portanto, não se trata apenas de desempenho da web e não é o fator decisivo, é parte de uma estratégia muito maior, especialmente para E-Com online. Mas a evidência é que eu medi em primeira mão com meus clientes de varejo, meus clientes E-Com. O caso para isso está bem aí, você está absolutamente certo. É uma vantagem competitiva, e você ganhará mais dinheiro.
Drew: Antigamente, novamente, estou voltando a um tempo passado, mas pessoas como Steve Souders foram algumas das primeiras pessoas a realmente começar a escrever e falar sobre desempenho na web. E pessoas como Steve estavam basicamente dizendo”Esqueça a infraestrutura de back-end, onde todos os ganhos a serem obtidos estão no navegador, no front-end, é onde tudo que ocorre com lentidão”. Esse ainda é o caso 15 anos depois?
Harry: Sim, sim. Ele refez o teste entre aquele tempo e agora, e a lacuna realmente aumentou, então é realmente mais caro durante o fio. Mas há um contra para isso, que é se você tiver um desempenho de back-end muito ruim, se você sair do portão lentamente, há muito que você pode recuperar no front end. Eu tenho um cliente no momento, seu tempo para o primeiro byte é de 1,5 segundos. Nunca podemos renderizar mais rápido do que 1,5 segundo, portanto, isso vai ser um limite. Ainda podemos recuperar o tempo no front-end, mas se você teve um momento muito, muito ruim para o primeiro byte, você tem lentidão no back-end, há um limite de quão mais rápido seus esforços de desempenho do front end podem chegar. Mas com certeza.
Harry: Isso está, no entanto, mudando porque… Bem, não, não está mudando, eu acho, está piorando. Estamos empurrando mais para o cliente. Costumava ser um caso de”Seu servidor é tão rápido quanto está, mas depois disso temos um monte de pontos de interrogação.”porque eu ouço isso o tempo todo”Todos os nossos usuários rodam em WiFi. Todos eles têm desktops porque trabalham em nosso escritório.”Bem, não, agora eles estão todos trabalhando em casa. Você não pode escolher. Então, é aí que todos os pontos de interrogação vêm, onde a lentidão acontece, onde você realmente não pode controlá-la. Depois disso, o fato de agora estarmos tendendo a colocar mais no cliente. Com isso, quero dizer, tempos de execução inteiros no cliente. Você moveu toda a lógica do seu aplicativo de um servidor de qualquer maneira, então o tempo para o primeiro byte deve ser mínimo. Deveria ser o caso de enviar alguns pacotes de um CDM para o meu… mas você deixou de ser capaz de especificar para seus próprios servidores e passou a esperar que alguém não tenha o Netflix rodando na mesma máquina em que está tentando visualizar seu site em.
Drew: é um ponto muito bom sobre a forma como criamos sites e acho que a prática recomendada tradicional sempre foi você deve tentar e atender a todos os tipos de navegadores, todos os tipos de velocidades de conexão, todos os tamanhos de tela, porque você não sabe o que o usuário está esperando. E, como você disse, você tem esses cenários em que as pessoas dizem”Oh não, sabemos que todos os nossos usuários estão em suas máquinas desktop fornecidas pelo trabalho, eles estão executando este navegador, é a versão mais recente, eles estão conectados à LAN”mas então as coisas acontecem. Um dos grandes benefícios de ter aplicativos da web é que podemos fazer coisas como distribuir nossa força de trabalho repentinamente para todas as suas casas e eles podem continuar trabalhando, mas isso só é verdade se a qualidade da engenharia for tal que alguém que está girando em sua máquina doméstica que pode ter o IE11 ou qualquer outro, se a qualidade do trabalho está lá, isso realmente significa que a web cumpre seu potencial de ser um meio verdadeiramente acessível.
Drew: como você disse, há uma tendência de colocar mais e mais coisas no navegador e, claro, se o navegador for lento, é aí que a lentidão acontece. Você deve se perguntar”Esta é uma boa tendência? Devemos fazer isso?”Eu tenho um site que eu particularmente penso, percebi que é quase 100% renderizado pelo servidor. Há muito pouco JavaScript e é extremamente rápido. Toda vez que vou lá, penso”Oh, isso é rápido, quem escreveu isso?”E então eu percebo”Oh sim, fui eu”.
Harry: Isso é porque você está no host local, não é à toa que parece rápido. É o seu site de desenvolvimento.
Drew: Então, meu trabalho diário, estamos construindo nosso aplicativo de página única e mudando as coisas do servidor porque o servidor é o gargalo nesse caso. Você pode apenas dizer que é mais eficiente estar no navegador? Ou mais desempenho para estar no servidor? É apenas um caso de medição e avaliação caso a caso?
Harry: Acho que você precisa estar muito, muito, muito ciente do seu contexto e… genuinamente acho que um erro é… narcisismo em que as pessoas pensam”Oh, meu blog merece ser renderizado no navegador de alguém. Meu blog com uma taxa de rejeição de 89% precisa de seu próprio tempo de execução no navegador, porque preciso que as navegações subsequentes sejam rápidas, só quero buscar um… basicamente uma comparação dos dados.”Ninguém está clicando em seu próximo artigo de qualquer maneira, companheiro, não force o tempo de execução pelo cano. Portanto, você precisa estar bem ciente do seu contexto.
Harry: E eu sei que… se Jeremy Keith está ouvindo isso, ele provavelmente vai lançar um golpe sobre mim, mas há, eu diria, uma diferença entre um site e um aplicativo da web e a definição disso é muito, muito obscuro. Mas se você tem um aplicativo pesado de leitura e gravação, então algo em que você está inserindo dados, manipulando dados, etc. Basicamente, meu site não é um aplicativo da web, é um site, é somente leitura, que eu colocaria firmemente no acampamento do site. Algo como meu software de contabilidade é um aplicativo da web, eu diria que é um aplicativo da web e estou preparado para sofrer um pouco de custo de inicialização, porque sei que estarei lá por 20 minutos, uma hora, o que for. Então você precisa de um pouco de contexto e, novamente, talvez o narcisismo seja um pouco severo, mas você precisa ter um verdadeiro”Precisamos tornar este jornal um aplicativo do lado do cliente?”Não, você não precisa. Não, você não. As pessoas têm bloqueador de anúncios, as pessoas não gostam de sites de jornais locais de qualquer maneira. Eles provavelmente nem vão ler o artigo e reclamar sobre ele no Facebook. Apenas não crie algo assim como um aplicativo renderizado pelo cliente, não é adequado.
Harry: Então, eu acho que definitivamente há um ponto em que mover mais para o cliente ajudaria, e é quando você tem menos sensibilidade para rotatividade. Então, qualquer tipo de comunicação, por exemplo, estou fazendo uma auditoria por um momento para um site que… Eu acho que é um site da E-Com, mas é 100% no cliente. Você desativa o JavaScript e não vê nada, apenas uma div id=”app”vazia. E-Com é… você é muito sensível a qualquer problema. Seu fluxo de checkout está sutilmente errado, estou indo para outro lugar. Está muito lento, estou indo para outro lugar. Você não tem o contexto em que alguém está disposto a se hospedar nesse aplicativo por um tempo.
Harry: Photoshop. Abro o Photoshop e fico muito feliz em saber que levará 45 segundos para a tela inicial, porque estarei lá por… basicamente 45 segundos valem os 45 minutos. E é tão difícil de definir, é por isso que eu realmente luto para convencer os clientes”Por favor, não faça isso”, porque eu não posso simplesmente dizer”Por quanto tempo você acha que seu usuário estará lá”. E você pode procurá-lo de… se sua taxa de rejeição for de 89%, não otimize para uma segunda exibição de página. Baixe essa taxa de rejeição primeiro. Acho que definitivamente há uma divisão, mas o que eu diria é que a maioria das pessoas cai no lado errado dessa linha. A maioria das pessoas coloca coisas no cliente que não deveriam estar lá. CNN, por exemplo, você não pode ler um único título no site da CNN até que seja totalmente inicializado um aplicativo JavaScript. A única coisa que o servidor renderiza é o cabeçalho e o rodapé, que é a única coisa com a qual as pessoas não se importam.
Harry: E eu sinto que é só… Não sei como chegamos a esse ponto. Nunca será a melhor opção. Você entrega uma página que é efetivamente inútil que então tem que dizer”Legal, vou buscar o que seria um aplicativo da web, mas vamos executá-lo no navegador, então vou pedir um título , então você pode começar a… oh, você se foi.”Isso realmente me irrita.
Harry: E não é culpa de ninguém, acho que é a infância desse tipo de ecossistema JavaScript, o hype em torno dele, e também, isso vai soar muito duro, mas… É basicamente uma implementação ingênua. Claro, o Facebook inventou o React e tudo o mais, funciona para eles. Nove em cada 10 vezes você não está trabalhando na escala do Facebook, 95 vezes em 100 você provavelmente não é o engenheiro mais inteligente do Facebook, e isso é muito, muito cruel e soa horrível de se dizer, mas você só consegue… Nenhuma dessas coisas é rápida por padrão. Você precisa de uma implementação muito elegante dessas coisas para torná-las corretas.
Harry: Eu estava tendo uma discussão com meu velho… ele era um engenheiro-chefe do time que eu estava 10 anos atrás na Sky. Eu estava conversando com ele outro dia sobre isso e ele teve que trabalhar muito para tornar um aplicativo de cliente renderizado rápido, ao passo que para tornar um aplicativo de servidor renderizado rápido, você não precisa fazer nada. Você só precisa não desacelerar novamente. E eu sinto que há muitos vidros coloridos rosa, ingenuidade, marketing… Eu pareço tão desolado, precisamos seguir em frente antes que eu realmente comece a perder pessoas aqui.
Drew: Você acha que temos a tendência, como indústria, de nos concentrar mais na experiência do desenvolvedor do que na experiência do usuário às vezes?
Harry: Não como um todo, mas acho que esse problema surge em um lugar que você esperava. Se você olhar para a disparidade… Não sei se você viu isso, mas vou presumir que sim, você parece ter muito controle sobre a disparidade entre os dados do arquivo HTTP sobre o que frameworks e bibliotecas JavaScript são usados livremente em comparação com a pesquisa de estado de JavaScript. Se você seguir a pesquisa de estado de JavaScript, dirá”Oh sim, 75% dos desenvolvedores estão usando React”, enquanto menos de 5% dos sites estão usando React. Então, eu sinto que, em massa, não acho que seja um problema, mas acho que nas áreas que você esperaria, grande lealdade a um framework, por exemplo, a experiência do desenvolvedor é… evangelizada provavelmente antes do usuário. Não acho que a experiência do desenvolvedor deva ser esquecida, quer dizer, tudo tem um custo de manutenção. Your car. There was a decision when it was designed that”Well, if we hide this key, that functionality, from a mechanic, it’s going to take that mechanic a lot longer to fix it, therefore we don’t do things like that”. So there does need to be a balance of ergonomics and usability, I think that is important. I think focusing primarily on developer experience is just baffling to me. Don’t optimize for you, optimize for your customer, your customer pays you it’s not the other way around.
Drew: So the online echo chamber isn’t exactly representative of reality when you see everybody saying”Oh you should be using this, you should be doing that”then that’s actually only a very small percentage of people.
Harry: Correct, and that’s a good thing, that’s reassuring. The echo chamber… it’s not healthy to have that kind of monoculture perhaps, if you want to call it that. But also, I feel like… and I’ve seen it in a lot of my own work, a lot of developers… As a consultant, I work with a lot of different companies. A lot of people are doing amazing work in WordPress. And WordPress powers 24% of the web. And I feel like it could be quite easy for a developer like that working in something like WordPress or PHP on the backend, custom code, whatever it is, to feel a bit like”Oh, I guess everyone’s using React and we aren’t”but actually, no. Everyone’s talking about React but you’re still going with the flow, you’re still with the majority. It’s quite reassuring to find the silent majority.
Drew: The trend towards static site generators and then hosting sites entirely on a CDN, sort of JAMstack approach, I guess when we’re talking about those sorts of publishing type sites, rather than software type sites, I guess that’s a really healthy trend, would you think?
Harry: I love that, absolutely. You remember when we used to call SSG”flap file”, right?
Drew: Yeah.
Harry: So, I built CSS Wizardry on Jekyll back when Jekyll was called a flap file website. But now we service our generator, huge, huge fan of that. There’s no disadvantage to it really, you pay maybe a slightly larger up front compute cost of pre-compiling the site but then your compute cost is… well, Cloudflare fronts it, right? It’s on a CDN so your application servers are largely shielded from that.
Harry: Anything interactive that does need doing can be done on the client or, if you want to get fancy, what one really nice approach, if you are feeling ambitious, is use Edge Side Includes so you can keep your shopping cart server rendered, but at the edge. You can do stuff like that. Tremendous performance benefits there. Not appropriate for a huge swathe of sites, but, like you say, if we’re thinking publishing… an E-Com site it wouldn’t work, you need realtime stock levels, you need… search that doesn’t just… I don’t know you just need far more functionality. But yeah, I think the Smashing site, great example, my site is an example, much smaller than Smashing but yeah, SSG, flap filers, I’m really fond of it.
Drew: Could it work going deeper into the JAMstack approach of shifting everything into the client and building an E-Commerce site? I think the Smashing E-Commerce site is essentially using JavaScript in the client and server APIs to do the actual functionality as service functions or what have you.
Harry: Yeah. I’ve got to admit, I haven’t done any stuff with serverless. But yeah, that hybrid approach works. Perhaps my E-Commerce example was a bit clunky because you could get a hybrid between statically rendering a lot of the stuff, because most things on an E-Com site don’t really change. You filter what you can do on the client. Search, a little more difficult, stock levels does need to go back to an API somewhere, but yeah you could do a hybrid for a definite, for an E-Com site.
Drew: Okay, so then it’s just down to monitoring all those performance metrics again, really caring about the network, about latency, about all these sorts of things, because you’re then leaning on the network a lot more to fetch all those individual bits of data. It hosts a new set of problems.
Harry: Yeah, I mean you kind of… I wouldn’t say”Robbing Peter to pay Paul”but you are going to have to keep an eye on other things elsewhere. I’ve not got fully to the bottom of it, before anyone tweets it at us, but a client recently moved to an E-Commerce client. I worked with them two years ago and that site was already pretty fast. It was built on… I can’t remember which E-Com platform, it was.net, hosted on IIS, server rendered, obviously, and it was really fast because of that. It was great and we just wanted to maintain, maybe find a couple of hundred milliseconds here and there, but really good. Half way through last year, they moved to client side React for key pages. PP… product details page, product listing page, and stuff just got marketable slower lower, much slower. To the point they got back in touch needing help again.
Harry: And one of the interesting things I spotted when they were putting a case for”We need to actually revert this”. I was thinking about all the…what’s slower, obviously it’s slower, how could doing more work ever be faster, blah blah blah. One of their own bullet points in the audit was: based on projections, their yearly hosting costs have gone up by a factor of 10 times. Because all of a sudden they’ve gone from having one application server and a database to having loads of different gateways, loads of different APIs, loads of different microservers they’re calling on. It increased the surface area of their application massively. And the basic reason for this, I’ll tell you exactly why this happened. The developer, it was a very small team, the developer who decided”I’m going to use React because it seems like fun”didn’t do any business analysis. It was never expected of them to actually put forward a case of how much is it going to cost the dude, how much is it going to return, what’s the maintenance cost of this?
Harry: And that’s a thing I come up against really frequently in my work and it’s never the developer’s fault. It’s usually because the business keeps financials away from the engineering team. If your engineers don’t know the cost or value of their work then they’re not informed to make those decisions so this guy was never to know that that was going to be the outcome. But yeah, interestingly, moving to a more microservice-y approach… And this is an outlier, and I’m not going to say that that 10 times figure is typical, it definitely seems atypical, but it’s true that there is at least one incident I’m aware of when moving to this approach, because they just had to use more providers. It 10x’ed their… there’s your 10 times engineer, increased hosting by 10 times.
Drew: I mean, it’s an important point, isn’t it? Before starting out down any particular road with architectural changes and things about doing your research and asking the right questions. If you were going to embark on some big changes, say you’ve got a really old website and you’re going to structure it and you want it to be really fast and you’re making all your technology choices, I mean it pays, doesn’t it, to talk to different people in the business to find out what they want to be doing. What sort of questions should you be asking other people in the business as a web developer or as a performance engineer? Who should you be talking to you and what should you be asking them?
Harry: I’ve got a really annoying answer to the”Who should you be talking to?”And the answer is everyone should be available to you. And it will depend on the kind of business, but you should be able to speak to marketing”Hey, look, we’re using this AB testing tool. How much does that cost as a year and how much do you think it nets as a year?”And that developer should feel comfortable. I’m not saying developers need to change their attitude, what I mean is the company should make the developers able to ask those kind of questions. How much does Optimizely cost as a year? Right, well that seems like a lot, does it make that much in return? Okay, whatever we can make a decision based on that. That’s who you should be talking to and then questions you should ask, it should be things like…
Harry: The amount of companies I work will, they won’t give their own developers to Google Analytics. How are you meant to build a website if you don’t know who you’re building it for? So the question should be… I work a lot with E-Com clients so every developer should things like”What is our average order value? What is our conversion rate? What is our revenue, how much do we make?”These things mean that you can at least understand that”Oh, people spend a lot of money on this website and I’m responsible for a big chunk of that and I need to take that responsibility.”
Harry: Beyond that, other things are hard to put into context, so for me, one of things that I, as a consultant, so this is very different to an engineer in the business, I need to know how sensitive you are to performance. So if a client gives me the average order value, monthly traffic, and their conversion rate, I can work out how much 100 milliseconds, 500 a second will save them a year, or return them, just based on those three numbers I can work out roughly”Well a second’s worth 1.8 mil”. It’s a lot harder for someone in the business to get all the back information because as a performance engineer it’s second nature to me. But if you can work that kind of stuff out, it unlocks a load of doors. Okay, well if a second’s work this much to us, I need to make sure that I never lose a second and if I can, gain a second back. And that will inform a lot of things going forward. A lot of these developers are kept quite siloed.”Oh well, you don’t need to know about business stuff, just shut up and type”.
Drew: I’ve heard you say, it is quite a nice soundbite, that nobody wants a faster website.
Harry: Yeah.
Drew: What do you mean by that?
Harry: Well it kind of comes back to, I think I’ve mentioned it already in the podcast, that if my clients truly wanted the world’s fastest website, they would allow me to go in and delete all their JavaScript, all their CSS, all their images. Give that customer a Times New Roman stack.
Harry: But fast for fast sake is… not chasing the wrong thing but you need to know what fast means to you, because, I see it all the time with clients. There’s a point at which you can stop. You might find that your customer’s only so sensitive to web perf that it might mean that getting a First Contentful Paint from four seconds to two seconds might give you a 10% increase in revenue, but getting from that two to a one, might only give you a 1% increase. It’s still twice as fast, but you get minimal gains. So what I need to do with my clients is work out”How sensitive are you? When can we take our foot off the gas?”And also, like I said, towards the top of the show… You need to have a product that people want to buy.
Harry: If people don’t want to buy your product, it doesn’t matter how quickly you show them it, it’ll just disgust them faster, I guess. Is your checkout flow really, really, really seamless on mobile, for example. So there’s a number of factors. For me, and my clients, it’ll be working out a sweet spot, to also working out”If getting from here to here is going to make you 1.8 mil a year, I can find you that second for a fraction of that cost.”If you want me to get you an additional second on top of that, it’s going to get a lot harder. So my cost to you will probably go up, and that won’t be an extra 1.8, because it’s not lineal, you don’t get 1.8 mil for every one second.
Harry: It will tail off at some point. And clients will get to a point where… they’ll still be making gains but it might be a case of your engineering effort doubles, meaning your returns halve, you can still be in the green, hopefully it doesn’t get more expensive and you’re losing money on performance, but there’s a point where you need to slow down. And that’s usually things that I help clients find out because otherwise they will just keep chasing speed, speed, speed and get a bit blinkered.
Drew: Yeah, it is sort of diminishing returns, isn’t it?
Harry: That’s what I was look for-
Drew: Yeah.
Harry:… diminishing returns, that’s exactly it. Yeah, exactly.
Drew: And in terms of knowing where to focus your effort… Say you’ve got the bulk of your users, 80% of your users are getting a response within two, three seconds, and then you’ve got 20% who may be in the long-tail that might end up with responses five, ten seconds. Is it better to focus on that 80% where the work’s really hard, or is it better to focus on the 20% that’s super slow, where the work might be easier, but it’s only 20%. How do you balance those sorts of things?
Harry: Drew, can you write all podcast questions for everyone else? Isso é tão bom. Well, a bit of a shout out to Tim Kadlec, he’s done great talks on this very topic and he calls it”The Long-Tail of Web Performance”so anyone listening who wants to look at that, Tim’s done a lot of good firsthand work there. The 80, 20, let’s just take those as good example figures, by the time you’re dealing with the 80th percentile, you’re definitely in the edge cases. All your crooks and web file data is based around 75th percentile. I think there’s a lot of value investing in that top 20th percentile, the worst 20%. Several reasons for this.
Harry: First thing I’m going to start with is one of the most beautiful, succinct soundbites I’ve ever heard. And the guy who told me it, I can guarantee, did not mean it to be this impactful. I was 15 years old and I was studying product design, GCSE. Finally, a project, it was a bar stool so it was a good sign of things to come. And we were talking about how you design furniture. And my teacher basically said… I don’t know if I should… I’m going to say his name, Mr. Brocklesby.
Harry: He commanded respect but he was one of the lads, we all really liked him. But he was massive in every dimension. Well over six foot tall, but just a big lad. Big, big, big, big man. And he said to us”If you were to design a doorway, would you design it for the average person?”And 15 year old brains are going”Well yeah, if everyone’s roughly 5’9 then yeah”He was like”Well, immediately, Harry can’t use that door.”You don’t design for the average person, you design for the extremities because you want it to be useful to the most people. If you designed a chair for the average person, Mr. Brocklesby wasn’t going to fit in it. So he taught me from a really, really age, design to your extremities.
Harry: And where that becomes really interesting in web perf is… If you imagine a ladder, and you pick up the ladder by the bot… Okay I’ve just realized my metaphor might… I’ll stick with it and you can laugh at me afterwards. Imagine a ladder and you lift the ladder up by the bottom rungs. And that’s your worst experiences. You pick the bottom rung in the ladder to lift it up. The whole ladder comes with it, like a rising tide floats all boats. The reason that metaphor doesn’t work is if you pick a ladder up by the top rung, it all lifts as well, it’s a ladder. And the metaphor doesn’t even work if I turn it into a rope ladder, because a rope ladder then, you lift the bottom rung and nothing happens but… my point is, if you can improve experience for your 90th percentile, it’s got to get that up for your 10th percentile, right?
Harry: And this is why I tell clients, they’ll say to me things like”Oh well most of our users are on 4G on iPhones”so like all right, okay, and we start testing 3G on Android, like”No, no, most of our users are iPhones”okay… that means your average user’s going to have a better experience but anyone who isn’t already in the 50th percentile just gets left further behind. So set the bar pretty high for yourself by setting expectations pretty low.
Harry: Sorry, I’ve got a really bad habit of giving really long answers to short questions. But it was a fantastic question and, to try and wrap up, 100% definitely I agree with you that you want to look at that long-tail, you want to look at that… your 80th percentile because if you take all the experiences on the site and look at the median, and you improve the median, that means you’ve made it even better for people who were already quite satisfied. 50% of people being effectively ignored is not the right approach. And yeah, it always comes back to Mr Brocklesby telling me”Don’t design for the average person because then Harry can’t use the door”. Oh, for anyone listening, I’m 193 centimeters, so I’m quite lanky, that’s what that is.
Drew: And all those arms and legs.
Harry: Yeah. Here’s another good one as well. My girlfriend recently discovered the accessibility settings in iOS… so everyone has their phone on silent, right? Nobody actually has a phone that actually rings, everyone’s got it on silent. She found that”Oh you know, you can set it so that when you get a message, the flash flashes. And if you tap the back of the phone twice, it’ll do a screenshot.”And these are accessibility settings, these are designed for that 95th percentile. Yet she’s like”Oh, this is really useful”.
Harry: Same with OXO Good Grips. OXO Good Grips, the kitchen utensils. I’ve got a load of them in the kitchen. They’re designed because the founder’s wife had arthritis and he wanted to make more comfortable utensils. He designed for the 99th percentile, most people don’t have arthritis. But by designing for the 99th percentile, inadvertently, everyone else is like”Oh my God, why can’t all potato peelers be this comfortable?”And I feel like it’s really, really… I like a feel-good or anecdote that I like to wheel out in these sort of scenarios. But yeah, if you optimize for them… Well, a rising tide floats all boats and that therefore optimizes the tail-end of people and you’re going to capture a lot of even happier customers above that.
Drew: Do you have the OXO Good Grips manual hand whisk?
Harry: I don’t. I don’t, is it good?
Drew: Look into it. It’s so good.
Harry: I do have the OXO Good Grips mandolin slicer which took the end of my finger off last week.
Drew: Yeah, I won’t get near one of those.
Harry: Yeah, it’s my own stupid fault.
Drew: Another example from my own experience with catering for that long-tail is that, in the project I’m working on at the moment, that long-tail is right at the end, you’ve got people with the slowest performance, but if it turns out if you look at who those customers are, they’re the most valuable customers to the business-
Harry: Okay.
Drew:… because they are the biggest organizations with the most amount of data.
Harry: Right.
Drew: And so they’re hitting bottlenecks because they have so much data to display on a page and those pages need to be refactored a little bit to help that use case. So they’re having the slowest experience and they’re, when it comes down to it, paying the most money and making so much more of a difference than all of the people having a really fast experience because they’re free users with a tiny amount of data and it all works nice and it is quick.
Harry: That’s a fascinating dimension, isn’t it? In fact, I had a similar… I had nowhere near the business impact as what you’ve just described, but I worked with a client a couple of years ago, and their CEO got in touch because their site was slow. Like, slow, slow, slow. Really nice guy as well, he’s just a really nice down to earth guy, but he’s mentored, like proper rich. And he’s got the latest iPhone, he can afford that. He’s a multimillionaire, he spends a lot of his time flying between Australia, where he is from, and Estonia, where he is now based.
Harry: And he’s flying first class, course he is. But it means most of his time on his nice, shiny iPhone 12 Pro Max whatever, whatever, is over airplane WiFi, which is terrible. And it was this really amazing juxtaposition where he owns the site and he uses it a lot, it’s a site that he uses. And he was pushing it… I mean easily their richest customer was their CEO. And he’s in this weirdly privileged position where he’s on a worse connection than Joe Public because he’s somewhere above Singapore on a Quantas flight getting champagne poured down his neck, and he’s struggling. And that was a really fascinating insight that… Oh yeah, because you’ve got your 95th percentile can basically can go in either direction.
Drew: Yeah, it’s when you start optimizing for using a site with a glass of champagne in one hand that you think”Maybe we’re starting to lose the way a bit.”
Harry: Yeah, exactly.
Drew: We talked a little bit about measurement of performance, and in my own experience with performance work it’s really essential to measure everyhtin.g A so you can identify where problems are but B so that when you actually start tackling something you can tell if you’re making a different and how much of a difference you’re making. How should we be going about measuring the performance of our sites? What tools can we use and where should we start?
Harry: Oh man, another great question. So there’s a range of answers depending on how much time, resources, inclination there is towards fixing site speed. So what I will try and do with client is… Certain off the shelf metrics are really good. Load time, do not care about that anymore. It’s very, very, very… I mean, it’s a good proxy if your load time’s 120 seconds I’m going to guess you don’t have a very fast website, but it’s too obscure and it’s not really customer facing. I actually think vitals are a really good step in the right direction because they do measure user experience but they’re based on technical input. Largest Contentful Paint is a really nice thing to visual but the technical stuff there is unblock your critical path, make sure hero images arrive quickly and make sure your web font strategy is decent. There’s a technical undercurrent to these metrics. Those are really good off the shelf.
Harry: However, if clients have got the time, it’s usually time, because you want to capture the data but you need time to actually capture the data. So what I try and do with clients is let’s go”Look, we can’t work together for the next three months because I’m fully booked. So, what we can do is really quickly set you up with a free trial of Speedcurve, set up some custom metrics”so that means that for a publisher client, a newspaper, I’d be measuring”How quickly was the headline of the article rendered? How quickly was the lead image for the article rendered?”For an E-Commerce client I want to measure, because obviously you’re measuring things like start render passively. As soon as you start using any performance monitoring software, you’re capturing your actual performance metrics for free. So your First Contentful Paint, Largest Contentful, etc. What I really want to capture is things that matter to them as a business.
Harry: So, working with an E-Com client at the moment where we are able to correlate… The faster your start render, what is the probability to an adding to cart. If you can show them a product sooner, they’re more likely to buy it. And this is a lot of effort to set up, this is kind of the stretch goal for clients who are really ambition, but anything that you really want to measure, because like I say, you don’t really want to measure what your Largest Contentful Paint is, you want to measure your revenue and was that influenced by Large Contentful Paint? So the stretch goal, ultimate thing, would be anything you would see as a KPI for that business. It could be, on newspapers, how far down the article did someone scroll? And does that correlate in any way to first input delay? Did people read more articles if CLS was lower? But then before we start doing custom, custom metrics, I honestly think web vitals is a really good place to start and it’s also been quite well normalized. It becomes a… I don’t know what the word is. Lowest common denominator I guess, where everyone in the industry now can discuss performance on this level playing field.
Harry: One problem I’ve got, and I actually need to set up a meeting with the vitals team, is I also really think Lighthouse is great, but CLS is 33% of web vitals. You’ve got LCP, FID, CLS. CLS is 33% of your vitals. Vitals is what normally goes in front of your marketing team, your analytics department, because it pops up in search console, it’s mentioned in context of search results pages, whereas vitals is concerned, you’ve got heavy weighting, 33%, a third of vitals is CLS, it’s only 5% of our Lighthouse score. So what you’re going to get is developers who build around Lighthouse, because it can be integrated into tooling, it’s a lab metric. Vitals is field data, it’s rum.
Harry: So you’ve got this massive disconnect where you’ve got your marketing team saying”CLS is really bad”and developers are thinking”Well it’s 5% of the Lighthouse score that DevTools is giving me, it’s 5% of the score that Lighthouse CLI gives us in CircleCI”or whatever you’re using, yet for the marketing team its 33% of what they care about. So the problem there is a bit of a disconnect because I do think Lighthouse is very valuable, but I don’t know how they reconcile that fairly massive difference where in vitals, CLS is 33% of your score… well, not score because you don’t really have one, and Lighthouse is only 5%, and it’s things like that that still need ironing out before we can make this discussion seamless.
Harry: But, again, long answer to a short question. Vitals is really good. LCP is a good user experience metric which can be boiled down to technical solutions, same with CLS. So I think that’s a really good jump off point. Beyond that, it’s custom metrics. What I try and get my clients to is a point where they don’t really care how fast their site is, they just care that they make more money from yesterday, and if it did is that because it was running fast? If it made less is that because it was running slower? I don’t want them to chase a mystical two second LCP, I want them to chase the optimal LCP. And if that actually turns out to be slower than what you think, then whatever, that’s fine.
Drew: So, for the web developer who’s just interested in… they’ve not got budget to spend on tools like Speedcurve and things, they can obviously run tools like Lighthouse just within their browser, to get some good measurement… Are things like Google Analytics useful for that level?
Harry: They are and they can be made more useful. Analytics, for many years now, has captured rudimentary performance information. And that is going to be DNS time, TCP and TLS, time to first byte, page download time, which is a proxy… well, whatever, just page download time and load time. So fairly clunky metrics. But it’s a good jump off point and normally every project I start with a client, if they don’t have New Relic or Speedcurve or whatever, I’ll just say”Well let me have a look at your analytics”because I can at least proxy the situation from there. And it’s never going to be anywhere near as good as something like Speedcurve or New Relic or Dynatrace or whatever. You can send custom metrics really, really, really easily off to analytics. If anyone listening wants to be able to send… my site for example. I’ve got metrics like”How quickly can you read the heading of one of my articles? At what point was the About page image rendered? At what point was the call to action that implores you to hire me? How soon is that rendered to screen?”Really trivial to capture this data and almost as trivial to send it to analytics. So if anyone wants to view source on my site, scroll down to the closing body tag and find the analytics snippet, you will see just how easy it is for me to capture custom data and send that off to analytics. And, in the analytics UI, you don’t need to do anything. Normally you’d have to set up custom reports and mine the data and make it presentable. These are a first class citizen in Google Analytics. So the moment you start capturing custom analytics, there’s a whole section of the dashboard dedicated to it. There’s no setup, no heavy lifting in GA itself, so it’s really trivial and, if clients are on a real budget or maybe I want to show them the power of custom monitoring, I don’t want to say”Oh yeah, I promise it’ll be really good, can I just have 24 grand for Speedcurve?”I can start by just saying”Look, this is rudimentary. Let’s see the possibilities here, now we can maybe convince you to upgrade to something like Speedcurve.”
Drew: I’ve often found that my gut instinct on how fast something should be, or what impact a change should have, can be wrong. I’ll make a change and think I’m making things faster and then I measure it and actually I’ve made things slower. Is that just me being rubbish at web perf?
Harry: Not at all. I’ve got a really pertinent example of this. Preload… a real quick intro for anyone who’s not heard of preload, loading certain assets on the web is inherently very slow and the two primary candidates here are background images in CSS and web fonts, because before you can download a background image, you have to download the HTML, which then downloads the CSS, and then the CSS says”Oh, this div on the homepage needs this background image.”So it’s inherently very slow because you’ve got that entire chunk of CSS time in between. With preload, you can put one line in HTML in the head tag that says”Hey, you don’t know it yet but, trust me, you’ll need this image really, really, really soon.”So you can put a preload in the HTML which preemptively fires off this download. By the time the CSS needs the background image, it’s like”Oh cool, we’ve already got it, that’s fast.”And this is toutered as this web perf Messiah… Here’s the thing, and I promise you, I tweeted this last week and I’ve been proved right twice since. People hear about preload, and the promise it gives, and also it’s very heavily pushed by Lighthouse, in theory, it makes your site faster. People get so married to the idea of preload that even when I can prove it isn’t working, they will not remove it again. Because”No, but Lighthouse said.”Now this is one of those things where the theory is sound. If you have to wait for your web font, versus downloading it earlier, you’re going to see stuff faster. The problem is, when you think of how the web actually works, any page you first hit, any brand new domain you hit, you’ve got a finite amount of bandwidth and the browser’s very smart spending that bandwidth correctly. It will look through your HTML really quickly and make a shopping list. Most important thing is CSS, then it’s this jQuery, then it’s this… and then next few things are these, these, and these less priority. As soon as you start loading your HTML with preloads, you’re telling the browser”No, no, no, this isn’t your shopping list anymore, buddy, this is mine. You need to go and get these.”That finite amount of bandwidth is still finite but it’s not spent across more assets, so everything gets marginally slower. And I’ve had to boo this twice in the past week, and still people are like”Yeah but no it’s because it’s downloading sooner.”No, it’s being requested sooner, but it’s stealing bandwidth from your CSS. You can literally see your web fonts are stealing bandwidth from your CSS. So it’s one of those things where you have to, have to, have to follow the numbers. I’ve done it before on a large scale client. If you’re listening to this, you’ve heard of this client, and I was quite insistent that”No, no, your head tags are in the wrong order because this is how it should be and you need to have them in this order because theoretically it clues in that…”Even in what I was to the client I knew that I was setting myself up for a fool. Because of how browsers work, it has to be faster. So I’m making the ploy, this change… to many millions of people, and it got slower. It got slower. And me sitting there, indignantly insisting”No but, browsers work like this”is useless because it’s not working. And we reverted it and I was like”Sorry! Still going to invoice you for that!”So it’s not you at all.
Drew: Follow these numbers.
Harry: Yeah, exactly.”I actually have to charge you more, because I spent time reverting it, took me longer.”But yeah, you’re absolutely right, it’s not you, it’s one of those things where… I have done it a bunch of times on a much smaller scale, where I’ll be like”Well this theoretically must work”and it doesn’t. You’ve just got to follow what happens in the real world. Which is why that monitoring is really important.
Drew: As the landscape changes and technology develops, Google rolls out new technologies that help us make things faster, is there a good way that we can keep up with the changes? Is there any resources that we should be looking at to keep our skills up to date when it comes to web perf?
Harry: To quickly address the whole”Google making”… I know it’s slightly tongue in cheek but I’m going to focus on this. I guess right towards the beginning, bet on the browser. Things like AMP, for example, they’re at best a after thought catch of a solution. There’s no replacement for building a fast site, and the moment you start using things like AMP, you have to hold on to those non-standard standards, the mercy of the AMP team changing their mind. I had a client spend a fortune licensing a font from an AMP allow-listed font provider, then at some point, AMP decided”Oh actually no, that font provided, we’re going to block list them now”So I had a client who’s invested heavily in AMP and this font provider and had to choose”Well, do we undo all the AMP work or do we just waste this very big number a year on the web font”blah, blah, blah. So I’d be very wary of any one… I’m a Google Developer expert but I don’t know of any gagging-order… I can be critical, and I would say… avoid things that are hailed as a one-size-fits-all solution, things like AMP.
Harry: And to dump on someone else for a second, Cloudflare has a thing called Rocket Loader, which is AMP-esque in its endeavor. It’s designed like”Oh just turn this thing on your CDN, it’ll make your site faster.”And actually it’s just a replacement for building your site properly in the first place. So… to address that aspect of it, try and remain as independent as possible, know how browsers work, which immediately means that Chrome monoculture, you’re back in Google’s lap, but know how browsers work, stick to some fundamental ideologies. When you’re building a site, look a the page. Whether that’s in Figma, or Sketch, or wherever it is, look at the design and say”Well, that is what a user wants to see first, so I’ll put nothing in the way of that. I won’t lazy load this main image because that’s daft, why would I do that?”So just think about”What would you want the user to be first?”On an E-Com site, it’s going to be that product image, probably nav at the same time, but reviews of the product, Q and A of the product, lazy load that. Tuck that behind JavaScript.
Harry: Certain fundamental ways of working that will serve you right no matter what technology you’re reading up on, which is”Prioritize what your customer prioritizes”. Doing more work on that’d be faster, so don’t put things in the way of that, but then more tactical things for people to be aware of, keep abreast of… and again, straight back to Google, but web.dev is proving to be a phenomenal resource for framework agnostic, stack agnostic insights… So if you want to learn about vitals, you want to learn about PWAs, so web.dev’s really great.
Harry: There’s actually very few performance-centric publications. Calibre’s email is, I think its fortnightly perf email is just phenomenal, it’s a really good digest. Keep an eye on the web platform in general, so there’s the Performance Working Group, they’ve got a load of stuff on GitHub proposals. Again, back to Google, but no one knows about this website and its phenomenal: chromestatus.com. It tells you exactly what Chrome’s working on, what the signals are from other browsers, so if you want to see what the work is on priority hints, you can go and get links to all the relevant bug trackers. Chrome Status shows you milestones for each…”This is coming out in MAT8, this was released in ’67″or whatever, that’s a really good thing for quite technical insights.
Harry: But I keep coming back to this thing, and I know I probably sound like”Old man shouts at Cloud”but stick to the basics, nearly every single pound or dollar, euro, I’ve ever earned, has been teaching clients that”You know the browser does this already, right”or”You know that this couldn’t possible be faster”and that sounds really righteous of me… I’ve never made a cent off of selling extra technology. Every bit of money I make is about removing, subtracting. If you find yourself adding things to make your site faster, you’re in the wrong direction.
Harry: Case in point, I’m not going to name… the big advertising/search engine/browser company at all, not going to name them, and I’m not going to name the JavaScript framework, but I’m currently in discussions with a very, very big, very popular JavaScript framework about removing something that’s actively harming, or optionally removing something that would harm the performance of a massive number of websites. And they were like”Oh, we’re going to loop in…”someone from this big company, because they did some research… and it’s like”We need an option to remove this thing because you can see here, and here, and here it’s making this site slower.”And their solution was to add more, like”Oh but if you do this as well, then you can sidestep that”and it’s like”No, no, adding more to make a site faster must be the wrong solution. Surely you can see that you’re heading in the wrong direction if it takes more code to end up with a faster site.”
Harry: Because it was fast to start with, and everything you add is what makes it slower. And the idea of adding more to make it faster, although… it might manifest itself in a faster website, it’s the wrong way about it. It’s a race to the bottom. Sorry, I’m getting really het up, you can tell I’ve not ranted for a while. So that’s the other thing, if you find yourself adding features to make a site faster, you’re probably heading in the wrong direction, it’s far more effective to make a faster by removing things than it is to add them.
Drew: You’ve put together a video course called”Everything I Have Done to Make CSS Wizardry Fast”.
Harry: Yeah!
Drew: It’s a bit different from traditional online video courses, isn’t it?
Harry: It is. I’ll be honest, it’s partly… I don’t want say laziness on my part, but I didn’t want to design a curriculum which had to be very rigid and take you from zero to hero because the time involved in doing that is enormous and time I didn’t know if I would have. So what I wanted to was have ready-to-go material, just screen cast myself talking through it so it doesn’t start off with”Here is a browser and here’s how it works”so you do need to be at least aware of web perf fundamentals, but it’s hacks and pro-tips and real life examples.
Harry: And because I didn’t need to do a full curriculum, I was able to slam the price way down. So it’s not a big 10 hour course that will take you from zero to hero, it’s nip in and out as you see fit. It’s basically just looking at my site which is an excellent playground for things that are unstable or… it’s very low risk for me to experiment there. So I’ve just done video series. It was a ton of fun to record. Just tearing down my own site and talking about”Well this is how this works and here’s how you could use it”.
Drew: I think it’s really great how it’s split up into solving different problems. If I want to find out more about optimizing images or whatever, I can think”Right, what does my mate Harry have to say about this?”, dip in to the video about images and off I go. It’s really accessible in that way, you don’t have to sit through hours and hours of stuff, you can just go to the bit you want and learn what you need to learn and then get out.
Harry: I think I tried to keep it more… The benefit of not doing a rigid curriculum is you don’t need to watch a certain video first, there’s no intro, it’s just”Go and look around and see what you find interesting”which meant that someone suffering with LTP issues they’re like”Oh well I’ve got to dive into this folder here”or if they’re suffering with CSS problems they can go dive into that folder. Obviously I have no stats, but I imagine there’s a high abandonment rate on courses, purely because you have to trudge through three hours of intro in case you do miss something, and it’s like”Oh, do you know what, I can’t keep doing this every day”and people might just abandon a lot of courses. So my thinking was just dive in, you don’t need to have seen the preceding three hours, you can just go and find whatever you want. And feedback’s been really, really… In fact, what I’ll do is, it doesn’t exist yet, but I’ll do it straight after the call, anybody who uses the discount code SMASHING15, they’ll get 15% off of it.
Drew: So it’s almost like you’ve performance optimized the course itself, because you can just go straight to the bit you want and you don’t have to do all the negotiation and-
Harry: Yeah, unintentional but I’ll take credit for that.
Drew: So, I’ve been learning all about web performance, what have you been learning about lately, Harry?
Harry: Technical stuff… not really. I’ve got a lot on my”to learn”list, so QUIC, H3 sort of stuff I would like to get a bit more working knowledge of that, but I wrote an E-Book during first lockdown in the UK so I learned how to make E-Books which was a ton of fun because they’re just HTML and CSS and I know my way around that so that was a ton of fun. I learnt very rudimentary video editing for the course, and what I liked about those is none of that’s conceptual work. Obviously, learning a programming language, you’ve got to wrestle concepts, whereas learning an E-Book was just workflows and… stuff I’ve never tinkered with before so it was interesting to learn but it didn’t require a change of career, so that was quite nice.
Harry: And then, non technical stuff… I ride a lot of bikes, I fall off a lot of bikes… and because I’ve not traveled at all since last March, nearly a year now, I’ve been doing a lot more cycling and focusing a lot more on… improving that. So I’ve been doing a load of research around power outputs and functional threshold powers, I’m doing a training program at the moment, so constantly, constantly exhausted legs but I’m learning a lot about physiology around cycling. I don’t know why because I’ve got no plans of doing anything with it other than keep riding. It’s been really fascinating. I feel like I’ve been very fortunate during lockdowns, plural, but I’ve managed to stay active. A lot of people will miss out on simple things like a daily commute to the office, a good chance to stretch legs. In the UK, as you’ll know, cycling has been very much championed, so I’ve been tinkering a lot more with learning more about riding bikes from a more physiological aspect which means… don’t know, just being a nerd about something else for a change.
Drew: Is there perhaps not all that much difference between performance optimization on the web and performance optimization in cycling, it’s all marginal gains, right?
Harry: Yeah, exactly. And the amount of graphs I’ve been looking at on the bike… I’ve got power data from the bike, I’ll go out on a ride and come back like”Oh if I had five more watts here but then saved 10 watts there, I could do this, this, and this the fastest ever”and… been a massive anorak about it. But yeah, you’re right. Do you know what, I think you’ve hit upon something really interest there. I think that kind of thing is a good sport/pastime for somebody who is a bit obsessive, who does like chasing numbers. There are things on, I mean you’ll know this but, Strava, you’ve got your KOMs. I bagged 19 of them last year which is, for me, a phenomenal amount. And it’s nearly all from obsessing over available data and looking at”This guy that I’m trying to beat, he was doing 700 watts at this point, if I could get up to 1000 and then tail off”and blah, blah, blah… it’s being obsessive. Nerdy. But you’re right, I guess it’s a similar kind of thing, isn’t it? If you could learn where you afford to tweak things from or squeeze last little drops out…
Drew: And you’ve still got limited bandwidth in both cases. You’ve got limited energy and you’ve got limited network connection.
Harry: Exactly, you can’t just magic some more bandwidth there.
Drew: If you, the listener, would like to hear more from Harry, you can find him on Twitter, where he’s @csswizardty, or go to his website at csswizardry.com where you’ll find some fascinating case studies of his work and find out how to hire him to help solve your performance problems. Harry’s E-Book, that he mentioned, and video course we’ll link up from the show notes. Thanks for joining us today, Harry, do you have any parting words?
Harry: I’m not one for soundbites and motivation quotes but I heard something really, really, really insightful recently. Everyone keeps saying”Oh well we’re all in the same boat”and we’re not. We’re all in the same storm and some people have got better boats than others. Some people are in little dinghies, some people have got mega yachts. Oh, is that a bit dreary to end on… don’t worry about Corona, you’ll be dead soon anyway!
Drew: Keep hold of your oars and you’ll be all right.
Harry: Yeah. I was on a call last night with some web colleagues and we were talking about this and missing each other a lot. The web is, by default, remote, that’s the whole point of the web. But… missing a lot of human connection so, chatting to you for this hour and a bit now has been wonderful, it’s been really nice. I don’t know what my parting words really are meant to be, I should have prepared something, but I just hope everyone’s well, hope everyone’s making what they can out of lockdown and people are keeping busy.
