Melhorando o desempenho de uma loja online (estudo de caso)

Todo desenvolvedor front-end está perseguindo o mesmo santo graal de desempenho: pontuações verdes no Google Page Speed. Sinais tangíveis de trabalho bem feito são sempre apreciados. Como a caça ao Graal, porém, você tem que questionar se esta é realmente a resposta que você está procurando. O desempenho real para seus usuários e como o site “sente” quando você o está usando não deve ser descontado, mesmo que isso custe um ou dois pontos em Velocidade de página (caso contrário, todos teríamos apenas uma barra de pesquisa e texto).

Eu trabalho em uma pequena agência digital e minha equipe trabalha principalmente em grandes sites e lojas corporativas – a velocidade da página entra em discussão em algum momento, mas geralmente a resposta é que uma grande reescrita seria necessária para realmente alcançar qualquer coisa, um infeliz efeito colateral de tamanho e estrutura de projeto nas corporações.

Trabalhar com a jewellerybox em sua loja online foi uma mudança de ritmo bem-vinda para nós. O projeto consistiu em atualizar o software da loja para nosso próprio sistema de código aberto e refazer o front-end da loja do zero. O design foi feito por uma agência de design e UX que também tratou do protótipo HTML (baseado no Bootstrap 4). A partir daí, nós o incorporamos aos templates – e pela primeira vez, tivemos um cliente obcecado com o desempenho do site também.

Para o lançamento, focamos principalmente em lançar o novo design, mas assim que o relançamento do site foi lançado, começamos a focar nossa atenção em transformar as pontuações vermelhas e laranjas em verdes. Foi uma jornada de vários meses cheia de decisões difíceis, com muitas discussões sobre quais otimizações valiam a pena. Hoje, o site é muito mais rápido e tem uma classificação alta em várias vitrines e benchmarks. Neste artigo, vou destacar alguns dos trabalhos que fizemos e como conseguimos atingir nossa velocidade.

As lojas online são um pouco diferentes

Antes de entrarmos em detalhes, vamos falar um pouco sobre como as lojas online são diferentes de muitos outros sites (se você já sabe disso, nos encontraremos na próxima seção). Quando falamos de um site de comércio eletrônico, as principais páginas que você terá são:

• a página inicial (e páginas de “conteúdo”),
• categorias e páginas de pesquisa,
• páginas de detalhes do produto,
• o carrinho e o checkout (obviamente).

Para este artigo, focaremos nos três primeiros e nos ajustes de desempenho para eles. O checkout é a sua própria fera. Lá, você terá muito JavaScript extra e lógica de back-end para calcular os preços, além de várias chamadas de serviço para obter o provedor de remessa apropriado e estimativas de preço com base no país para o qual está sendo enviado.

Obviamente, além da validação dos campos do formulário, você precisará registrar os endereços de cobrança e envio. Acrescente a isso o drop-in do provedor de pagamento e você terá algumas páginas que ninguém vai querer tocar depois de terem sido devidamente testadas e funcionarem.

Qual é a primeira coisa que você pensa quando imagina uma loja online? Imagens — muitas e muitas imagens de produtos. Eles estão basicamente em todos os lugares e dominarão seu design. Além disso, você vai querer mostrar muitos produtos para que as pessoas comprem de você – então é um carrossel. Mas espere! As pessoas clicam nos produtos nele? Podemos descobrir colocando algum rastreamento no carrossel. Se o rastrearmos, podemos otimizá-lo! E, de repente, temos carrosséis de produtos externos com inteligência artificial em nossas páginas.

A questão é que um carrossel não será o último elemento penalizador de velocidade que você adiciona à página para mostrar mais produtos na esperança de atrair mais vendas. É claro que uma loja precisa de elementos interativos , seja o zoom da imagem do produto, alguns vídeos, uma contagem regressiva para o prazo de entrega de hoje ou uma janela de bate-papo para entrar em contato com o suporte ao cliente.

Tudo isso é muito importante quando você mede as conversões diretamente como receita . Além disso, a cada poucos meses, alguém da equipe identificará algumas novas funcionalidades interessantes que podem ser adicionadas e, assim, a complexidade e o JavaScript começam a se acumular, mesmo que você tenha começado com a melhor das intenções de mantê-lo enxuto.

E enquanto você geralmente pode armazenar em cache a página inteira de um artigo, o mesmo não acontece com muitas páginas e elementos da loja. Alguns são específicos do usuário, como o carrinho de compras no cabeçalho ou a lista de desejos, e devido à natureza pessoal dos dados, eles nunca devem ser armazenados em cache. Além disso, se você tem bens físicos, está lidando com estoque ao vivo: especialmente durante a corrida do Natal, você precisará que as informações sobre o estoque sejam precisas e atualizadas; portanto, você precisará de uma estratégia de cache mais complexa que permita armazenar em cache partes da página e combinar tudo novamente durante a renderização do lado do servidor.

Mas mesmo nas fases de planejamento, as armadilhas esperam. Em um projeto - e muitas vezes também na fase de protótipo - você trabalhará com nomes e descrições de produtos bem elaborados, todos quase uniformes em comprimento e imagens de produtos ideais. Eles parecem incríveis! O único problema? Na realidade, as informações do produto podem ser muito diferentes em tamanho, o que pode atrapalhar seu design. Com vários milhares de produtos, você não pode verificar cada um.

Portanto, ajuda se os designers ou as pessoas que estão fazendo o teste de protótipo com cordas muito curtas e muito longas para garantir que o design ainda se encaixe. Da mesma forma, fazer com que as informações apareçam duas vezes no HTML, uma para desktop e outra para celular, pode ser um grande problema para uma loja - especialmente se forem informações complexas, como detalhes do produto, carrinho de compras ou facetas dos filtros em uma categoria de produto página. É difícil mantê-los sincronizados – então, por favor, ajude um colega desenvolvedor e não faça isso.

Outra coisa que nunca deve ser uma reflexão tardia e deve ser incorporada a partir do estágio de protótipo é a acessibilidade. Várias ferramentas por aí podem ajudá-lo com algumas noções básicas, desde ter texto alternativo para todas as imagens e ícones com uma função, contraste de cores, até saber quais atributos ARIA usar onde (e quando não usar). Incorporar isso desde o início é muito mais fácil do que mais tarde e permite que todos aproveitem o site em que você está trabalhando.

Aqui vai uma dica: se você ainda não viu as pessoas usarem um leitor de tela ou navegarem com apenas um teclado, vídeos sobre isso podem ser facilmente encontrados no YouTube. Isso mudará sua compreensão desses tópicos.

De volta ao desempenho: Por que é tão importante melhorar o desempenho de uma loja novamente? A resposta óbvia é que você quer que as pessoas comprem de você . Existem várias maneiras de afetar isso, e a velocidade do seu site é grande. Estudos mostram que cada segundo adicional de tempo de carregamento tem um impacto significativo na taxa de conversão. Além disso, a velocidade da página é um fator de classificação para pesquisa e também para seus anúncios do Google. Assim, melhorar o desempenho terá um efeito tangível no resultado final.

Coisas práticas que fizemos

Alguns gargalos de desempenho são fáceis de identificar, mas uma melhoria completa é uma jornada mais longa, com muitas reviravoltas. Começamos com todas as coisas usuais, como verificar novamente o cache de recursos, ver o que poderíamos pré-buscar ou carregar de forma assíncrona, garantindo que estamos usando HTTP/2 e TLSv1.3. Muitos deles são abordados na visão geral útil do CSS-Tricks, e a Smashing Magazine oferece uma ótima lista de verificação em PDF.

Primeiras coisas primeiro: coisas carregadas em todas as páginas

Vamos falar sobre recursos, e não apenas CSS ou JavaScript (que abordaremos mais tarde). Começamos analisando coisas compartilhadas em várias telas, cada uma das quais pode ter um impacto. Somente depois disso nos concentramos nos tipos de página e nos problemas exclusivos deles. Alguns itens comuns foram os seguintes.

Carregando ícone

Como em tantos sites, usamos vários ícones em nosso design. O protótipo veio com alguns ícones personalizados que eram símbolos SVG incorporados. Eles foram armazenados como uma grande tag svg no cabeçalho HTML da página, com um símbolo para cada um dos ícones que foram usados ​​como um svg vinculado no corpo do HTML. Isso tem o bom efeito de torná-los disponíveis diretamente para o navegador quando o documento é carregado, mas obviamente o navegador não pode armazená-los em cache para todo o site.

Então decidimos movê-los para um arquivo SVG externo e pré-carregá-lo. Além disso, incluímos apenas os ícones que realmente usamos. Dessa forma, o arquivo pode ser armazenado em cache no servidor e no navegador, e nenhum SVG supérfluo precisará ser interpretado. Também suportamos o uso de Font Awesome na página (que carregamos via JavaScript), mas carregamos sob demanda (adicionando um pequeno script que verifica se há tags <i> e, em seguida, carregando o Font Awesome JavaScript para obter qualquer SVG ícones que encontra). Como mantemos nossos próprios ícones acima da dobra, podemos executar o script inteiro depois que o DOM for carregado.

Também usamos emoji em alguns lugares para ícones coloridos, algo que nenhum de nós realmente pensou, mas que nosso editor de conteúdo, Daena, pediu e que são uma ótima maneira de mostrar ícones sem nenhum efeito adverso no desempenho (a única ressalva é os diferentes designs em diferentes sistemas operacionais).

Carregamento de fonte

Como em tantos outros sites, usamos fontes da web para nossas necessidades de tipografia. O design exige duas fontes no corpo ( Josefin Sans em dois pesos), uma para títulos ( Nixie One ) e outra para texto com estilo especial ( Moonstone Regular ). Desde o início, nós os armazenamos localmente, com uma rede de entrega de conteúdo (CDN) para desempenho, mas depois de ler o maravilhoso artigo de Simon Hearne sobre como evitar mudanças de layout com carregamento de fonte, experimentamos remover a versão em negrito e usar a normal.

Em nossos testes, a diferença visual foi tão pequena que nenhum de nossos testadores foi capaz de dizer sem ver os dois ao mesmo tempo. Então, eliminamos o peso da fonte . Enquanto trabalhávamos neste artigo e preparávamos um auxílio visual para esta seção, nos deparamos com diferenças maiores nos navegadores baseados em Chromium no Mac e nos baseados em WebKit em telas de alta resolução (sim, complexidade!). Isso levou a outra rodada de discussões sobre o que devemos fazer.

Depois de algumas idas e vindas, optamos por manter o negrito falso e usar -webkit-text-stroke: 0.3px para ajudar esses navegadores específicos. A diferença de usar o peso real da fonte separada é pequena, mas não o suficiente para o nosso caso de uso, onde quase não usamos fonte em negrito, apenas um punhado de palavras por vez (desculpe, aficionados por fontes).

Além disso, vários produtos podem ser personalizados com gravuras . Essas gravuras podem ser feitas em várias fontes, e para algumas oferecemos uma prévia com a fonte aplicada. Para isso, baixamos a fonte sob demanda quando ela é escolhida no seletor de fontes suspenso. As visualizações na lista suspensa são imagens de amostra da aparência da fonte. Isso evita que tenhamos que baixar 10 ou mais arquivos de fonte adicionais.

Suporte legado

Um dia, CSS-Tricks me surpreendeu com um artigo sobre “How to Favicon in 2021”. Estávamos usando todos os tamanhos de ícones de toque do mundo – o artigo me fez reavaliar o que realmente precisamos e me mostrou que às vezes o que era verdade há alguns anos pode não ser mais necessário. Com base no artigo, limitamos nossas listas de favicon e ícones de toque às versões recomendadas.

Da mesma forma, também convertemos uma fonte que tínhamos apenas como uma versão WOFF para WOFF2 , que é muito menor, e decidimos fornecer WOFF2 para fontes (com WOFF restante como fallback). E limpamos as diretivas CSS que não são mais necessárias.

Carregamento preguiçoso e sob demanda

Várias métricas se concentram no tempo após o qual os usuários podem interagir com a página. A lógica dita que ter menos elementos para carregar significa que esse ponto será alcançado mais cedo. Para dar conta disso, é importante se perguntar quais partes da página são essenciais e quais o usuário só precisará mais tarde. Passamos por muito debate e tentativa e erro sobre isso.

A cascata de atividade da rede ajudou muito aqui, mas pensar nos fluxos de usuários também. Por exemplo, a imagem ampliada do produto pode ser carregada na primeira vez que um usuário interage com a imagem do produto, e as imagens no rodapé geralmente não aparecem acima da dobra e podem ser carregadas posteriormente. Se você estiver preocupado com lentidão, ainda poderá trabalhar com recursos de pré-busca.

Uma coisa que notamos muito cedo foi o grande impacto do cliente de chat. Foram mais de 500 KB de JavaScript sozinho e, embora infelizmente eu não tenha mais um gráfico, o carregamento também foi lento. Embora o JavaScript tenha sido configurado para carregar de forma assíncrona, o Google o incluiu nas medições de tempo para interação.

Não fomos capazes de rastrear completamente por que esse era o caso, mas entre isso e o tamanho dele, começamos a procurar alternativas, em vez de tentar consertar algo sobre o qual tínhamos controle limitado. Convencemos a jewellerybox a experimentar um widget de bate-papo de código aberto auto-hospedado , o que nos dá mais controle sobre como ele é carregado e que também é muito menor. Para melhorar ainda mais, carregamos inicialmente apenas o ícone do chat; o resto é carregado quando você clica para abri-lo.

O carrossel invisível de terceiros

A Jewellerybox queria experimentar um serviço de terceiros que usa IA para melhorar a personalização do produto nos carrosséis em várias páginas. Decidimos chamar sua API do back-end para isso, para que tivéssemos mais controle sobre o que é carregado (sem grandes dependências de JavaScript) e quanto tempo esperamos por uma resposta de seu serviço (com alguns fallbacks definidos). Devido a isso, os carrosséis são carregados da mesma forma que os não personalizados e também podem ser armazenados em cache com uma chave de cache exclusiva.

No entanto, há uma desvantagem: isso significa que a renderização inicial da página no lado do servidor pode ser mais lenta, a menos que seja armazenada em cache. Por esse motivo, estamos trabalhando em maneiras alternativas de injetar os resultados depois que a página for carregada e renderizar um espaço reservado primeiro.

Em segundo lugar: Otimizando JavaScript — Uma batalha difícil contra inimigos externos

O carrossel nos leva à segunda grande área em que focamos: JavaScript. Auditamos o JavaScript que tínhamos, e a maioria é de bibliotecas para tarefas diferentes, com muito pouco código personalizado. Otimizamos o código que nós mesmos escrevemos, mas obviamente não há muito o que você pode fazer se for apenas uma fração do seu código geral - os grandes ganhos estão nas bibliotecas.

Otimizar coisas em bibliotecas ou retirar peças que você não precisa é, com toda a probabilidade, uma tarefa tola. Você não sabe realmente por que algumas partes estão lá e nunca mais poderá atualizar a biblioteca sem muito trabalho manual. Com isso em mente, demos um passo para trás e analisamos quais bibliotecas usamos e para que precisamos delas , e investigamos para cada uma delas se existe uma alternativa menor ou mais rápida que atenda às nossas necessidades.

Em vários casos, houve! Por exemplo, decidimos substituir a biblioteca do slider Slick pelo GliderJS, que tem menos recursos, mas todos os que precisamos, além de ser mais rápido de carregar e ter suporte a CSS mais moderno! Além disso, retiramos muitas bibliotecas independentes do arquivo JavaScript principal e começamos a carregá-las sob demanda.

Como estamos usando o Bootstrap 4, ainda estamos incluindo jQuery para o projeto, mas estamos trabalhando para substituir tudo por implementações nativas. Para o Bootstrap em si, existe uma versão bootstrap.native no GitHub sem a dependência do jQuery que usamos agora. É menor em tamanho e funciona mais rápido. Além disso, geramos duas versões do nosso arquivo JavaScript principal: uma sem polyfills e outra com eles incluídos, e trocamos a versão com eles quando o navegador precisa deles, permitindo entregar uma versão principal simplificada para a maioria das pessoas. Testamos um serviço “polyfill-on-demand”, mas o desempenho não atendeu às nossas expectativas.

Uma última coisa sobre o tópico de jQuery. Inicialmente, nós o carregamos do nosso servidor. Vimos melhorias de desempenho em nosso sistema de teste ao carregá-lo através do Google CDN, mas o Page Speed ​​Insights reclamou do desempenho (eu me pergunto quem poderia resolver isso), então testamos hospedá-lo novamente, e na produção foi realmente mais rápido devido ao CDN que usamos.

Lição aprendida : um ambiente de teste não é um ambiente de produção, e as correções para um podem não ser válidas para o outro.

Terceiro: Imagens — Formatos, tamanhos e todo esse jazz

As imagens são uma grande parte do que faz uma loja online. Uma página geralmente terá várias dezenas de imagens, mesmo antes de contarmos as diferentes versões para diferentes dispositivos. O site jewellerybox existe há quase 10 anos, e muitos produtos estão disponíveis a maior parte desse tempo, então as imagens originais dos produtos não são uniformes em tamanho e estilo, e o número de fotos de produtos também pode variar.

Idealmente, gostaríamos de oferecer imagens responsivas para diferentes tamanhos de visualização e densidades de exibição em formatos modernos, mas qualquer alteração nos requisitos significaria muito trabalho de conversão a ser feito. Devido a isso, atualmente usamos um tamanho otimizado de imagens de produtos, mas não temos imagens responsivas para elas. Atualizar isso está no roteiro, mas não é trivial. As páginas de conteúdo oferecem mais flexibilidade, e nelas geramos e usamos tamanhos diferentes e incluímos formatos WebP e fallback.

Ter tantas imagens adiciona muito peso à carga inicial. Então, quando e como carregar imagens se tornou um grande tópico. O carregamento lento parece a solução, mas, se aplicado universalmente, pode desacelerar as imagens inicialmente visíveis, em vez de carregá-las diretamente (ou pelo menos parece assim para o usuário). Por esse motivo, optamos por uma combinação de carregamento direto dos primeiros e carregamento lento do restante, usando uma combinação de carregamento lento nativo e um script.

Para o logotipo do site, usamos um arquivo SVG, para o qual obtivemos uma versão inicial do cliente. O logotipo é uma fonte intrincada em que faltam partes das letras, pois estariam em uma impressão imperfeita feita à mão. Em tamanhos grandes, você precisaria mostrar os detalhes, mas no site nunca usamos acima de 150 por 30 pixels. O arquivo original tinha 192 KB de tamanho, não era enorme, mas também não era superpequeno. Decidimos brincar com o SVG e diminuir os detalhes nele, e acabamos com uma versão com 40 KB de tamanho descompactado. Não há diferença visual nos tamanhos de exibição que usamos.

Por último, mas definitivamente não menos importante: CSS

CSS crítico

O CSS figura muito no Relatório de experiência do usuário do Google Chrome (CrUX) e também aparece fortemente no relatório e nas recomendações do Google Page Speed ​​Insights. Uma das primeiras coisas que fizemos foi definir alguns CSS críticos, que carregamos diretamente no HTML para que estejam disponíveis para o navegador o mais rápido possível - essa é sua principal arma para combater as mudanças de layout de conteúdo (CLS). Optamos por uma combinação de extração automatizada do CSS crítico com base em uma página de protótipo e um mecanismo com o qual podemos definir os nomes das classes a serem extraídas (incluindo todas as sub-regras). Fazemos isso separadamente para estilos gerais, estilos de página de produto e estilos de categoria que são adicionados aos respectivos tipos de página.

Algo que aprendemos com isso e que causou alguns bugs no meio é que temos que ter cuidado para que a ordem do CSS não seja alterada por isso. Entre diferentes pessoas escrevendo o código, alguém adicionando uma substituição mais tarde no arquivo e uma ferramenta automática extraindo coisas, pode ficar confuso.

Dimensões explícitas em relação ao CLS

Para mim, o CLS é algo que o Google tirou do chapéu, e agora todos nós precisamos lidar com isso e envolver nossas cabeças coletivas em torno disso. Enquanto antes, podíamos simplesmente deixar os contêineres obterem seu tamanho dos elementos dentro deles, agora o carregamento desses elementos pode atrapalhar o tamanho da caixa. Com isso em mente, usamos a guia “Desempenho” nas Ferramentas do desenvolvedor e o gerador de GIF de deslocamento de layout super útil para ver quais elementos estão causando o CLS. A partir daí, analisamos não apenas os elementos em si, mas também seus pais e analisamos as propriedades CSS que teriam impacto no layout. Às vezes tivemos sorte – por exemplo, o logotipo só precisava de um tamanho explícito definido no celular para evitar uma mudança de layout – mas outras vezes, a luta era real.

Dica profissional: Às vezes, uma mudança é causada não pelo elemento aparente, mas pelo elemento que o precede. Para identificar possíveis culpados, concentre-se nas propriedades que mudam de tamanho e espaçamento. A pergunta básica a se fazer é: O que poderia fazer com que esse bloco se movesse?

Como há tantas imagens na página, fazer com que elas se comportem corretamente com o CLS também nos deu algum trabalho. Barry Pollard nos lembra justamente disso em seu artigo, “Setting Height and Width on Images Is Important Again”. Passamos muito tempo descobrindo os valores corretos de largura e altura (mais proporções) para nossas imagens em cada caso para adicioná-las ao HTML novamente. Como resultado, não há mais mudança de layout para as imagens porque o navegador obtém as informações antecipadamente.

O Caso da Misteriosa Pontuação CLS

Depois de remover muitos dos grandes problemas do CLS perto do topo da página, encontramos um obstáculo. Às vezes (nem sempre) ao analisar o Page Speed ​​ou o Lighthouse, obtivemos uma pontuação CLS superior a 0,3, mas nunca na guia “Desempenho”. O Layout Shift GIF Generator às vezes o mostrava, mas parecia que todo o contêiner da página estava se movendo .

Com a limitação de rede e CPU habilitada, finalmente vimos isso nas capturas de tela! O cabeçalho no celular estava crescendo 2 pixels de altura devido aos elementos dentro dele. Como o cabeçalho tem uma altura fixa no celular de qualquer maneira, optamos pela correção simples e adicionamos uma altura explícita a ele – caso encerrado. Mas nos custou muito nervos e mostra que o ferramental aqui ainda é muito impreciso.

Isso não está funcionando – vamos refazer!

Como todos sabemos, as pontuações em dispositivos móveis são muito mais duras para o Page Speed ​​do que para desktop, e uma área em que elas foram particularmente ruins para nós foi nas páginas de produtos. A pontuação do CLS estava no topo, e a página também teve problemas de desempenho (vários carrosséis, guias e elementos não armazenáveis ​​em cache farão isso). Para piorar a situação, o layout da página significava que algumas informações estavam sendo embaralhadas ou adicionadas duas vezes.

No desktop, temos basicamente duas colunas para o conteúdo:

• Coluna A : O carrossel de fotos do produto, às vezes seguido por citações de blogueiros, seguido por um layout com guias com informações do produto.
• Coluna B : O nome do produto, o preço, a descrição e o botão “adicionar ao carrinho”.
• Linha C : O carrossel de produtos similares.

No celular, no entanto, o carrossel de fotos do produto precisava vir primeiro, depois a coluna B, depois o layout com abas da coluna A. Devido a isso, certas informações foram duplicadas no HTML, sendo controladas por display: none , e o pedido estava sendo comutada com a propriedade flex: order . Definitivamente funciona, mas não é bom para as pontuações do CLS porque basicamente tudo precisa ser reordenado.

Decidi fazer um experimento simples no CodePen: eu poderia obter o mesmo layout básico de caixas no desktop e no celular repensando o HTML e usando display: grid em vez de flexbox, e isso me permitiria simplesmente reorganizar as áreas da grade conforme necessário? Para encurtar a história, funcionou e resolveu o CLS, e tem o benefício adicional de que o nome do produto agora vem muito mais cedo no HTML do que antes - uma vitória adicional de SEO!

Hackeando um carrossel para CLS

A palavra “carrossel” já surgiu várias vezes – e com razão. Não apenas alteramos a biblioteca do carrossel que usamos (e alteramos o comportamento de carregamento das imagens nela), também tivemos que lidar com isso para o CLS porque temos várias páginas nas quais o carrossel está acima da dobra e, portanto, pode ter um grande impacto nas pontuações de velocidade.

Começamos carregando o carrossel mais tarde para diminuir o tempo de interação , mas isso causou um atraso visível até que o JavaScript disparou e os slides passaram de estar abaixo um do outro para estar em uma linha. Tentamos várias maneiras de escrever o CSS para evitar que isso acontecesse e manter tudo em uma linha, incluindo ocultar todo o carrossel até que ele terminasse de carregar. Nada nos deu o tipo de solução que gostaríamos de ver ao visitar uma loja como usuário.

Desculpe por este discurso curto, mas realmente, carrosséis de produtos e categorias são a tempestade perfeita de elementos flexíveis em uma loja responsiva: as imagens podem não ter uma altura universal, os nomes dos produtos podem abranger várias linhas e você pode ou não ter rótulos. Basicamente, tudo se resume a isso: nenhuma altura fixa para a linha é possível, e você também não sabe a largura. Tempos divertidos.

No final, decidimos definir todos os slides (exceto o primeiro) para visibility: hidden até que o carrossel termine de carregar, momento em que adicionamos uma classe ao carrossel para alterar todos os slides para ficarem visíveis novamente . Isso resolve o problema de ocupar altura adicional no início.

Além disso, definimos inicialmente flex-shrink: 0 e flex-base: 340px para os slides em um flexbox sem encapsulamento. Isso faz com que eles fiquem em uma única linha e forneça uma largura inicial aproximada para os slides. Com esse quebra-cabeça resolvido - e sim, foi uma dor de cabeça tão grande quanto parece - adicionamos algumas correções para manter espaço para os pontos e setas caírem. Com isso, quase não há mais CLS para os carrosséis!

Retrospectiva é ²⁰ ⁄ ₂₀

No final, foram muitas pequenas mudanças ao longo de vários meses que melhoraram nossas pontuações, e ainda não terminamos. Trabalhamos principalmente com duas pessoas nas melhorias do front-end, enquanto o resto da equipe se concentrou em melhorar o back-end. Embora provavelmente tenha sido um pouco mais lento dessa maneira, garantiu que não houvesse sobreposição e as diferenças nas pontuações pudessem ser claramente atribuídas. Alguns recursos que ajudaram muito foram os ótimos artigos aqui na Smashing Magazine sobre as melhorias da própria revista.

Em algum momento, as coisas que você deveria tentar se tornam não-óbvias porque você acha que elas não deveriam fazer uma grande diferença, mas algum tempo depois você percebe que elas fazem. Mais do que isso, o que este projeto nos ensinou novamente é o quão importante é ter o desempenho e as métricas para isso desde o início , desde a concepção do design e codificação do protótipo até a implementação nos modelos. Pequenas coisas negligenciadas no início podem resultar em enormes montanhas que você terá que escalar mais tarde para desfazer.

Aqui estão alguns dos principais aspectos que aprendemos:

• Otimizar o JavaScript não é tão eficaz quanto carregá-lo sob demanda;
• Otimizar CSS parece ganhar mais pontos do que otimizar JavaScript;
• Escrever classes CSS com CLS e extração de CSS crítico em mente;
• As ferramentas para encontrar problemas de CLS ainda não são perfeitas. Pense fora da caixa e verifique várias ferramentas;
• Avalie cada serviço de terceiros que você integra para o tamanho do arquivo e o tempo de desempenho. Se possível, recue na integração de qualquer coisa que atrase tudo;
• Teste novamente sua página regularmente para alterações no CrUX (e especialmente no CLS);
• Verifique regularmente se todas as suas entradas de suporte legadas ainda são necessárias.

Ainda temos coisas em nossa lista de melhorias a fazer:

• Ainda temos muito CSS não utilizado no arquivo principal que pode ser removido;
• Gostaríamos de remover completamente o jQuery. Isso significa reescrever partes do nosso código, especialmente na área de checkout;
• Mais experimentos precisam ser conduzidos sobre como incluir os controles deslizantes externos;
• Nossas pontuações de pontos móveis poderiam ser melhores. Mais trabalho será necessário especialmente para dispositivos móveis;
• Imagens responsivas precisam ser adicionadas para todas as imagens de produtos;
• Verificaremos as páginas de conteúdo especificamente em busca de melhorias necessárias, especialmente em torno do CLS;
• Elementos que usam o plug-in de recolhimento do Bootstrap serão substituídos pela tag de details HTML nativa;
• O tamanho do DOM precisa ser reduzido;
• Integraremos um serviço de terceiros para resultados de pesquisa mais rápidos e melhores. Isso virá com uma grande dependência de JavaScript que precisaremos integrar;
• Trabalharemos para melhorar a acessibilidade analisando ferramentas automatizadas e executando alguns testes com leitores de tela e navegação por teclado.

Recursos adicionais

• “Dicas e atalhos de depuração do DevTools (Chrome, Firefox, Edge)”, Vitaly Friedman, Smashing Magazine
• “Algumas postagens de blog de desempenho que marquei e li ultimamente”, Chris Coyier, CSS-Tricks
• “Um guia detalhado para medir os principais elementos vitais da Web”, Barry Pollard, Smashing Magazine
• “Do CSS semântico ao Tailwind: refatorando a base de código da interface do usuário do Netlify”, Charlie Gerard e Leslie Cohn-Wein, Netlify
• “Ferramentas de auditoria CSS”, Iris Lješnjanin, Smashing Magazine
• “Coisas que você pode fazer com CSS hoje”, Andy Bell, Smashing Magazine
• “Como melhorar o desempenho do CSS”, Milica Mihajlija, Calibre
• “A lacuna de desigualdade de desempenho móvel, 2021”, Alex Russell
• “Otimizando ao máximo o carregamento de imagens para a Web em 2021”, Malte Ubl
• “O humilde elemento <img> e as principais características vitais da Web”, Addy Osmani, Smashing Magazine