Smashing Podcast Episódio 34 Com Harry Roberts: Qual é o estado do desempenho da Web?

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 de Masterclass de Performance na Web com o Smashing em maio de 2021. No momento da publicação, grandes descontos antecipados ainda estão disponíveis.

• Harry no Twitter
• Site de consultoria de Harry CSS Wizardry
• Curso em vídeo Tudo o que fiz para tornar o CSS Wizardry rápido, incluindo 15% de desconto
• E-book Perguntas para Consultores com 15% de desconto
• Guia Web.dev para Web Vitals
• O batedor de ovos OXO GoodGrips favorito de Drew

Atualização semanal

• Tendências de Web Design 2021: O relatório escrito por Suzanne Scacca
• Usando Grommet In React Applications escrito por Fortune Ikechi
• Como construir uma API Node.js para Ethereum Blockchain escrita por John Agbanusi
• Como melhoramos o desempenho do SmashingMag escrito por Vitaly Friedman
• Quando dizer não aos projetos freelance escritos 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 do que se trata quando se trata de desempenho na web, mas você sabia que ele tem 14 braços e sete pernas? Meus amigos Smashing, por favor, dêem as boas-vindas a Harry Roberts. Oi Harry, tudo bem?

Harry Roberts: Ei, estou arrasando, muito obrigado. Obviamente os 14 braços, sete pernas... ainda com seus problemas habituais. Impossível comprar calças.

Drew: E bicicletas.

Harry: Sim. Bem, eu tenho três bicicletas e meia.

Drew: Então eu queria falar com você hoje, não sobre bicicletas, infelizmente, embora isso seja divertido por si só. Eu queria falar com você sobre desempenho na web. É um assunto que eu pessoalmente sou muito apaixonado, mas é uma daquelas áreas em que eu me preocupo, quando eu tiro meus olhos da bola e me envolvo em algum outro tipo de trabalho e depois volto a fazer um pouco de trabalho de performance, Eu me preocupo que o conhecimento com o qual estou trabalhando fique desatualizado muito rápido... O desempenho da web está se movendo tão rápido hoje em dia quanto eu percebo?

Harry: Isso é... eu não estou apenas dizendo isso para ser legal com você, essa é uma boa pergunta porque eu tenho pensado muito sobre isso ultimamente e eu diria que há duas metades. Uma coisa que eu tentaria dizer aos clientes é que, na verdade, não se move tão rápido. Predominantemente porque, e este é o soundbite que sempre uso, você pode apostar no navegador. Os navegadores não têm permissão para mudar fundamentalmente 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 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, em geral, sempre serão melhores práticas no que diz respeito aos fundamentos.

Harry: Onde fica mais interessante é... O que estou vendo cada vez mais é que estamos nos colocando em curvas 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 em movimento, suponho. Quanto mais a paisagem ou a topografia da web muda, e a forma como ela é construída e a forma como trabalhamos, novos desafios nos colocam. Portanto, o advento de fazer muito mais trabalho no cliente apresenta problemas de desempenho diferentes do que estaríamos resolvendo há cinco anos, mas esses problemas de desempenho ainda pertencem aos componentes internos do navegador que, em geral, não mudaram em cinco anos. Então, depende muito… E eu diria que definitivamente há dois lados claros nisso… Eu encorajo meus clientes a se apoiarem no navegador, nos padrões, porque eles não podem simplesmente ser alterados, as balizas realmente não se movem . Mas, é claro, isso precisa se fundir com práticas de desenvolvimento mais modernas e, talvez, um pouco mais interessantes. Então você mantém seu… Bem, eu ia dizer “Um pé em ambos os campos”, mas com meus dois metros, 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 mudou em… digo “nos últimos anos”, isso provavelmente está voltando um pouco agora, mas é o HTTP em que tínhamos esse protocolo HTTP estabelecido para comunicação entre clientes e servidores, e isso mudou e depois temos H2 que é então todo binário e diferente. E isso mudou muito do... Foi por questões de desempenho, foi para tirar algumas das limitações existentes, mas isso foi uma mudança e a forma de otimizar para aquele protocolo mudou. Isso agora é estável? Ou vai mudar de novo, ou...

Harry: Então, uma coisa sobre a qual eu gostaria de aprender mais é a segunda metade da pergunta, a mudança novamente. Eu preciso olhar mais para QUIC e H3, mas é um pouco longe demais 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 o 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 voos agora. Portanto, em vez de seis solicitações despachadas e/ou seis em voo por vez, potencialmente ilimitadas, infinitas. Mas traz problemas realmente interessantes porque… é muito difícil 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 só vez, mas você não tem largura de banda suficiente para isso. Portanto, você não fica realmente mais rápido porque só pode gerenciar, talvez, uma fração disso de cada vez.

Harry: E também o que você tem que pensar é como os arquivos respondem. E esta é outra dica profissional que passo 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, elas podem ver 24. Despachar 24 solicitações não é tão útil. O que é útil é quando essas respostas são retornadas. E o que você notará é que você pode despachar 24 solicitações, então o lado esquerdo de sua cascata parece muito bom e íngreme, mas todos eles retornam de maneira bastante escalonada e sequencial porque você precisa limitar a quantidade de largura de banda para você não pode cumprir todas as respostas ao mesmo tempo.

Harry: Bem, a outra coisa é que se você preenchesse todas as respostas ao mesmo tempo, você estaria intercalando as respostas. Então você obtém os primeiros 10% de cada arquivo e os próximos 20%… 20% de um arquivo JavaScript é inútil. JavaScript não é utilizável até que 100% dele tenha chegado. Então, o que você verá é, na verdade, a maneira como uma cascata H2 se manifesta quando você olha para a resposta... Parece muito mais com H1 de qualquer maneira, é muito mais escalonado. Então, H2, acho que foi supervendido, ou talvez os engenheiros não tenham sido levados a acreditar que existem limites para a eficácia. Porque você verá pessoas fragmentando excessivamente seus ativos e elas 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 criou mais largura de banda por mágica.

Harry: E o outro problema é que cada solicitação tem uma latência constante. Então, digamos que você está 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 2400 milissegundos de latência e 24 vezes... em vez de 250 milissegundos de download, digamos que seu download seja de 25 milissegundos, na verdade, demora mais 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 o H2 é essa bala mágica. Eles vão estilhaçar… Oh! Eles não poderiam simplificar o processo de desenvolvimento, não precisamos fazer agrupamento ou concatenação etc., etc. E, no final das contas, isso acabará mais lento porque você conseguiu espalhar suas solicitações, que era a promessa, mas sua latência permanece constante, então você acaba de ter n vezes mais latência no navegador. Como eu disse, muito difícil, provavelmente inútil tentar explicar isso sem recursos visuais, mas é notável como o H2 se manifesta em comparação com o que as pessoas esperam que ele faça.

Drew: Ainda há benefícios nesse processo de fragmentação, ok, para obter o lote inteiro ainda leva a mesma quantidade de tempo, mas quando você receber 100% do primeiro 24º de volta, poderá começar a trabalhar nele e poderá comece a executá-lo antes do dia 24.

Harry: Ah, cara, outra ótima pergunta. Então, absolutamente, se as coisas correrem corretamente e isso 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 executar na ordem em que chegam. Assim, 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 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, então ficará mais rápido. E então você tem benefícios indiretos de sua estratégia de cache pode ser mais granular. Muito chato seria você atualizar o tamanho da fonte no seu widget selecionador de data. No mundo H1 você tem que cachear talvez 200 kilowatts do CSS de largura do seu site. Considerando que agora, você apenas armazena em cache o datepicker.css. Portanto, temos benefícios derivados como esse, que são definitivamente muito valiosos.

Drew: Eu acho que, no cenário em que você magicamente recebesse todos os seus pedidos de volta de uma vez, isso obviamente atrapalharia o cliente potencialmente, 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 sendo uma cascata onde todas as suas respostas retornam ao mesmo tempo, então você teria uma lacuna bastante grande entre o última resposta que chega e sua capacidade de execução. Então, idealmente, quando estamos falando de JavaScript, você gostaria que o navegador solicitasse todos eles na ordem de solicitação, basicamente na ordem em que você os definiu, o servidor os retornasse todos na ordem correta para que o navegador pudesse executar -los na ordem correta. Porque, como você disse, se todos eles retornarem ao mesmo tempo, você terá um JavaScript enorme para ser executado de uma só vez, mas ainda precisará ser agendado. Assim, você pode ter uma dúvida de até um segundo entre um arquivo chegar e se tornar útil. Então, na verdade, H1... Acho que, idealmente, o que você procura é agendamento de requisição H2, respostas no estilo H1, para que as coisas possam ser úteis à medida que chegam.

Drew: Então você está basicamente procurando por uma cascata de respostas que pareça que você pode descer por ela.

Harry: Sim, exatamente.

Drew: Mas você não precisaria de um pára-quedas.

Harry: Sim. E é muito difícil… acho que falar isso em voz alta soa muito trivial, mas dada a maneira como o H2 foi vendido, acho bastante… não desafiador porque isso faz meu cliente parecer… burro… mas é uma coisa para explicar para eles... se você pensar em como o H1 funciona, não foi tão ruim assim. E se recebermos respostas que se parecem com isso e “Ah, sim, posso ver agora”. Eu tive que ensinar engenheiros de desempenho isso antes. Pessoas que fazem o que eu faço. Eu tive que ensinar aos engenheiros de desempenho que não nos importamos muito quando as solicitações são feitas, nós realmente nos importamos quando as respostas se tornam úteis.

Drew: Uma das razões pelas quais as coisas parecem progredir rapidamente, especialmente nos últimos cinco anos, é que o desempenho é um grande tópico para o Google. E quando o Google coloca peso por trás de algo assim, ele ganha força. Essencialmente, porém, o desempenho é um aspecto da experiência do usuário, não é?

Harry: Ah, quero dizer… este é um podcast muito bom, eu estava pensando nisso meia hora atrás, eu prometo a você que eu estava pensando nisso meia hora atrás. Desempenho é acessibilidade aplicada. Você está garantindo ou aumentando as chances de alguém acessar o seu conteúdo e eu acho que acessibilidade é sempre apenas... Ah é leitores de tela, né? São pessoas sem visão. As decisões de construir um site em vez de um aplicativo… as decisões são acessar mais 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 eu cliquei em um botão, ele respondeu em tempo hábil?”. Então eu concordo 100% e acho que esse é o motivo pelo qual o Google está colocando peso nisso, é porque isso 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 que você 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 esperando, e então você tem que clicar no botão voltar e então esperar, e é só... você desiste.

Harry: Sim, e faz sentido. Se você for ao supermercado e vir que está absolutamente lotado de pessoas, você fará o mínimo. Você não vai gastar muito dinheiro lá, é tipo “Ah, eu só preciso de leite”, entrando e saindo. Considerando que se for uma experiência legal, você tem “Ah, bem, enquanto eu estiver aqui eu vou ver se… Ah, sim, eles têm isso… Ah, eu vou cozinhar isso amanhã à noite” ou qualquer outra coisa. Acho que ainda, três décadas na web, mesmo as pessoas que constroem para a web lutam, porque é intangível. Eles lutam para realmente pensar que o que o incomodaria em uma loja real o incomodaria online, e isso acontece, e as estatísticas mostram que sim.

Drew: Acho que nos primeiros dias, estou pensando no final dos anos 90, mostrando minha idade aqui, quando estávamos construindo sites, pensávamos muito em performance, mas pensamos em performance do ponto de vista de que as conexões que as pessoas usando eram tão lentos. Estamos falando de dial-up, modems, por linhas telefônicas, modems de 28K, 56K, e havia uma tendência em um ponto com imagens de estilo que todas as outras linhas da imagem ficariam em branco com uma cor sólida para dar isso… você pode imaginar como olhar através de uma veneziana para a imagem. E fizemos isso porque ajudou na compressão. Porque todas as outras linhas o algoritmo de compressão poderia-

Harry: Recolher em um ponteiro.

Drew: Sim. E assim você reduziu significativamente o tamanho da sua imagem enquanto ainda era capaz de obter... E isso se tornou um elemento de design. Todo mundo estava fazendo isso. Acho que talvez Jeffrey Zeldman tenha sido um dos primeiros pioneiros nessa abordagem. Mas o que estávamos pensando era principalmente a rapidez com que poderíamos fazer as coisas acontecerem. Não para a experiência do usuário, porque não estávamos pensando em... Quer dizer, acho que foi a experiência do usuário porque não queríamos que as pessoas deixassem nossos sites, essencialmente. Mas estávamos pensando em não otimizar as coisas para serem muito rápidas, mas tentar evitar que elas fossem muito lentas, se isso faz sentido.

Harry: Sim, sim.

Drew: E então, acho que à medida que as velocidades como as linhas ADSL se tornaram mais predominantes, paramos de pensar nesses termos e começamos a não pensar mais nisso. 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. Além do lado da experiência do usuário, ele pode ter benefícios comerciais reais em termos de custos e capacidade de obter lucro. Não é?

Harry: Sim, tremendamente. Quero dizer, não sei como dizer isso. Não estou dando um tiro no pé aqui, mas uma coisa que eu tento enfatizar 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 igualmente, 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 mostraram que há enormes benefícios em ser rápido, na ordem de milhões. Estou trabalhando com um cliente enquanto falamos. Nós descobrimos para eles que se eles 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, valeria 1,8 milhão por ano, o que é… um grande número.

Drew: Isso quase pagaria sua taxa.

Harry: Oi! Sim, quase. Eu disse a eles: “Olha, depois de dois anos, tudo isso será pago. Você estará empatando”. Eu desejo. Mas sim, o aspecto voltado para o cliente... desculpe, o aspecto voltado para o cliente, se você tem um site E-Com, eles vão gastar mais dinheiro. Se você é um editor, eles vão ler mais de um artigo ou vão ver mais minutos de conteúdo, ou o que quer que você faça, é o seu KPI que você mede. Pode ser no site Smashing, pode ser que eles não saltam, eles realmente clicam em mais alguns artigos porque tornamos isso muito fácil e rápido. E os sites mais rápidos são mais baratos de executar. Se você tiver sua estratégia de cache organizada, manterá as pessoas longe de seus servidores. Se você otimizar seus ativos, qualquer coisa que tenha que vir do seu servidor pesará muito menos. Muito mais barato de executar.

Harry: A questão é que há um custo para chegar lá. Eu acho que Scott Jehl provavelmente disse um dos mais… E eu ouvi isso dele primeiro, então eu vou assumir que ele veio com isso, mas o ditado é “É fácil fazer um site rápido, mas é difícil fazer um site velozes". E isso é tão sucinto. Porque a razão pela 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 seu site um segundo mais rápido, você ganhará 1,8 milhão extra por ano" ou pode ser “Se você acabou de adicionar o Apple Pay ao seu checkout, ganhará cinco milhões a mais.” Portanto, não se trata apenas de desempenho na web e não é o fator decisivo, é parte de uma estratégia muito maior, especialmente para o E-Com online. Mas a evidência é que eu medi isso em primeira mão com meus clientes de varejo, meus clientes de E-Com. O caso para isso está aí, você está absolutamente certo. É vantagem competitiva, vai fazer 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 o que é lento acontece”. Isso ainda acontece 15 anos depois?

Harry: Sim, sim. Ele reexecutou o teste na época e agora, e a diferença realmente aumentou, então é realmente mais caro pelo fio. Mas há um contra-ataque a isso, que é se você tiver um desempenho de back-end muito ruim, se você sair do portão lentamente, há muito o que você pode recuperar no front-end. Eu tenho um cliente no momento, seu tempo para o primeiro byte é de 1,5 segundos. Nós nunca podemos renderizar mais rápido que 1,5 segundo, então isso será um limite. Ainda podemos recuperar o tempo no front-end, mas se você tiver um tempo muito, muito ruim para o primeiro byte, tiver lentidão no back-end, há um limite de quanto mais rápido seus esforços de desempenho de front-end podem levá-lo. Mas absolutamente.

Harry: No entanto, isso está mudando porque... Bem, não, não está mudando, eu acho, está ficando pior. Estamos empurrando mais para o cliente. Costumava ser um caso de “Seu servidor é tão rápido quanto é, 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 computadores desktop porque todos 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 vêm todos os pontos de interrogação, onde as desacelerações acontecem, onde você não pode realmente controlá-las. Depois disso, o fato de que agora estamos 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 para fora de um servidor de qualquer maneira, então seu tempo para o primeiro byte deve ser muito, muito mínimo. Deve ser o caso de enviar alguns pacotes de um CDM para o meu… mas você deixou de poder especificar seus próprios servidores para esperar que alguém não tenha o Netflix rodando na mesma máquina em que está tentando visualizar seu site .

Drew: É um ponto muito bom sobre a maneira como projetamos sites e acho que a melhor prática tradicional sempre foi tentar atender a todos os tipos de navegadores, todos os tipos de velocidades de conexão, todos os tipos de tamanhos de tela, porque você não não sabe o que o usuário vai estar esperando. E, como você disse, você tem esses cenários em que as pessoas dizem "Ah, não, sabemos que todos os nossos usuários estão em sua máquina desktop de trabalho, estão executando este navegador, é a versão mais recente, estão conectados à LAN" mas depois 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 de volta para suas casas e eles podem continuar trabalhando, mas isso só vale se a qualidade da engenharia for tal que alguém que esteja girando até sua máquina doméstica que pode ter o IE11 ou qualquer outra coisa, se a qualidade do trabalho estiver lá, isso realmente significa que a web cumpre seu potencial de ser um meio verdadeiramente acessível.

Drew: Como você disse, há essa tendência de transferir mais e mais coisas para o navegador e, claro, se o navegador for lento, é aí que a lentidão acontece. Você tem que se perguntar “Esta é uma boa tendência? Deveríamos estar fazendo isso?” Eu tenho um site que eu particularmente penso, notei que é quase 100% renderizado pelo servidor. Há muito pouco JavaScript e é extremamente rápido. Toda vez que vou lá, penso: “Ah, isso é rápido, quem escreveu isso?” E então eu percebo “Ah sim, fui eu”.

Harry: Isso é porque você está no localhost, 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 tirando as coisas do servidor porque o servidor é o gargalo nesse caso. Você pode apenas dizer que é mais eficiente estar no navegador? Ou mais performático para estar no servidor? Trata-se apenas de medir e tomar caso a caso?

Harry: Eu acho que você precisa estar muito, muito, muito ciente do seu contexto e… genuinamente eu acho que um erro é… narcisismo onde 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 um diff dos dados.” Ninguém está clicando em seu próximo artigo de qualquer maneira, cara, não empurre um tempo de execução pelo cano. Então você precisa estar muito atento ao seu contexto.

Harry: E eu sei disso... se Jeremy Keith estiver ouvindo isso, ele provavelmente vai me dar um golpe, mas há, eu diria, uma diferença entre um site e um aplicativo da web e a definição disso é muito, muito turvo. Mas se você tem um aplicativo de leitura e gravação pesada, 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 web, eu diria que é um aplicativo web e estou preparado para sofrer um pouco de custo de tempo 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 duro, mas você precisa ter um verdadeiro “Precisamos fazer deste jornal um aplicativo do lado do cliente?” Não, você não. Não, você não. As pessoas têm bloqueador de anúncios, as pessoas não gostam de sites de jornais de qualquer maneira. Eles provavelmente nem vão ler o artigo e reclamar sobre isso no Facebook. Apenas não construa algo assim como um aplicativo renderizado pelo cliente, não é adequado.

Harry: Então eu acho que definitivamente há um ponto em que mudar mais para o cliente ajudaria, e é aí que você tem menos sensibilidade ao churn. Então, qualquer tipo de comunicação, por exemplo, estou fazendo uma auditoria por um momento para um site que... acho que é um site de E-Com, mas é 100% no cliente. Você desativa o JavaScript e não vê nada, apenas um div id = “app” vazio. E-Com é... você é muito sensível a qualquer problema. Seu fluxo de checkout está sutilmente errado, estou em outro lugar. É muito lento, estou em outro lugar. Você não tem o contexto em que alguém está disposto a usar esse aplicativo por um tempo.

Harry: Photoshop. Eu abro o Photoshop e estou muito feliz em saber que vai demorar 45 segundos de tela inicial porque eu vou estar lá por… basicamente os 45 segundos valem os 45 minutos. E é tão difícil de definir, e é 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 vai estar lá”. E você pode proximo-lo de… se sua taxa de rejeição de 89% não otimizar para uma segunda visualização de página. Baixe essa taxa de rejeição primeiro. Eu acho que definitivamente há uma divisão, mas o que eu diria é que a maioria das pessoas cai do 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 uma única manchete 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 isso é apenas... eu não sei como chegamos a esse ponto. Nunca será a melhor opção. Você entrega uma página que é efetivamente inútil que 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... ah, você se foi.” Isso realmente, 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 muita implementação ingênua. Claro, o Facebook inventou o React e o que quer que seja, funciona para eles. Nove em cada 10 vezes você não está trabalhando na escala do Facebook, 95 vezes em cada 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… essas coisas são rápidas por padrão. Você precisa de uma implementação muito, muito elegante dessas coisas para torná-las corretas.

Harry: Eu estava tendo essa discussão com o meu velho... ele era o engenheiro-chefe da equipe em que eu estava há 10 anos na Sky. Eu estava conversando com ele outro dia sobre isso e ele teve que trabalhar muito para tornar um aplicativo renderizado pelo cliente rápido, enquanto para tornar um aplicativo renderizado pelo servidor rápido, você não precisa fazer nada. Você só precisa não torná-lo lento novamente. E eu sinto que há um monte de óculos cor de rosa, ingenuidade, marketing... Eu pareço tão sombrio, precisamos seguir em frente antes que eu comece realmente a perder pessoas aqui.

Drew: Você acha que temos a tendência, como indústria, de focar 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ê esperaria. Se você olhar para a disparidade... Eu não sei se você já viu isso, mas eu vou presumir que você tem, você parece estar muito atento, a disparidade entre os dados do arquivo HTTP sobre quais frameworks e As bibliotecas JavaScript são usadas em estado selvagem versus o estado da pesquisa JavaScript, se você seguir o estado da pesquisa JavaScript, ele diria “Ah, 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, forte 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 menosprezada, quer dizer, tudo tem um custo de manutenção. Seu carro. Houve uma decisão quando foi projetado que “Bem, se escondermos essa chave, essa funcionalidade, de um mecânico, vai demorar muito mais para esse mecânico consertar, então não fazemos coisas assim”. Portanto, é preciso haver um equilíbrio entre ergonomia e usabilidade, acho que isso é importante. Acho que focar principalmente na experiência do desenvolvedor é simplesmente desconcertante para mim. Não otimize para você, otimize para o seu cliente, seu cliente te paga não é o contrário.

Drew: Então a câmara de eco online não é exatamente representativa da realidade quando você vê todo mundo dizendo “Ah, você deveria estar usando isso, você deveria estar fazendo aquilo”, então essa é na verdade apenas uma porcentagem muito pequena de pessoas.

Harry: Correto, e isso é bom, é reconfortante. A câmara de eco… não é saudável ter esse tipo de monocultura talvez, se você quiser chamar assim. Mas também, eu sinto que… e eu vi isso em muito do meu próprio trabalho, muitos desenvolvedores… Como consultor, eu trabalho com muitas empresas diferentes. Muitas pessoas estão fazendo um trabalho incrível no WordPress. E o WordPress alimenta 24% da web. E eu sinto que poderia ser muito fácil para um desenvolvedor como esse trabalhando em algo como WordPress ou PHP no backend, código personalizado, seja o que for, se sentir um pouco como “Ah, acho que todo mundo está usando React e não estamos ” mas, na verdade, não. Todo mundo está falando sobre React, mas você ainda está seguindo o fluxo, você ainda está com a maioria. É bastante reconfortante encontrar a maioria silenciosa.

Drew: A tendência para geradores de sites estáticos e, em seguida, hospedar sites inteiramente em um CDN, uma espécie de abordagem JAMstack, acho que quando estamos falando sobre esses tipos de sites de publicação, em vez de sites de tipo de software, acho que é uma tendência realmente saudável , você acha?

Harry: Eu amo isso, absolutamente. Você se lembra quando costumávamos chamar o SSG de “arquivo flap”, certo?

Drew: Sim.

Harry: Então, eu construí o CSS Wizardry no Jekyll quando o Jekyll era chamado de site de arquivos flap. 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: Sim.

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? This is so good. 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: Ele impunha respeito, mas ele era um dos rapazes, todos nós realmente gostávamos dele. Mas ele era enorme em todas as dimensões. Bem mais de um metro e oitenta de altura, mas apenas um rapaz grande. Grande, grande, grande, grande homem. E ele nos disse: “Se você fosse projetar uma porta, você a projetaria para uma pessoa comum?” E cérebros de 15 anos estão dizendo “Bem, sim, se todo mundo tem cerca de 1,70m, então sim” Ele estava tipo “Bem, imediatamente, Harry não pode usar aquela porta.” Você não projeta para a pessoa comum, você projeta para as extremidades porque você quer que seja útil para a maioria das pessoas. Se você projetasse uma cadeira para uma pessoa comum, o Sr. Brocklesby não caberia nela. Então ele me ensinou desde muito, muito tempo, desde o design até as extremidades.

Harry: E onde isso se torna realmente interessante no web perf é... Se você imaginar uma escada, e você pegar a escada pelo bot... Ok, acabei de perceber que minha metáfora pode... Eu vou ficar com ela e você pode rir eu depois. Imagine uma escada e você a levanta pelos degraus inferiores. E essas são suas piores experiências. Você pega o degrau inferior da escada para levantá-la. A escada inteira vem com ela, como uma maré cheia flutua todos os barcos. A razão pela qual a metáfora não funciona é que se você pegar uma escada no degrau mais alto, ela também levanta, é uma escada. E a metáfora nem funciona se eu a transformar em uma escada de corda, porque uma escada de corda então, você levanta o degrau inferior e nada acontece, mas… meu ponto é, se você pode melhorar a experiência para o seu percentil 90, tem que aumente isso para o seu percentil 10, certo?

Harry: E é por isso que eu digo aos clientes, eles vão me dizer coisas como "Ah, bem, a maioria dos nossos usuários está em 4G em iPhones", então tudo bem, ok, e começamos a testar 3G no Android, como "Não, não, a maioria dos nossos usuários são iPhones” ok… isso significa que seu usuário médio terá uma experiência melhor, mas qualquer um que ainda não esteja no percentil 50 fica para trás. Portanto, defina a fasquia bem alta para si mesmo, definindo expectativas bem baixas.

Harry: Desculpe, eu tenho o péssimo hábito de dar respostas muito longas para perguntas curtas. Mas foi uma pergunta fantástica e, para tentar encerrar, 100% definitivamente concordo com você que você quer olhar para aquela cauda longa, você quer olhar para isso… seu percentil 80 porque se você levar todas as experiências em frente o site e olhar para a mediana, e você melhora a mediana, isso significa que você melhorou ainda mais para as pessoas que já estavam bastante satisfeitas. 50% das pessoas sendo efetivamente ignoradas não é a abordagem correta. E sim, isso sempre volta para o Sr. Brocklesby me dizendo “Não projete para a pessoa comum porque então Harry não pode usar a porta”. Ah, para quem está ouvindo, eu tenho 193 centímetros, então sou bem magrinho, é isso.

Drew: E todos aqueles braços e pernas.

Harry: Sim. Aqui está outra boa também. Minha namorada descobriu recentemente as configurações de acessibilidade no iOS… então todo mundo está com o celular no silencioso, certo? Na verdade, ninguém tem um telefone que realmente toca, todo mundo está no silencioso. Ela descobriu que “Oh, você sabe, você pode configurá-lo para que, quando receber uma mensagem, o flash pisque. E se você tocar na parte de trás do telefone duas vezes, ele fará uma captura de tela.” E essas são configurações de acessibilidade, projetadas para esse percentil 95. No entanto, ela fica tipo “Oh, isso é realmente útil”.

Harry: O mesmo com OXO Good Grips. OXO Good Grips, os utensílios de cozinha. Eu tenho um monte deles na cozinha. Eles são projetados porque a esposa do fundador tinha artrite e ele queria fazer utensílios mais confortáveis. Ele projetou para o percentil 99, a maioria das pessoas não tem artrite. Mas ao projetar para o percentil 99, inadvertidamente, todo mundo fica tipo “Oh meu Deus, por que todos os descascadores de batata não podem ser tão confortáveis?” E eu sinto que é muito, muito… Eu gosto de uma boa sensação ou anedota que eu gosto de contar nesses tipos de cenários. Mas sim, se você otimizar para eles... Bem, uma maré alta flutua em todos os barcos e, portanto, otimiza a cauda das pessoas e você vai capturar muitos clientes ainda mais felizes acima disso.

Drew: Você tem o batedor manual OXO Good Grips?

Harry: Eu não. Eu não, é bom?

Drew: Olhe para ele. É tão bom.

Harry: Eu tenho o cortador de bandolim OXO Good Grips que arrancou a ponta do meu dedo semana passada.

Drew: Sim, não vou chegar perto de um desses.

Harry: Sim, é minha própria culpa estúpida.

Drew: Outro exemplo da minha própria experiência com a cauda longa é que, no projeto em que estou trabalhando no momento, essa cauda longa está bem no final, você tem pessoas com o desempenho mais lento, mas se você observar quem são esses clientes, eles são os clientes mais valiosos para a empresa.

Harry: Ok.

Drew: … porque são as maiores organizações com a maior quantidade de dados.

Harry: Certo.

Drew: E então eles estão atingindo gargalos porque têm muitos dados para exibir em uma página e essas páginas precisam ser um pouco refatoradas para ajudar nesse caso de uso. Então, eles estão tendo a experiência mais lenta e, quando se trata disso, pagam mais dinheiro e fazem muito mais diferença do que todas as pessoas que têm uma experiência muito rápida porque são usuários gratuitos com um pequena quantidade de dados e tudo funciona bem e é rápido.

Harry: Essa é uma dimensão fascinante, não é? Na verdade, eu tive um semelhante... não tive nem de longe o impacto comercial que você acabou de descrever, mas trabalhei com um cliente alguns anos atrás, e seu CEO entrou em contato porque o site estava lento. Tipo, devagar, devagar, devagar. Um cara muito legal também, ele é apenas um cara muito legal, mas ele é orientado, como um rico de verdade. E ele tem o iPhone mais recente, ele pode pagar por isso. Ele é um multimilionário, passa muito tempo voando entre a Austrália, de onde é, e a Estônia, onde agora mora.

Harry: E ele está voando na primeira classe, claro que está. Mas isso significa que ele passa a maior parte do tempo em seu belo e brilhante iPhone 12 Pro Max, seja o que for, seja por WiFi de avião, o que é terrível. E foi essa justaposição realmente incrível onde ele é dono do site e usa muito, é um site que ele usa. E ele estava forçando... quero dizer, facilmente, o cliente mais rico deles era o CEO. E ele está nessa posição estranhamente privilegiada onde ele está em uma conexão pior do que Joe Public porque ele está em algum lugar acima de Cingapura em um voo da Quantas recebendo champanhe no pescoço, e ele está lutando. E esse foi um insight realmente fascinante que… Ah sim, porque você tem seu percentil 95 pode basicamente ir em qualquer direção.

Drew: Sim, é quando você começa a otimizar para usar um site com uma taça de champanhe na mão que você pensa “Talvez estejamos começando a perder um pouco o caminho”.

Harry: Sim, exatamente.

Drew: Nós conversamos um pouco sobre medição de desempenho, e na minha própria experiência com trabalho de desempenho é realmente essencial medir tudo A para que você possa identificar onde estão os problemas, mas B para que quando você realmente começar a lidar com algo você possa dizer se você está fazendo uma diferença e quanta diferença você está fazendo. Como devemos proceder para medir o desempenho de nossos sites? Que ferramentas podemos usar e por onde devemos começar?

Harry: Oh cara, outra ótima pergunta. Portanto, há uma variedade de respostas, dependendo de quanto tempo, recursos e inclinação há para corrigir a velocidade do site. Então, o que vou tentar fazer com o cliente é... Algumas métricas prontas para uso são realmente boas. Tempo de carregamento, não se preocupe mais com isso. É muito, muito, muito… Quero dizer, é um bom proxy se o seu tempo de carregamento for de 120 segundos, acho que você não tem um site muito rápido, mas é muito obscuro e não é realmente voltado para o cliente. Na verdade, acho que os sinais vitais são um passo muito bom na direção certa porque medem a experiência do usuário, mas são baseados em informações técnicas. A maior pintura de conteúdo é uma coisa muito boa para o visual, mas o material técnico desbloqueia seu caminho crítico, certifique-se de que as imagens dos heróis cheguem rapidamente e certifique-se de que sua estratégia de fonte da web seja decente. Há uma tendência técnica para essas métricas. Esses são realmente bons fora da prateleira.

Harry: No entanto, se os clientes têm tempo, geralmente é tempo, porque você quer capturar os dados, mas precisa de tempo para realmente capturar os dados. Então, o que eu tento fazer com os clientes é: “Olha, não podemos trabalhar juntos pelos próximos três meses porque estou lotado. Então, o que podemos fazer é configurar rapidamente para você uma avaliação gratuita do Speedcurve, configurar algumas métricas personalizadas”, o que significa que, para um cliente editor, um jornal, eu estaria medindo “A rapidez com que a manchete do artigo renderizado? Com que rapidez a imagem principal do artigo foi renderizada?” Para um cliente de comércio eletrônico, quero medir, porque obviamente você está medindo coisas como começar a renderizar passivamente. Assim que você começar a usar qualquer software de monitoramento de desempenho, estará capturando suas métricas de desempenho reais gratuitamente. Então, sua primeira pintura de conteúdo, o maior conteúdo, etc. O que eu realmente quero capturar são coisas que importam para eles como um negócio.

Harry: Então, trabalhando com um cliente E-Com no momento em que somos capazes de correlacionar... Quanto mais rápido você começar a renderizar, qual é a probabilidade de adicionar ao carrinho. Se você puder mostrar a eles um produto mais cedo, é mais provável que eles o comprem. E isso é muito esforço para configurar, esse é um tipo de meta estendida para clientes que são realmente ambiciosos, mas qualquer coisa que você realmente queira medir, porque, como eu disse, você realmente não quer medir o que seu maior Contentful Paint é, você quer medir sua receita e isso foi influenciado pelo Large Contentful Paint? Portanto, o objetivo final, o objetivo final, seria qualquer coisa que você veria como um KPI para esse negócio. Pode ser, nos jornais, até que ponto alguém rolou o artigo? E isso se correlaciona de alguma forma com o atraso da primeira entrada? As pessoas leram mais artigos se o CLS fosse menor? Mas antes de começarmos a fazer métricas personalizadas, eu honestamente acho que o web vitals é um bom lugar para começar e também foi muito bem normalizado. Torna-se um… não sei qual é a palavra. O mínimo denominador comum, eu acho, onde todos na indústria agora podem discutir o desempenho neste campo de jogo nivelado.

Harry: Um problema que tenho, e na verdade preciso marcar uma reunião com a equipe de vitals, é que também acho o Lighthouse ótimo, mas o CLS é 33% dos vitals da web. Você tem LCP, FID, CLS. CLS é 33% de seus sinais vitais. Vitais é o que normalmente vai na frente de sua equipe de marketing, seu departamento de análise, porque aparece no console de pesquisa, é mencionado no contexto das páginas de resultados de pesquisa, enquanto os vitais estão preocupados, você tem peso pesado, 33%, um terço dos sinais vitais é CLS, é apenas 5% da nossa pontuação do Lighthouse. Então o que você vai conseguir são desenvolvedores que constroem em torno do Lighthouse, porque ele pode ser integrado em ferramentas, é uma métrica de laboratório. Vitals são dados de campo, é rum.

Harry: Então você tem essa grande desconexão onde você tem sua equipe de marketing dizendo “CLS é muito ruim” e os desenvolvedores estão pensando “Bem, é 5% da pontuação do Lighthouse que o DevTools está me dando, é 5% da pontuação que o Lighthouse CLI nos dá no CircleCI” ou o que você estiver usando, mas para a equipe de marketing é 33% do que eles se importam. Portanto, o problema é um pouco de desconexão porque acho que o Lighthouse é muito valioso, mas não sei como eles reconciliam essa diferença bastante grande, onde nos sinais vitais, o CLS é 33% da sua pontuação ... bem, não pontuação porque você realmente não tem um, e Lighthouse é apenas 5%, e são coisas assim que ainda precisam ser resolvidas antes que possamos tornar essa discussão perfeita.

Harry: Mas, novamente, uma resposta longa para uma pergunta curta. Vital é muito bom. O LCP é uma boa métrica de experiência do usuário que pode ser resumida a soluções técnicas, o mesmo com o CLS. Então eu acho que é um ponto de partida muito bom. Além disso, são métricas personalizadas. O que eu tento fazer com meus clientes é um ponto em que eles realmente não se importam com o quão rápido o site deles é, eles só se importam em ganhar mais dinheiro com ontem, e se isso aconteceu é porque estava rodando rápido? Se fez menos é porque estava rodando mais devagar? Eu não quero que eles persigam um LCP místico de dois segundos, eu quero que eles persigam o LCP ideal. E se isso realmente for mais lento do que você pensa, então tudo bem.

Drew: Então, para o desenvolvedor web que está apenas interessado em... eles não têm orçamento para gastar em ferramentas como Speedcurve e outras coisas, eles obviamente podem executar ferramentas como Lighthouse apenas dentro de seu navegador, para obter uma boa medição... São coisas como o Google Analytics útil para esse nível?

Harry: Eles são e podem ser mais úteis. A análise, por muitos anos, capturou informações de desempenho rudimentares. E isso vai ser tempo de DNS, TCP e TLS, tempo para o primeiro byte, tempo de download de página, que é um proxy... bem, tanto faz, apenas tempo de download de página e tempo de carregamento. Portanto, métricas bastante desajeitadas. Mas é um bom ponto de partida e normalmente todo projeto que eu começo com um cliente, se eles não tiverem New Relic ou Speedcurve ou qualquer outra coisa, eu direi apenas "Bem, deixe-me dar uma olhada em suas análises", porque eu posso menos proxy a situação a partir daí. E nunca será tão bom quanto algo como Speedcurve ou New Relic ou Dynatrace ou qualquer outra coisa. Você pode enviar métricas personalizadas muito, muito, muito facilmente para análises. Se alguém ouvindo quiser poder enviar… meu site por exemplo. Tenho métricas como “Com que rapidez você consegue ler o título de um dos meus artigos? Em que ponto a imagem da página Sobre foi renderizada? Em que ponto foi a chamada à ação que implora para você me contratar? Em quanto tempo isso é renderizado na tela?” Realmente trivial para capturar esses dados e quase tão trivial para enviá-los para análise. Então, se alguém quiser ver a fonte no meu site, role para baixo até a tag de fechamento do corpo e encontre o snippet de análise, você verá como é fácil para mim capturar dados personalizados e enviá-los para análise. E, na interface do usuário de análise, você não precisa fazer nada. Normalmente, você teria que configurar relatórios personalizados e extrair os dados e torná-los apresentáveis. Estes são um cidadão de primeira classe no Google Analytics. Assim, no momento em que você começa a capturar análises personalizadas, há uma seção inteira do painel dedicada a elas. Não há configuração, nem trabalho pesado no próprio GA, então é muito trivial e, se os clientes estiverem com um orçamento real ou talvez eu queira mostrar a eles o poder do monitoramento personalizado, não quero dizer “Ah, sim, prometo vai ser muito bom, posso ter apenas 24 mil pelo Speedcurve?” Posso começar dizendo apenas “Olha, isso é rudimentar. Vamos ver as possibilidades aqui, agora talvez possamos convencê-lo a atualizar para algo como o Speedcurve.”

Drew: Muitas vezes descobri que meu instinto de quão rápido algo deveria ser, ou que impacto uma mudança deveria ter, pode estar errado. Vou fazer uma mudança e acho que estou tornando as coisas mais rápidas e então meço e, na verdade, deixei as coisas mais lentas. Isso é só eu sendo lixo na web perf?

Harry: De jeito nenhum. Eu tenho um exemplo muito pertinente disso. Pré-carregamento… uma introdução bem rápida para quem não ouviu falar de pré-carregamento, carregar certos ativos na web é inerentemente muito lento e os dois principais candidatos aqui são imagens de fundo em CSS e fontes da web, porque antes de baixar uma imagem de fundo, você tem para baixar o HTML, que então baixa o CSS, e então o CSS diz “Ah, este div na página inicial precisa desta imagem de fundo”. Portanto, é inerentemente muito lento porque você tem todo esse tempo CSS no meio. Com o pré-carregamento, você pode colocar uma linha em HTML na tag head que diz “Ei, você ainda não sabe, mas acredite, você precisará dessa imagem muito, muito, muito em breve”. Então você pode colocar um pré-carregamento no HTML que aciona preventivamente este download. Quando o CSS precisa da imagem de fundo, é como “Ah, legal, já temos, é rápido”. E isso é anunciado como o Messias perf da web… Aqui está a coisa, e eu prometo a você, eu twittei isso na semana passada e já tive razão duas vezes desde então. As pessoas ouvem falar de pré-carregamento e da promessa que ele oferece, e também é fortemente impulsionado pelo Lighthouse, em teoria, torna seu site mais rápido. As pessoas se casam tanto com a ideia de pré-carregamento que, mesmo quando eu puder provar que não está funcionando, elas não vão removê-lo novamente. Porque “Não, mas o Lighthouse disse”. Agora, esta é uma daquelas coisas em que a teoria é sólida. Se você tiver que esperar pela sua fonte da web, em vez de baixá-la mais cedo, verá as coisas mais rapidamente. O problema é que, quando você pensa em como a web realmente funciona, qualquer página que você acessar pela primeira vez, qualquer novo domínio que você acessar, você tem uma quantidade finita de largura de banda e o navegador é muito inteligente gastando essa largura de banda corretamente. Ele examinará seu HTML muito rapidamente e fará uma lista de compras. A coisa mais importante é CSS, então é esse jQuery, então é isso... e as próximas coisas são essas, essas e essas menos prioritárias. Assim que você começar a carregar seu HTML com pré-carregamentos, você estará dizendo ao navegador “Não, não, não, esta não é mais sua lista de compras, amigo, esta é minha. Você precisa ir buscar isso.” Essa quantidade finita de largura de banda ainda é finita, mas não é gasta em mais ativos, então tudo fica um pouco mais lento. E eu tive que vaiar isso duas vezes na semana passada, e as pessoas ainda ficam tipo “Sim, mas não, é porque está baixando mais cedo”. Não, está sendo solicitado antes, mas está roubando largura de banda do seu CSS. Você pode literalmente ver que suas fontes da web estão roubando largura de banda do seu CSS. Então é uma daquelas coisas que você tem que, tem que, tem que seguir os números. Eu já fiz isso antes em um cliente de grande escala. Se você está ouvindo isso, você já ouviu falar desse cliente, e eu insisti bastante que “Não, não, suas etiquetas de cabeça estão na ordem errada porque é assim que deve ser e você precisa tê-las neste ordem porque teoricamente dá uma pista nisso...” Mesmo no que eu era para o cliente eu sabia que estava me preparando para um tolo. Por causa de como os navegadores funcionam, tem que ser mais rápido. Então, estou fazendo a manobra, essa mudança... para muitos milhões de pessoas, e ficou mais lento. Ficou mais lento. E eu sentado lá, indignado insistindo “Não, mas os navegadores funcionam assim” é inútil porque não está funcionando. E nós revertemos e eu fiquei tipo “Desculpe! Ainda vou cobrar por isso!” Então não é você mesmo.

Drew: Siga estes números.

Harry: Sim, exatamente. “Na verdade, tenho que te cobrar mais, porque gastei um tempo revertendo, demorei mais.” Mas sim, você está absolutamente certo, não é você, é uma daquelas coisas em que… eu fiz isso um monte de vezes em uma escala muito menor, onde eu ficaria tipo “Bem, isso teoricamente deve funcionar” e não não. Você só precisa seguir o que acontece no mundo real. É por isso que esse monitoramento é realmente importante.

Drew: À medida que o cenário muda e a tecnologia se desenvolve, o Google lança novas tecnologias que nos ajudam a tornar as coisas mais rápidas. Existe uma boa maneira de acompanhar as mudanças? Existe algum recurso que devemos procurar para manter nossas habilidades atualizadas quando se trata de desempenho na web?

Harry: Para abordar rapidamente toda a “criação do Google”… Eu sei que é um pouco irônico, mas vou focar nisso. Acho que logo no início, aposte no navegador. Coisas como AMP, por exemplo, são, na melhor das hipóteses, uma captura tardia de uma solução. Não há substituto para a construção de um site rápido e, no momento em que você começa a usar coisas como AMP, precisa manter esses padrões fora do padrão, a mercê da equipe de AMP mudando de ideia. Eu tive um cliente que gastou uma fortuna licenciando uma fonte de um provedor de fontes AMP permitido na lista, então, em algum momento, a AMP decidiu "Ah, na verdade, não, essa fonte fornecida, vamos bloqueá-las agora" Então eu tinha um cliente que investiu pesadamente em AMP e nesse provedor de fontes e teve que escolher “Bem, vamos desfazer todo o trabalho de AMP ou apenas desperdiçamos esse número muito grande por ano na fonte da web” blá, blá, blá. Então, eu ficaria muito cauteloso com qualquer um... Sou um especialista em desenvolvedores do Google, mas não conheço nenhuma ordem de engasgo... Posso ser crítico e diria... evite coisas que são aclamadas como tamanho único -fits-all solução, coisas como AMP.

Harry: E para despejar em outra pessoa por um segundo, Cloudflare tem uma coisa chamada Rocket Loader, que é AMP-esque em seu esforço. Ele foi projetado como "Ah, basta ativar essa coisa em seu CDN, isso tornará seu site mais rápido". E, na verdade, é apenas um substituto para construir seu site corretamente em primeiro lugar. Então… para abordar esse aspecto disso, tente permanecer o mais independente possível, saiba como funcionam os navegadores, o que imediatamente significa que a monocultura do Chrome, você está de volta ao colo do Google, mas saiba como os navegadores funcionam, atenha-se a algumas ideologias fundamentais. Quando você estiver construindo um site, procure na página. Seja no Figma, no Sketch ou onde quer que esteja, olhe para o design e diga “Bem, isso é o que um usuário quer ver primeiro, então não vou colocar nada no caminho. Eu não vou carregar esta imagem principal com preguiça porque isso é idiota, por que eu faria isso?” Então, pense em “O que você gostaria que o usuário fosse primeiro?” Em um site E-Com, vai ser a imagem do produto, provavelmente nav ao mesmo tempo, mas as análises do produto, perguntas e respostas do produto, carregam com preguiça. Coloque isso atrás do JavaScript.

Harry: Certas maneiras fundamentais de trabalhar que irão atendê-lo bem, não importa qual tecnologia você esteja lendo, que é “Priorize o que seu cliente prioriza”. Fazer mais trabalho nisso seria mais rápido, então não coloque as coisas no caminho, mas então mais coisas táticas para as pessoas estarem cientes, manter-se a par… e novamente, direto para o Google, mas web.dev está provando ser um recurso fenomenal para insights agnósticos de estrutura, agnósticos de pilha… Então, se você quer aprender sobre vitals, você quer aprender sobre PWAs, então o web.dev é realmente ótimo.

Harry: Na verdade, existem muito poucas publicações centradas em performance. O e-mail do Calibre é, eu acho que seu e-mail quinzenal é simplesmente fenomenal, é um resumo muito bom. Fique de olho na plataforma da web em geral, então há o Performance Working Group, eles têm um monte de coisas sobre as propostas do GitHub. Novamente, de volta ao Google, mas ninguém sabe sobre este site e seu fenomenal: chromestatus.com. Ele informa exatamente no que o Chrome está trabalhando, quais são os sinais de outros navegadores; portanto, se você quiser ver qual é o trabalho nas dicas de prioridade, poderá obter links para todos os rastreadores de bugs relevantes. O Status do Chrome mostra os marcos para cada… “Isso está saindo no MAT8, foi lançado em 67” ou o que quer que seja, isso é muito bom para insights bastante técnicos.

Harry: Mas eu continuo voltando a essa coisa, e eu sei que provavelmente soa como “Velho grita com Cloud”, mas me atenha ao básico, quase cada libra ou dólar, euro, que eu já ganhei, tem ensinado clientes que "Você sabe que o navegador já faz isso, certo" ou "Você sabe que isso não poderia ser mais rápido" e isso soa muito justo da minha parte... Eu nunca ganhei um centavo com a venda de tecnologia extra. Todo dinheiro que ganho é para remover, subtrair. Se você estiver adicionando coisas para tornar seu site mais rápido, você está na direção errada.

Harry: No caso em questão, não vou nomear… a grande empresa de publicidade/mecanismo de busca/navegador, não vou nomeá-los, e não vou nomear a estrutura JavaScript, mas estou atualmente em discussões com uma estrutura JavaScript muito, muito grande e muito popular sobre a remoção de algo que está prejudicando ativamente ou, opcionalmente, removendo algo que prejudicaria o desempenho de um grande número de sites. E eles ficaram tipo "Ah, vamos fazer um loop..." alguém dessa grande empresa, porque eles fizeram algumas pesquisas... e é como "Precisamos de uma opção para remover essa coisa porque você pode ver aqui, e aqui, e aqui está tornando este site mais lento.” E a solução deles foi adicionar mais, como “Ah, mas se você fizer isso também, então você pode contornar isso” e é como “Não, não, adicionar mais para tornar um site mais rápido deve ser a solução errada. Certamente você pode ver que está indo na direção errada se for preciso mais código para terminar com um site mais rápido.”

Harry: Porque foi rápido para começar, e tudo o que você adiciona é o que o torna mais lento. E a ideia de adicionar mais para torná-lo mais rápido, embora… possa se manifestar em um site mais rápido, é o caminho errado. É uma corrida para o fundo. Desculpe, estou ficando muito nervoso, você pode dizer que eu não discuto por um tempo. Então, essa é outra coisa, se você estiver adicionando recursos para tornar um site mais rápido, provavelmente está indo na direção errada, é muito mais eficaz tornar mais rápido removendo coisas do que adicioná-las.

Drew: Você montou um curso em vídeo chamado “Tudo o que fiz para tornar a magia do CSS mais rápida”.

Harry: Sim!

Drew: É um pouco diferente dos cursos tradicionais de vídeo online, não é?

Harry: É. Vou ser honesto, é em parte… Não quero dizer preguiça da minha parte, mas não queria desenhar um currículo que tivesse que ser muito rígido e levar você do zero ao herói porque o tempo envolvido em fazer isso é enorme e tempo que eu não sabia se teria. Então, o que eu queria era ter material pronto para uso, apenas o screencast eu falando sobre ele para que não começasse com "Aqui está um navegador e é assim que funciona", então você precisa estar pelo menos ciente de fundamentos de web perf, mas são hacks e dicas profissionais e exemplos da vida real.

Harry: E porque eu não precisava fazer um currículo completo, eu consegui baixar o preço. Portanto, não é um grande curso de 10 horas que o levará de zero a herói, é entrar e sair como achar melhor. É basicamente apenas olhar para o meu site, que é um excelente playground para coisas instáveis ​​ou… é muito baixo risco para mim experimentar lá. Então eu acabei de fazer uma série de vídeos. Foi muito divertido gravar. Apenas derrubando meu próprio site e falando sobre “Bem, é assim que isso funciona e aqui está como você pode usá-lo”.

Drew: Eu acho muito legal como é dividido em resolver problemas diferentes. Se eu quiser saber mais sobre como otimizar imagens ou qualquer outra coisa, posso pensar “Certo, o que meu amigo Harry tem a dizer sobre isso?”, mergulhar no vídeo sobre imagens e pronto. É realmente acessível dessa forma, você não tem que ficar sentado por horas e horas de coisas, você pode simplesmente ir para a parte que você quer e aprender o que você precisa aprender e depois sair.

Harry: Acho que tentei manter mais… O benefício de não fazer um currículo rígido é que você não precisa assistir a um determinado vídeo primeiro, não tem intro, é só “Vá e olhe ao redor e veja o que você acha interessante” o que significa que alguém que sofre com problemas de LTP fica tipo “Ah, bem, eu tenho que mergulhar nesta pasta aqui” ou se está sofrendo com problemas de CSS, pode mergulhar nessa pasta. Obviamente não tenho estatísticas, mas imagino que haja uma alta taxa de abandono nos cursos, puramente porque você tem que se arrastar por três horas de introdução caso perca alguma coisa, e é como “Ah, você sabe, não posso continue fazendo isso todos os dias” e as pessoas podem simplesmente abandonar muitos cursos. Então, meu pensamento foi apenas mergulhar, você não precisa ter visto as três horas anteriores, você pode simplesmente ir e encontrar o que quiser. E o feedback tem sido muito, muito… Na verdade, o que vou fazer é que ainda não existe, mas farei logo após a ligação, quem usar o código de desconto SMASHING15 terá 15% de desconto disso.

Drew: Então é quase como se você tivesse otimizado o desempenho do curso em si, porque você pode ir direto para a parte que você quer e você não precisa fazer toda a negociação e-

Harry: Sim, não intencional, mas vou levar o crédito por isso.

Drew: Então, eu tenho aprendido tudo sobre desempenho na web, o que você tem aprendido ultimamente, Harry?

Harry: Coisas técnicas... não realmente. Eu tenho muito na minha lista de “aprender”, então QUIC, H3 tipo de coisas que eu gostaria de obter um pouco mais de conhecimento prático disso, mas escrevi um e-book durante o primeiro bloqueio no Reino Unido, então aprendi como fazer E-Books que foi muito divertido porque eles são apenas HTML e CSS e eu sei como fazer isso, então foi muito divertido. Aprendi edição de vídeo muito rudimentar para o curso, e o que eu gostei neles não é nenhum trabalho conceitual. Obviamente, aprender uma linguagem de programação, você tem que lutar contra conceitos, enquanto aprender um E-Book era apenas fluxos de trabalho e… coisas que eu nunca havia mexido antes, então foi interessante aprender, mas não exigiu uma mudança de carreira , então isso foi bem legal.

Harry: E depois, coisas não técnicas… eu ando de bicicleta, caio de bicicleta… e porque eu não viajo desde março passado, quase um ano agora, eu tenho feito muito mais andar de bicicleta e focar muito mais em… melhorar isso. Então, eu tenho feito muita pesquisa sobre potências e potências de limiar funcional, estou fazendo um programa de treinamento no momento, tão constantemente, pernas constantemente exaustas, mas estou aprendendo muito sobre fisiologia em torno do ciclismo. Não sei por que, porque não tenho planos de fazer nada com isso além de continuar andando. Tem sido realmente fascinante. Sinto que tive muita sorte durante os bloqueios, no plural, mas consegui me manter ativo. Muitas pessoas vão perder coisas simples como um deslocamento diário para o escritório, uma boa chance de esticar as pernas. No Reino Unido, como você sabe, o ciclismo tem sido muito defendido, então eu tenho mexido muito mais em aprender mais sobre andar de bicicleta de um aspecto mais fisiológico, o que significa… não sei, apenas sendo um nerd sobre outra coisa para variar.

Drew: Talvez não haja muita diferença entre otimização de desempenho na web e otimização de desempenho no ciclismo, são todos ganhos marginais, certo?

Harry: Sim, exatamente. E a quantidade de gráficos que tenho visto na moto... Tenho dados de potência da moto, vou dar uma volta e volto como “Ah, se eu tivesse mais cinco watts aqui, mas economizasse 10 watts lá, eu poderia fazer isso, isso e isso o mais rápido de todos os tempos” e… fui um anoraque enorme sobre isso. Mas sim, você está certo. Quer saber, acho que você encontrou algo realmente interessante lá. Acho que esse tipo de coisa é um bom esporte/passatempo para alguém que é um pouco obsessivo, que gosta de perseguir números. Há coisas, quero dizer, você saberá disso, mas, Strava, você tem seus KOMs. Peguei 19 deles no ano passado, o que é, para mim, uma quantidade fenomenal. E é quase tudo por ficar obcecado com os dados disponíveis e olhar para “Esse cara que estou tentando vencer, ele estava fazendo 700 watts neste momento, se eu pudesse chegar a 1000 e depois diminuir” e blá, blá, blá … está sendo obsessivo. Nerd. Mas você está certo, eu acho que é um tipo semelhante de coisa, não é? 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: Sim. 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.