Desempenho mobile-first para WordPress em 2026

O Google indexa e classifica a versão móvel de uma página, obtida pelo seu rastreador para smartphones. Um site WordPress que se limita a encolher o layout de desktop até à largura do telemóvel pode parecer bem numa verificação rápida e, mesmo assim, enviar uma página pesada e lenta ao dispositivo que decide como é indexado. Desempenho mobile-first significa construir cada página primeiro para um telemóvel numa rede limitada e só depois acrescentar peso para ecrãs maiores, apenas onde esse peso se justifica.

Saiba mais sobre a otimização da velocidade do WordPress na WPPoland.

Este guia explica o que a indexação mobile-first do Google exige, os limiares das Core Web Vitals para mobile, como se mede a velocidade móvel em laboratório e no terreno, e as funcionalidades e padrões de código WordPress que melhoram o LCP, o INP, o CLS e a navegação para trás no telemóvel.

#Cronologia da indexação mobile-first de 2016 a 2024

As boas práticas de indexação mobile-first do Google definem o termo numa linha: o Google usa a versão móvel do conteúdo de um site, rastreada com o agente de smartphone, para indexar e classificar. Levar a web inteira até lá demorou oito anos.

Na publicação de outubro de 2023, John Mueller e Nir Kalush descreveram o pequeno grupo de sites que ainda restava no rastreador de desktop. Os erros eram páginas que mostram erros a todos os utilizadores móveis, uma versão móvel bloqueada no robots.txt enquanto a versão desktop continua rastreável, e páginas móveis que redirecionam todas para a página inicial. Em junho de 2024, Mueller escreveu que, depois de 5 de julho de 2024, um site cujo conteúdo não possa ser acedido de todo a partir de um dispositivo móvel deixaria de ser indexável. O Googlebot Desktop continua a aparecer nos registos do servidor para algumas funcionalidades, como as listagens de produtos e o Google for Jobs, por isso um user agent de desktop no seu registo de acessos não significa que o seu site tenha sido ignorado.

O “índice móvel de 2026” não é, portanto, um índice novo. A mudança aconteceu em 2023 e 2024. O que continua a mudar é o conteúdo das suas páginas móveis e a rapidez com que carregam para visitantes reais.

#O que a documentação mobile-first do Google pede aos sites WordPress que verifiquem

A página de boas práticas é uma lista de verificação de paridade. A versão móvel de uma página deve corresponder à versão desktop em:

• conteúdo principal, incluindo texto, imagens e vídeo
• dados estruturados
• elemento title e meta description
• texto alternativo das imagens
• meta tags robots
• títulos

A mesma página desaconselha o carregamento diferido de conteúdo principal que só aparece depois de uma interação do utilizador, como um toque ou um deslize, porque o rastreador não realiza essas interações. No WordPress, os culpados habituais são separadores ou acordeões que vão buscar o conteúdo por AJAX ao clicar, e templates móveis separados de plugins móveis mais antigos que deixam cair secções, schema ou texto alternativo. Um tema responsivo que envia o mesmo HTML a todos os dispositivos passa na verificação de paridade por definição. É uma das razões para ter cuidado com HTML específico por dispositivo, tema da secção sobre Client Hints mais abaixo.

#Limiares das Core Web Vitals para mobile em 2026

Os limiares atuais são:

Desde março de 2024, a métrica de capacidade de resposta é o Interaction to Next Paint. A publicação de lançamento no web.dev, de Rick Viscomi, anunciou o INP como Core Web Vital estável em substituição do First Input Delay e deu aos programadores até 9 de setembro de 2024 para abandonarem o FID. Um guia que ainda apresenta o FID como Core Web Vital é anterior a essa mudança.

Cada limiar é avaliado no percentil 75 dos carregamentos de página, segmentado entre mobile e desktop (web.dev, Web Vitals). Mobile e desktop são populações separadas, por isso um resultado rápido em desktop não diz nada sobre o resultado no telemóvel.

Muitas equipas definem metas internas abaixo da linha de “bom” para ter margem, porque os dados de campo variam com a composição do tráfego, as campanhas e os scripts de terceiros. A própria documentação do Google sobre experiência de página deixa um aviso: perseguir uma pontuação perfeita apenas por razões de SEO pode não ser a melhor forma de usar o seu tempo.

#Como o Google usa os sinais de experiência de página na classificação

A documentação do Google sobre experiência de página responde diretamente à questão da classificação:

• Não existe um sinal único de experiência de página. Os sistemas de classificação principais analisam uma variedade de sinais.
• As Core Web Vitals são usadas pelos sistemas de classificação do Google.
• Para além das Core Web Vitals, os outros aspetos da experiência de página não ajudam diretamente um site a subir na classificação, embora tornem o site mais agradável de usar.
• A experiência de página é geralmente avaliada por página, com algumas avaliações ao nível do site inteiro.
• O Google continua a mostrar o conteúdo mais relevante quando a experiência de página é fraca. Uma boa experiência ajuda quando há muitas páginas igualmente úteis.

No trabalho móvel, isto define prioridades. O tamanho das áreas de toque, um menu móvel limpo e a elegibilidade para o bfcache valem a pena para os visitantes e para as Core Web Vitals que influenciam, mas o Google não os descreve como sinais de classificação separados. A mesma página não indica qualquer requisito de AMP: a sua autoavaliação abrange Core Web Vitals, HTTPS, apresentação em dispositivos móveis, anúncios, intersticiais intrusivos e uma área de conteúdo principal clara.

#Como testar a velocidade móvel em laboratório e no terreno

#Definições de emulação móvel do Lighthouse

A execução móvel predefinida do Lighthouse emula um Moto G Power (2022) com um viewport de 412 por 823 píxeis, definido nas constantes de configuração do Lighthouse. A documentação de limitação indica como predefinição de rede 150 ms de latência, 1,6 Mbps de descarga e 750 Kbps de envio, com o rótulo “Slow 4G” e descrita como aproximadamente o quartil inferior das ligações 4G. A limitação de CPU usa um multiplicador constante de 4x, pensado para levar um desktop topo de gama ao escalão de telemóveis de gama média. Num portátil mais lento, esse multiplicador exagera, por isso verifique o valor “CPU/Memory Power” no fundo do relatório antes de comparar execuções feitas em máquinas diferentes.

• Lighthouse (Chrome DevTools): emulação móvel com limitação de CPU e de rede
• PageSpeed Insights: dados de utilizadores reais (CrUX) e uma execução de laboratório do Lighthouse
• WebPageTest: testes em dispositivos reais a partir de diferentes localizações

#Dados de campo do CrUX e da Search Console

Os dados de campo são os que a avaliação das Core Web Vitals usa. A metodologia do CrUX recolhe dados apenas de utilizadores do Chrome que ativam o envio de estatísticas de utilização e sincronizam o histórico do navegador, e o Chrome em iOS fica excluído. O Safari não é o Chrome, por isso também não contribui. Um site cujo público móvel usa sobretudo iPhone recebe a sua pontuação de campo móvel a partir dos visitantes Android.

• Chrome User Experience Report (CrUX): dados reais de utilizadores do Chrome
• Google Search Console (relatório Core Web Vitals): grupos mobile e desktop para os seus próprios URLs
• RUM (Real User Monitoring): ferramentas como SpeedCurve, Calibre ou New Relic para monitorização contínua em todos os navegadores

#Em que telemóveis reais testar

Nenhum emulador reproduz por completo um dispositivo real. Tenha pelo menos estes para testes:

• um smartphone de gama média (Moto G ou Samsung Galaxy A)
• um smartphone topo de gama recente (iPhone ou Pixel)
• um tablet (iPad ou Samsung Tab)

#Carregamento adaptativo por dispositivo no WordPress

O carregamento adaptativo serve versões mais leves ou mais pesadas da mesma página consoante aquilo que o dispositivo do visitante aguenta.

#Como detetar as capacidades do dispositivo com JavaScript

// Detetar as capacidades do dispositivo, com valores predefinidos quando falta uma API
const getDeviceCapabilities = () => {
  return {
    // Núcleos de CPU
    cores: navigator.hardwareConcurrency || 4,
    // Memória aproximada do dispositivo em GB (não disponível em todos os navegadores)
    memory: navigator.deviceMemory || 4,
    // Tipo efetivo de ligação
    connection: navigator.connection?.effectiveType || '4g',
    // Preferência por poupança de dados
    saveData: navigator.connection?.saveData || false,
  };
};

A MDN marca navigator.deviceMemory como de disponibilidade limitada, fora do Baseline, disponível apenas por HTTPS e propositadamente impreciso: o valor é arredondado a uma potência de dois para dificultar o fingerprinting. Trate-o como uma indicação com um valor predefinido seguro. A escolha do formato de imagem não precisa de deteção nenhuma, porque o elemento picture mostrado mais abaixo deixa o próprio navegador escolher entre AVIF e WebP.

#O que servir a telemóveis topo de gama, de gama média e de gama baixa

Com base nas capacidades detetadas:

Dispositivos topo de gama (8+ núcleos, 8+ GB de RAM, ligação rápida):

• imagens AVIF em qualidade total
• JavaScript completo com animações
• carregamento especulativo mais amplo das páginas seguintes prováveis
• vídeos de fundo onde servem o conteúdo

Dispositivos de gama média (4 a 6 núcleos, 4 a 6 GB de RAM, 4G):

• imagens de qualidade média
• JavaScript reduzido, animações CSS simples
• carregamento especulativo apenas para as ligações principais
• imagens estáticas em vez de vídeos de fundo

Dispositivos de gama baixa (2 a 4 núcleos, menos de 4 GB de RAM, ligação lenta ou Save-Data):

• imagens comprimidas de forma agressiva
• apenas o JavaScript essencial
• sem carregamento especulativo, para poupar largura de banda
• um layout simplificado sem efeitos visuais

#Client Hints, Accept-CH e cache de páginas no WordPress

Os Client Hints permitem ao servidor tomar a mesma decisão antes de enviar o HTML. O navegador não os envia por iniciativa própria. Segundo o guia de Client Hints da MDN, o servidor anuncia que hints quer num cabeçalho de resposta Accept-CH, e o navegador inclui-os nos pedidos seguintes. A primeira visualização de página de um visitante novo chega, portanto, sem eles. Apenas os hints de baixa entropia (Save-Data, Sec-CH-UA, Sec-CH-UA-Mobile e Sec-CH-UA-Platform) podem ser enviados por predefinição. A memória do dispositivo segue como Sec-CH-Device-Memory, e a qualidade da rede como ECT, RTT e Downlink.

// 1. Pedir ao navegador hints de dispositivo e de rede nos pedidos seguintes
add_action('send_headers', function () {
    header('Accept-CH: Sec-CH-Device-Memory, ECT');
    header('Vary: Sec-CH-Device-Memory', false);
});

// 2. Ler os hints e escolher um nível de desempenho
function device_aware_content_strategy() {
    $memory = isset($_SERVER['HTTP_SEC_CH_DEVICE_MEMORY'])
        ? (float) $_SERVER['HTTP_SEC_CH_DEVICE_MEMORY']
        : null;

    $ect = $_SERVER['HTTP_ECT'] ?? null;

    if ($memory && $memory >= 8 && $ect === '4g') {
        define('WP_DEVICE_TIER', 'high');
    } elseif (($memory && $memory <= 2) || in_array($ect, ['slow-2g', '2g'], true)) {
        define('WP_DEVICE_TIER', 'low');
    } else {
        define('WP_DEVICE_TIER', 'medium');
    }
}
add_action('init', 'device_aware_content_strategy');

É na cache que a adaptação do lado do servidor costuma falhar. Um plugin de cache de página inteira ou uma CDN guarda uma cópia do HTML por URL, a menos que a chave de cache inclua o hint. Sem isso, o nível escolhido para o primeiro visitante é servido a todos os que vêm depois. A MDN recomenda indicar no cabeçalho Vary os hints que alteram uma resposta e avisa que hints com muitos valores possíveis, como Downlink e RTT, tornam uma resposta praticamente impossível de guardar em cache. Para a maioria dos sites WordPress, a divisão mais segura é manter o HTML idêntico para todos os dispositivos, deixar srcset e sizes escolherem os ficheiros de imagem e fazer a adaptação de JavaScript no cliente. Isso também mantém a paridade de conteúdo que a documentação mobile-first do Google pede.

#Como melhorar o LCP em mobile

O Largest Contentful Paint é normalmente a métrica mais difícil de melhorar em mobile, porque depende ao mesmo tempo da rede, do CPU e do tamanho do conteúdo.

#Que elemento é o LCP em mobile

Na maioria das páginas WordPress, o elemento LCP móvel é um destes:

• a imagem de destaque ou imagem hero do artigo
• uma imagem de banner num slider
• o primeiro bloco longo de texto, em páginas sem imagens

#Subpartes do LCP e onde se gasta o tempo

O guia do web.dev para otimizar o LCP divide a métrica em quatro subpartes: tempo até ao primeiro byte, atraso no carregamento do recurso (desde o TTFB até o navegador começar a carregar o recurso LCP), duração do carregamento do recurso e atraso na renderização do elemento (desde o fim da transferência até o elemento estar totalmente renderizado). O orçamento do guia é que a maior parte do tempo seja gasta a carregar o documento HTML e o recurso LCP, cerca de 40 por cento cada, enquanto cada um dos dois atrasos fica abaixo de 10 por cento. Um atraso longo no carregamento do recurso quase sempre significa que o navegador encontrou a imagem tarde. O mesmo guia indica uma imagem LCP definida como fundo CSS como um caso que o preload scanner não consegue descobrir no HTML, e diz para nunca carregar a imagem LCP em diferido.

#Como acelerar o LCP com preload, formato e tamanho de imagem

Pré-carregar o recurso LCP:

<link rel="preload" as="image" href="/images/hero-mobile.avif"
      type="image/avif" fetchpriority="high">

Eliminar cadeias de descoberta: O navegador deve encontrar o recurso LCP o mais cedo possível:

1. O HTML é descarregado (TTFB)
2. O recurso LCP é descoberto no HTML
3. Começa a transferência do recurso

Se a sua imagem hero estiver referenciada numa folha de estilos externa como background-image, o navegador só a descobre depois de descarregar e analisar o CSS. Coloque um <img> diretamente no HTML com fetchpriority="high".

Formato de imagem ideal:

<picture>
  <source srcset="/images/hero-400.avif 400w,
                  /images/hero-800.avif 800w"
          type="image/avif" sizes="100vw">
  <source srcset="/images/hero-400.webp 400w,
                  /images/hero-800.webp 800w"
          type="image/webp" sizes="100vw">
  <img src="/images/hero-800.jpg"
       alt="Descrição relevante"
       width="800" height="450"
       fetchpriority="high"
       decoding="async">
</picture>

Tamanhos de imagem específicos para mobile: Não envie o mesmo ficheiro para telemóveis e desktops. Um ecrã de telemóvel com 400 píxeis de largura não precisa de uma imagem de 1920 píxeis (mais no nosso guia de otimização de imagens e critical CSS):

// Adicionar tamanhos de imagem para layouts móveis
function add_mobile_image_sizes() {
    add_image_size('mobile-hero', 480, 270, true);
    add_image_size('mobile-thumbnail', 320, 180, true);
}
add_action('after_setup_theme', 'add_mobile_image_sizes');

#Funcionalidades do núcleo do WordPress para imagens responsivas e lazy loading

Grande parte do trabalho com imagens descrito acima já está no núcleo do WordPress, e um plugin que o repete pode atrapalhar.

• WordPress 4.4 (2015): srcset e sizes. A nota de desenvolvimento de Joe McGill explica que o WordPress adiciona srcset e sizes ao markup de imagem que gera, para que o navegador possa descarregar o tamanho mais adequado. O valor predefinido de sizes assume que a imagem é mostrada na sua própria largura até à largura total do viewport, e a nota indica aos temas que o ajustem com o filtro wp_calculate_image_sizes (wp_calculate_image_srcset altera a lista de candidatos). O filtro max_srcset_image_width limita as larguras incluídas, 1600 píxeis por predefinição. A mesma versão acrescentou o tamanho medium_large, com 768 píxeis de largura e sem limite de altura, gerado apenas para novos carregamentos ou quando os tamanhos são regenerados.
• WordPress 5.5: lazy loading nativo. O atributo loading é controlado por wp_lazy_loading_enabled, introduzido na 5.5 e ativo para iframes por predefinição desde a 5.7.
• WordPress 6.3: atributos de otimização de carregamento. wp_get_loading_optimization_attributes decide se uma imagem recebe loading="lazy", fetchpriority="high" ou decoding="async". Não mexe em atributos já presentes e emite um aviso se um elemento for receber ao mesmo tempo lazy loading e prioridade alta. Desde a 7.0 aceita também fetchpriority="low" e fetchpriority="auto", para que o lazy loading não seja adicionado.

A verificação prática faz-se no HTML renderizado de uma página real num viewport de telemóvel: a imagem hero deve ter fetchpriority="high" e nenhum loading="lazy", e o seu valor sizes deve corresponder ao espaço que a imagem ocupa de facto no layout móvel. Um tema que imprime a imagem hero como fundo CSS salta tudo isto.

#Carregamento especulativo no WordPress 6.8

O WordPress 6.8 ativou o carregamento especulativo através da Speculation Rules API do navegador. A nota de desenvolvimento de Felix Arntz descreve as predefinições:

• Está ativo no frontend de todos os sites, exceto para utilizadores com sessão iniciada e sites com as ligações permanentes amigáveis desativadas.
• Os URLs são pré-obtidos com avidez conservadora (conservative eagerness), que é acionada quando o utilizador começa a clicar numa ligação.
• Os URLs com parâmetros de consulta são excluídos automaticamente, o que cobre a maioria dos “URLs de ação” que alteram o estado num pedido GET.
• O Chrome, o Edge e o Opera suportam a API; os outros navegadores ignoram-na, por isso nada deixa de funcionar.

A nota refere que o plugin da funcionalidade correu em mais de 50 000 sites antes da integração no núcleo, e que os sites que o usavam melhoraram a taxa de aprovação no LCP em cerca de 1,9 por cento na mediana, medida com dados do HTTP Archive e do CrUX. Em mobile, onde os toques para recuar e avançar e os toques em ligações são todo o modelo de navegação, isto pesa mais do que em desktop. Plugins com caminhos de ação próprios, como um carrinho, devem excluí-los:

add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $href_exclude_paths ) {
    $href_exclude_paths[] = '/cart/*';
    return $href_exclude_paths;
} );

#Como melhorar o INP em mobile

O INP mede a rapidez com que a página responde às ações do utilizador. O artigo do web.dev sobre o INP conta três tipos de interação: cliques do rato, toques num ecrã tátil e teclas premidas num teclado físico ou no ecrã. Passar o cursor por cima, fazer zoom e deslocar a página não são observados. A latência de cada interação tem três partes: o atraso de entrada antes de qualquer handler correr, o tempo de processamento dos handlers e o atraso de apresentação até ser pintado o frame seguinte. Num telemóvel, todas as interações são toques e o CPU é mais lento, por isso as três partes crescem.

#Principais causas de um mau INP em mobile

1. JavaScript pesado na thread principal: scripts de terceiros (analítica, chat, anúncios) que bloqueiam a interação.
2. Hidratação de frameworks: React, Vue ou Angular a hidratar componentes depois do carregamento inicial.
3. Handlers de eventos dispendiosos: listeners que executam cálculos pesados ao toque.
4. Tarefas longas: o guia do web.dev para otimizar tarefas longas define uma tarefa longa como qualquer tarefa que demore mais de 50 ms.

#Como reduzir o INP adiando JavaScript

Adiar o JavaScript não crítico:

<!-- Carregar a analítica depois da primeira interação do utilizador -->
<script>
  let analyticsLoaded = false;
  function loadAnalytics() {
    if (analyticsLoaded) return;
    analyticsLoaded = true;
    const script = document.createElement('script');
    script.src = '/analytics.js';
    document.head.appendChild(script);
  }

  // Carregar no primeiro toque, deslocamento ou tecla premida, ou ao fim de 5 segundos
  ['touchstart', 'scroll', 'keydown'].forEach(event => {
    document.addEventListener(event, loadAnalytics, { once: true, passive: true });
  });
  setTimeout(loadAnalytics, 5000);
</script>

Usar requestIdleCallback para trabalho não urgente:

// Executar trabalho não crítico enquanto o navegador está inativo
requestIdleCallback((deadline) => {
  while (deadline.timeRemaining() > 0) {
    processNonCriticalTask();
  }
});

Ceder a vez dentro dos handlers de eventos:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

button.addEventListener('click', async () => {
  showSpinner();        // feedback visível no frame seguinte
  await yieldToMain();  // deixar o navegador pintar primeiro
  heavyCalculation();   // a parte lenta corre numa tarefa posterior
});

Envolver o trabalho pesado em requestAnimationFrame não ajuda, porque essa callback corre imediatamente antes da pintura seguinte e continua a atrasar o frame. Ceder a vez divide o trabalho para que o navegador possa primeiro pintar a resposta ao toque. O guia das tarefas longas nota que scheduler.yield() é suportado no Chrome e no Edge 129 e no Firefox 142, mas não no Safari, e é por isso que existe a alternativa com setTimeout.

#Como evitar o CLS em mobile no WordPress

O Cumulative Layout Shift (CLS) prejudica mais num telemóvel, onde o ecrã é pequeno e qualquer movimento se nota. Num telemóvel, um deslocamento de 10 píxeis perturba muito mais do que num monitor de 27 polegadas.

#O que provoca CLS em mobile

• imagens sem dimensões explícitas
• tipos de letra web que provocam FOUT ou FOIT
• anúncios e conteúdo injetado dinamicamente
• barras de navegação que mudam de tamanho ao deslocar a página
• o teclado virtual a empurrar o conteúdo

#Como reservar espaço para imagens, tipos de letra e anúncios

Reservar espaço para imagens:

/* Caixas com proporção fixa para imagens */
.wp-post-image {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
  object-fit: cover;
}

Pré-carregar os tipos de letra críticos:

<link rel="preload" href="/fonts/main-font.woff2"
      as="font" type="font/woff2" crossorigin>

/* font-display: swap com um tipo de letra alternativo de métricas ajustadas */
@font-face {
  font-family: 'MainFont';
  src: url('/fonts/main-font.woff2') format('woff2');
  font-display: swap;
  size-adjust: 98%;
  ascent-override: 95%;
  descent-override: 22%;
}

Reservar espaço para anúncios:

.ad-slot {
  min-height: 250px; /* Altura prevista do anúncio */
  background: #f5f5f5;
  contain: layout;
}

#Como tornar as páginas WordPress elegíveis para o bfcache

A back/forward cache guarda em memória uma cópia completa de uma página, incluindo a heap de JavaScript, para que recuar a restaure quase instantaneamente sem tocar na rede. O guia do bfcache no web.dev, de Philip Walton e Barry Pollard, cita dados de utilização do Chrome que mostram que 1 em cada 5 navegações em mobile é uma navegação para trás ou para a frente, contra 1 em cada 10 em desktop. Todos os principais navegadores têm bfcache, o Chrome desde a versão 96.

#O que bloqueia o bfcache

• Listeners de unload. Em desktop, o Chrome e o Firefox tornam inelegível uma página com um listener de unload. Em mobile, o Chrome e o Safari continuam a tentar guardar essas páginas em cache, mas o handler deixa de ser fiável. Use pagehide em vez disso; o Lighthouse tem uma auditoria no-unload-listeners que também apanha código de terceiros.
• Cache-Control: no-store no HTML. Historicamente, os navegadores recusaram-se a colocar essas páginas no bfcache. Para conteúdo que tem de se manter atualizado mas não é sensível, o guia recomenda no-cache ou max-age=0, que não afetam a elegibilidade.
• Referências a window.opener. Uma página aberta com window.open() e controlada a partir da página que a abriu não pode ser guardada em cache. rel="noopener" evita isso e é hoje o comportamento predefinido dos navegadores para target="_blank".
• Ligações abertas. Alguns navegadores ignoram páginas com uma ligação IndexedDB aberta, um fetch() ou XMLHttpRequest em curso, ou uma ligação WebSocket ou WebRTC aberta. O guia nota que o Chrome (a partir da versão 149) e o Safari já não bloqueiam com WebSockets abertos. Feche as ligações em pagehide e volte a abri-las em pageshow.

Os utilizadores móveis navegam constantemente com o botão Retroceder. Quando uma página volta do bfcache, aparece sem um novo pedido.

#Como verificar se uma página foi restaurada do bfcache

// Verificar se a página foi restaurada do bfcache
window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('Page restored from bfcache');
    // Atualizar conteúdo dinâmico, como contagens do carrinho, se necessário
    refreshDynamicContent();
  }
});

O guia recomenda também atualizar dados desatualizados ou sensíveis em pageshow quando persisted é verdadeiro, por exemplo o total do carrinho depois de o utilizador o ter alterado noutra página.

#Definições do WordPress para o bfcache

// Enviar os cabeçalhos de cache e de política antes de qualquer output
add_action('send_headers', function () {
    if (!is_user_logged_in()) {
        header('Cache-Control: public, max-age=300');
        // Recusar handlers de unload, incluindo os adicionados por terceiros
        header('Permissions-Policy: unload=()');
    }
});

// Remover um script de plugin que se sabe registar um handler de unload
add_action('wp_enqueue_scripts', function () {
    wp_dequeue_script('plugin-with-unload-handler');
}, 99);

Os cabeçalhos pertencem a send_headers, porque wp_enqueue_scripts corre dentro de wp_head, depois de o output já ter começado. A linha da Permissions Policy segue o conselho do guia do bfcache para sites que não usam unload de todo. O Chrome DevTools tem um teste de back/forward cache no painel Application que indica o motivo exato do bloqueio de uma página.

#Áreas de toque e menus móveis fáceis de tocar

As áreas de toque contam para a usabilidade e a acessibilidade. O Google não as descreve como sinal de classificação.

#Tamanho mínimo das áreas de toque

• WCAG 2.2, critério de sucesso 2.5.8 (nível AA): o documento Understanding exige alvos de ponteiro com pelo menos 24 por 24 píxeis CSS, com exceções para espaçamento, um controlo equivalente, alvos em linha no texto, controlos do agente de utilizador e casos essenciais. Para controlos importantes, remete para o critério mais exigente 2.5.5 Target Size (Enhanced).
• Orientação do Lighthouse sobre áreas de toque: a documentação da auditoria diz que áreas de 48 por 48 píxeis nunca falham e que 8 píxeis entre áreas é um bom ponto de partida.

A exceção para alvos em linha importa no CSS. As ligações dentro de parágrafos não precisam de altura mínima, por isso aplique o dimensionamento apenas à navegação, aos botões e aos controlos de formulário:

/* Áreas de toque mínimas para controlos, não para ligações dentro do texto */
nav a, button, input, select, textarea, .wp-block-button__link {
  min-height: 48px;
  min-width: 48px;
  padding: 12px;
}

#Como tornar um menu móvel fácil de tocar

Os menus de navegação móveis exigem cuidado redobrado com as áreas de toque:

.mobile-nav a {
  display: block;
  padding: 16px 24px;
  min-height: 48px;
  font-size: 16px; /* Legível sem zoom */
  line-height: 1.5;
}

.mobile-nav li + li {
  border-top: 1px solid #eee;
}

#Otimização de Core Web Vitals móveis na WPPoland

Na WPPoland, construímos para o dispositivo que o utilizador tem na mão, não para o monitor que temos na secretária.

1. Carregamento adaptativo: mantemos o HTML idêntico em todos os dispositivos e adaptamos imagens e scripts onde as medições mostram ganhos.
2. Auditoria específica para mobile: testamos em dispositivos móveis reais, não apenas em emulação no navegador.
3. Primeiro os dados de campo: trabalhamos sobre o relatório CrUX móvel, levando grupos de URLs de “Fraco” ou “Precisa de melhorias” para “Bom”.

#Conclusão

O Google rastreia e indexa a web como um smartphone desde que a migração terminou, em 2023 e 2024. O trabalho de desempenho móvel no WordPress resume-se hoje a algumas coisas mensuráveis: o mesmo conteúdo em todos os dispositivos, uma imagem LCP que o navegador encontra no HTML, tarefas curtas em torno de cada toque, espaço reservado para tudo o que carrega tarde e páginas que o bfcache consegue guardar. Meça-as no CrUX para os seus visitantes móveis, confirme-as com o Lighthouse num perfil com limitação e corrija cada métrica das Core Web Vitals por essa ordem. Para o INP em particular, consulte o guia de otimização do INP.

Se as Core Web Vitals móveis estão a travar as suas posições, contacte a WPPoland para uma auditoria móvel.