Melhorias reais de desempenho em 2025

Clientes e usuários finais exigem interatividade instantânea agora mais do que nunca. O desempenho continua sendo a chave para seu sucesso, com empresas como o Google estabelecendo o desempenho como um fator de classificação importante nos resultados de pesquisa. A Akamai investiu pesado no desempenho do site. Usando nossos aprimoramentos e novos recursos, você pode obter o desempenho ideal da aplicação para clientes do mundo real.

Nesta publicação do blog, demonstraremos o impactos positivos que nossas melhorias causara nas métricas dos Core Web Vitals (CWV) de nossos clientes. Como um sinal de classificação de SEO, essencialmente em 2025, CWV é o padrão de fato para analisar o desempenho no mundo real. Usamos o CWV porque ele se concentra em usuários reais que usam aplicações modernas, independentemente da conexão, do local, do navegador ou do dispositivo que estão usando.

Em seguida, mostraremos como essas otimizações podem ser usadas para melhorar o desempenho de suas aplicações; isso inclui tanto as otimizações que introduzimos quanto os recursos e controles que agora podem ser adicionados à sua configuração da Akamai para ajudar a acelerar seus websites e aplicações.

Vamos começar.

As melhorias de desempenho que introduzimos no ano passado podem ter um impacto mensurável sobre os usuários reais. O Google confirmou isso por meio do Relatório de experiência do usuário do Chrome (CrUX). O CrUX é um conjunto de dados fornecido pelo Google, disponível publicamente, que oferece insights sobre como os usuários do mundo real experimentam os sites em termos de desempenho e tempo de carregamento.

Os dados são coletados de usuários reais que optaram por participar, permitindo que o Google rastreie e agregue métricas que refletem interações fundamentais do usuário, em vez de testes simulados ou baseados em laboratório.

Com os novos recursos da Akamai, observamos melhores resultados em indicadores-chave de desempenho (KPIs) centrados no usuário, como Maior exibição de conteúdo e Interação para a próxima exibição, bem como o mais técnico, mas ainda popular, tempo até o primeiro byte. Vejamos alguns exemplos de sites que viram uma evolução positiva desses sinais vitais da Web.

OBSERVAÇÃO: As figuras a seguir são capturas de tela da excelente ferramenta treo.sh, que permite visualizar dados históricos do CrUX para todos os sites no conjunto de dados.

A parte verde do gráfico na parte superior mostra a porcentagem de solicitações para as quais o LCP foi inferior a 2,5 segundos. Ele também mostra que 20% mais usuários têm uma experiência de usuário "boa" (verde) (a LCP foi inferior a 2,5 segundos) desde fevereiro, em comparação com os três meses anteriores.

O site foi muitas vezes registrado no território de "precisa de melhorias" (laranja) e estava potencialmente sendo penalizado nos resultados da pesquisa do Google, mas agora segue estavelmente no setor verde, que é um sinal forte de maior satisfação do usuário.

Um banco com foco em segurança percebeu melhorias impressionantes na interação com a próxima exibição (INP) (Figura 2). Eles não apenas fizeram suas próprias melhorias de implementação, mas também se beneficiaram de várias otimizações de JavaScript do Akamai Bot Manager que foram lançadas nos últimos meses. O banco percebeu que sua INP melhorou continuamente, com aumento de 55% a mais de 87% de usuários com uma experiência "boa" (INP < 200 milissegundos).

Embora não seja um CWV por si só, o tempo até o primeiro byte (TTFB) ainda é uma métrica importante a ser rastreada, pois muitas vezes se correlaciona bem com a LCP.

Um site de comércio eletrônico que já era rápido ficou ainda mais rápido nos últimos oito meses, pois a plataforma foi aprimorada (mais sobre isso na seção "O que melhoramos?"). A Figura 3 mostra um aumento contínuo, de acordo com os lançamentos da plataforma Akamai, na porcentagem de usuários com uma boa experiência TTFB nesse website.

Outro cliente, no setor de viagens, tinha historicamente números TTFB abaixo do padrão e não estava usando as otimizações de desempenho disponíveis da Akamai. Após implementar algumas práticas recomendadas pela equipe de desempenho da Akamai, esse cliente viu seu TTFB melhorar de 3 segundos para apenas 0,6 segundos em pouco mais de um mês (Figura 4).

Websites lentos ficaram mais rápidos, e websites que já eram rápidos ficaram ainda mais velozes com a Akamai. O site de comércio eletrônico exibido na Figura 5, que tem milhões de visitas mensais, recentemente cruzou a barreira mágica de 500 milissegundos ed LCP no P75, tem um impressionante 50 milissegundos de INP, e uma pontuação perfeita de 0,00 para a mudança cumulativa de layout (CLS).

Com a plataforma da Akamai, é possível criar sites maduros e altamente escaláveis que se beneficiam do melhor tempo de atividade com o melhor desempenho da categoria: sem compensações, sem comprometimentos; apenas excelência.

A essa altura da publicação, você deve ter esperado uma comparação do nosso desempenho em relação a outras CDNs (Redes de entrega de conteúdo). No entanto, especialmente em 2025, sentimos que é difícil fazer esse tipo de comparação em sã consciência.

Um dos principais motivos é que as métricas de CWV do usuário real dependem não apenas da velocidade da CDN, mas também da programação do front-end e do back-end de um site e de suas configurações específicas de CDN, que podem ser muito diferentes entre os sites. E, é claro, você pode criar sites rápidos e lentos em qualquer plataforma. 

A alternativa seria usar métricas de nível inferior, como TTFB. Aparentemente, essa é uma métrica que deve ser facilmente comparável entre as CDNs: Basta fazer o download de um único objeto em cada CDN,  medir a configuração da conexão e os tempos de solicitação… e pronto!

No entanto, embora seja de fato fácil coletar esses resultados, isso também está ficando cada vez mais sem sentido no mundo atual do HTTP/3 (e HTTP/2) e suas conexões de vários objetos. O (re)uso eficiente dessas conexões por meio de recursos avançados (como priorização de fluxo e compartilhamento de largura de banda) é muito mais importante para a experiência do usuário final (e métricas como LCP) do que a configuração inicial dessa conexão.

Além disso, muitas outras técnicas alteram a forma como o TTFB é medido na prática, incluindo: 103 dicas iniciais, dados iniciais (0-RTT), registros HTTPS DNS, API de regras de especulação, etc. (como discutiremos na seção "O que melhoramos?").

Como resultado, a medição do TTFB para dois objetos individuais em duas CDNs — uma com e outra sem um desses recursos ativados — já pode levar a resultados radicalmente diferentes que não dizem nada sobre o que a CDN é realmente capaz de fazer (como visto nas Figuras 1-5).

Para provar nosso argumento, aqui está um exemplo de um cliente que confiou demais em um benchmark que previa uma redução drástica em seu TTFB se ele se afastasse da Akamai (Figura 6). Ele mudou para uma solução diferente no início de agosto de 2024 e, infelizmente, seus dados CrUX públicos se deterioraram instantaneamente.

Nós nos concentramos nos dados de CWV dos clientes da Akamai para mostrar como impactamos os usuários reais, em vez de depender de técnicas de benchmarking herdadas. Não se deixe impressionar por grandes promessas; em vez disso, pesquise os CWVs de alguns dos maiores sites do mundo. É muito provável que eles estejam sendo executados na Akamai e tenham um desempenho excelente.

Agora que você já viu os resultados impressionantes que pode esperar dos aprimoramentos que fizemos nos últimos 12 meses, é hora de discutir com mais detalhes o que esses aprimoramentos implicam. Fizemos melhorias nas seguintes áreas:

• Plataforma
• Akamai Image & Video Manager
• Soluções de segurança
• Observabilidade e monitoramento de usuários reais

No centro da Akamai está nossa plataforma altamente distribuída que continua a aproximar mais cargas de trabalho dos usuários finais. Essa ampla plataforma nos permite implementar melhorias em uma escala sem precedentes.

Os últimos aprimoramentos destinados a fornecer seu conteúdo o mais rápido possível (para usuários reais) incluem:

• 103 dicas iniciais
• Dados iniciais (0-RTT)
• TLS 1.3 para a origem
• API de regras de especulação
• Otimizações de DNS
• Limite de anti-amplificação

Para recursos não armazenáveis em cache e perdas de cache, os servidores da edge da Akamai precisam entrar em contato com o servidor de origem. Isso causa ociosidade na conexão entre o navegador do cliente e nossos servidores da edge até que a resposta chegue.

Com as Dicas iniciais, os navegadores podem usar esse tempo de espera para pré-carregar os recursos que você especificar, como as principais folhas de estilo CSS, fontes da Web, logotipos ou JavaScript essencial, bem como pré-conectar-se a domínios ou subdomínios de terceiros. A Akamai oferece controle total sobre essas dicas para ajudar você a acelerar significativamente a experiência de renderização (LCP).

Os Dados iniciais são um novo recurso poderoso para HTTP/2 sobre TCP (protocolo de controle de transmissão) e HTTP/3 sobre QUIC. Eles permitem que os navegadores salvem um tempo de rota (RTT) de rede completo na maioria das conexões com a edge da Akamai.

Além disso, funciona bem em conjunto com outras opções, como as Dicas iniciais, para fornecer dados aos navegadores dos usuários o mais rapidamente possível. A Akamai permite uma configuração detalhada da compensação inerente de desempenho de segurança desse poderoso recurso.

Embora utilizemos conexões persistentes com seu potencial máximo, às vezes, a Akamai precisa estabelecer uma nova conexão TCP de nossa edge até sua origem. Adicionamos suporte para TLS 1.3, evitando o RTT adicional necessário com TLS 1.2. Para aproveitar esses benefícios de latência, configure suas origens corretamente.

Você pode aproveitar a nova API de regras de especulação para acelerar as aplicações de várias páginas com busca antecipada ou pré-configuração de navegações futuras. Essa API promete uma carga quase instantânea quando você pré-carrega páginas que seus usuários podem querer acessar em seguida.

A Akamai tem várias opções para entregar Regras de Especulação aos seus usuários finais, para que você possa impactar significativamente KPIs importantes, como LCP e CLS.

Nossa equipe de DNS lançou as primeiras fases de nossa arquitetura de DNS anycast de última geração. O programa, apelidado de Megacloud, está em andamento com 8 de nossos 22 clusters independentes já convertidos.

O Megacloud anuncia cada uma de nossas redes anycast de mais locais. A transição é complexa e deliberada para garantir que não haja comprometimentos de resiliência contra ataques. O resultado é uma pesquisa mais rápida de DNS em todos os percentis e regiões.

Normalmente, o handshake do QUIC leva apenas 1 RTT na rede para ser concluído. No entanto, como a Akamai adere estritamente a certos requisitos de segurança da indústria (refletindo as recomendações do RFC 9000), muitas conexões QUIC (e, portanto, HTTP/3) na prática exigiam dois RTTs em vez disso.

Para resolver esse problema, aumentamos o limite de anti-amplificação QUIC de três (de acordo com RFC) para sete e agora aproveitamos ao máximo o desempenho do HTTP/3 com apenas um RTT para estabelecer a conexão.

Imagens nítidas são uma parte essencial da web moderna. Para um bom LCP, as imagens devem ser carregadas rapidamente, e dois novos recursos do Image & Video Manager ajudarão você a alcançar isso.

• Subamostragem de croma SharpYUV: O AVIF e o HEIF, dois formatos de imagem modernos que fornecemos, agora usam a versão SharpYUV da subamostragem de croma, oferecendo melhor representação de cores e eficiência de compactação.

• Cache+: Esse novo add-on permite que você use o Akamai Cloud Wrapper para armazenar em cache os derivados do Image & Video Manager. Ele fornece um espaço de cache dedicado dentro do Cloud Wrapper, proporcionando maior controle sobre políticas de remoção e retenção de cache. Isso é ótimo para o desempenho, pois reduz o reprocessamento desnecessário e garante que as imagens permaneçam no cache por mais tempo, reduzindo perdas de cauda longa.

A maioria de nossos clientes não quer comprometer a segurança. Mas isso não significa que eles não se importam com o desempenho.

Nos últimos 12 meses, otimizamos a lógica da borda e do lado do cliente de nossas soluções de segurança (como o Akamai Bot Manager e o Akamai Content Protector). Para as bibliotecas do lado do cliente, as seguintes otimizações típicas de JavaScript foram feitas:

• Divisão de tarefas longas em partes menores
• Remoção de código não utilizado
• Mudança para bibliotecas mais rápidas
• Substituição de código antigo por outros mais rápidos

Essas otimizações resultaram em uma redução de bytes a serem enviados pelo cabo, reduzindo o congestionamento do caminho crítico e diminuindo o tempo de análise e compilação do JavaScript. Além disso, o impacto de nossas soluções de segurança nas métricas de tempo total de bloqueio (TBT) e interação com próxima exibição (INP) foi significativamente reduzido (por exemplo, consulte a Figura 2).

Agora que entendemos as métricas de desempenho e como várias otimizações as afetam, a próxima pergunta que podemos fazer é: "Como as medimos?" Alcançar visibilidade completa pode ser um desafio, especialmente ao usar vários provedores de nuvem, diferentes serviços e uma CDN.

Felizmente, há soluções disponíveis para lidar com esses problemas operacionais específicos, incluindo aqueles da solução de RUM (monitoramento do usuário real) Akamai mPulse e observabilidade de CDN.

• Painéis de atribuição de CWV: Saber que o seu site é lento é uma coisa, descobrir por que é lento é mais complexo. Vários novos widgets mPulse foram disponibilizados para resolver esse problema. Eles ajudam a atribuir problemas de CLS, identificar as causas de INP mais graves e mais frequentes e categorizar seus elementos de LCP.

• Novas métricas e temporizadores: Muitos temporizadores e dimensões interessantes foram adicionados ao mPulse. Eles removem as lacunas típicas de visibilidade, reduzem o ruído de RUM e facilitam a pesquisa dos dados mais relevantes. Isso inclui Frustrationindex, Page CDN Cache Status, quatro novos temporizadores de front-end e informações de BFCache.

• Sobrecarga de navegação não atribuída (UNO): Esse novo temporizador acumula todos os periodos de tempo "desconhecidos" e "extras" de uma navegação que não são contabilizados em outros temporizadores. Isso pode incluir atrasos no navegador, tempos de acesso ao disco, tempo oculto de restrições de origem cruzada, etc. Essa métrica ajuda a preencher as lacunas e a descobrir problemas que, de outra forma, poderiam ter passado despercebidos.

• O Akamai DataStream 2 foi alterado e agora inclui pontos de dados adicionais relevantes para os interessados em desempenho:

  • Suporte ao campo de dados iniciais de TLS e 103 dicas iniciais
  • Suporte do Akamai EdgeWorkers
  • Suporte ao destino TrafficPeak

• Trilhas de navegação: O novo recurso Breadcrumbs oferece visibilidade em tempo real das condições de erro e que afetam o desempenho do fornecimento de conteúdo.

• Common Media Client Data (CMCD): A coleta de dados de desempenho e métricas de uso de dispositivos que transmitem conteúdo, como vídeos, músicas ou jogos, é crucial para medir o desempenho de streaming. Identificar e mitigar:

  • Eventos de buffer
  • Tempos de inicialização lentos
  • Problemas de qualidade de reprodução
  • Taxas de erros
  • Taxa de transferência

Nos últimos 12 meses, introduzimos várias melhorias que agilizam as aplicações modernas, não apenas em papel, mas também para usuários reais. Os impactos dessas mudanças aparecem claramente nos dados do CrUX repetidamente e levam a resultados substancialmente aprimorados do CWV, melhorando tanto a experiência do usuário final quanto as cobiçadas classificações do mecanismo de busca do Google.

Embora estejamos satisfeitos com as muitas melhorias, sempre há oportunidades para nossas equipes eliminarem milissegundos adicionais, levando em conta a segurança, a escalabilidade e a disponibilidade.

Mais otimizações estão programadas para serem implementadas nas próximas semanas, meses e anos. Fique ligado enquanto esperamos um futuro ainda mais rápido.