(Provavelmente) Não precisas de jQuery em 2026: o guia completo de migração

O jQuery resolveu problemas reais de compatibilidade entre navegadores durante mais dé uma década. Em 2008, quando esté artigo foi publicado pela primeira vez, escrever JavaScript cross-browser sem jQuery era genuinamente doloroso. O Internet Explorer 6 tratava os eventos de forma diferente, os seletores CSS eram inconsistentes é o AJAX requeria implementações específicas de XMLHttpRequest para cada navegador.

Descobre mais sobre otimização de velocidade WordPress na WPPoland.

Em 2026, cada problema qué o jQuery resolvia é agora tratado nativamente pelos navegadores. A questão já não é se migrar, mas como fazê-lo de forma segura sem comprometer a funcionalidade existente.

#Porque é qué o jQuery é dívida técnica em 2026

O jQuery 3.7 pesa 87KB não comprimido (30KB gzipped). Pode parecer pouco, mas considera o que custa:

• Total Blocking Time (TBT): O jQuery tem de ser analisado e executado antes de qualquer código dependente poder correr. Em dispositivos móveis de gama média, isto adiciona 150-300ms ao TBT.
• Interaction to Next Paint (INP): O sistema de delegação de eventos do jQuery adiciona overhead a cada interação do utilizador, piorando de forma mensurável as pontuações INP.
• Cadeia de dependências: Carregar jQuery significa que cada script que depende dele tem de esperar, criando uma cascata de recursos bloqueantes.
• Código redundante: Cada método jQuery que chamas tem um equivalente nativo qué o navegador já disponibiliza. Estás a pagar duas vezes pela mesma funcionalidade.

#Benchmarks de desempenho: jQuery vs vanilla JS

Medições reais num tema WordPress com interações típicas (toggle de menu, troca de separadores, validação de formulário, carregamento AJAX de mais conteúdo):

Estes números provêm dé um site WordPress em produção com GeneratePress e WooCommerce, testado num Moto G Power (um dispositivo de gama média representativo).

#JavaScript moderno (ES2024+) substitui cada padrão jQuery

A especificação ES2024, totalmente suportada no Chrome 124+, Firefox 126+, Safari 17.4+ e Edge 124+, fornecé alternativas nativas para cada padrão comum de jQuery.

#Seleção DOM

// jQuery
const $buttons = $('.btn');
const $container = $('#main-container');
const $firstItem = $('.menu-item:first');

// Vanilla JS (ES2024+)
const buttons = document.querySelectorAll('.btn');
const container = document.getElementById('main-container');
const firstItem = document.querySelector('.menu-item');

// Seleção com âmbito (como jQuery .find())
const navLinks = container.querySelectorAll('a.nav-link');

Diferença chave: querySelectorAll devolvé um NodeList estático, não uma coleção viva. Isto é na verdade mais seguro porqué a lista não muda inesperadamente quando o DOM é alterado.

#Tratamento de eventos

// jQuery
$('.btn').click(function () {
  $(this).toggleClass('active');
});

$('.menu').on('click', '.menu-item', function () {
  // evento delegado
});

// Vanilla JS
document.querySelectorAll('.btn').forEach(btn => {
  btn.addEventListener('click', () => {
    btn.classList.toggle('active');
  });
});

// Delegação de eventos (substitui .on() com seletor)
document.querySelector('.menu').addEventListener('click', (e) => {
  const item = e.target.closest('.menu-item');
  if (item) {
    // tratar clique no elemento do menu
  }
});

O método closest() é o equivalente moderno do matching de eventos delegados do jQuery. Percorré a árvore DOM para cima para encontrar o ancestral mais próximo que corresponda a um seletor.

#Manipulação de classes

// jQuery
$el.addClass('active');
$el.removeClass('hidden');
$el.toggleClass('open');
$el.hasClass('visible');

// Vanilla JS
el.classList.add('active');
el.classList.remove('hidden');
el.classList.toggle('open');
el.classList.contains('visible');

// Múltiplas classes dé uma vez
el.classList.add('active', 'highlighted', 'animate-in');
el.classList.remove('hidden', 'collapsed');

#AJAX com fetch API é async/await

// jQuery
$.ajax({
  url: '/wp-json/wp/v2/posts',
  method: 'GET',
  data: { per_page: 5 },
  success: function (posts) { renderPosts(posts); },
  error: function (xhr) { console.error(xhr); }
});

// Vanilla JS (async/await moderno)
async function loadPosts() {
  try {
    const response = await fetch('/wp-json/wp/v2/posts?per_page=5');

    if (!response.ok) {
      throw new Error(`HTTP ${response.status}: ${response.statusText}`);
    }

    const posts = await response.json();
    renderPosts(posts);
  } catch (error) {
    console.error('Falha ao carregar publicações:', error);
  }
}

// POST com nonce (padrão WordPress)
async function submitForm(data) {
  const response = await fetch('/wp-json/custom/v1/submit', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'X-WP-Nonce': wpApiSettings.nonce,
    },
    body: JSON.stringify(data),
  });

  return response.json();
}

#Animações sem jQuery

Os métodos .fadeIn(), .slideDown() e .animate() do jQuery podem ser substituídos por transições CSS, animações CSS ou a Web Animations API.

// jQuery
$('.panel').slideDown(300);
$('.modal').fadeIn(200);

// Abordagem CSS (preferida para desempenho)
// Em CSS:
// .panel { max-height: 0; overflow: hidden; transition: max-height 0.3s ease; }
// .panel.open { max-height: 500px; }

// Em JS:
panel.classList.add('open');

// Web Animations API (para animações complexas e programáticas)
modal.animate(
  [
    { opacity: 0, transform: 'scale(0.95)' },
    { opacity: 1, transform: 'scale(1)' },
  ],
  { duration: 200, easing: 'ease-out', fill: 'forwards' }
);

A Web Animations API corre na thread do compositor, o que significa qué as animações não bloqueiam a thread principal. As animações jQuery correm na thread principal e causam jank em dispositivos mais lentos.

#Manipulação DOM

// jQuery
$('<div class="notice">Olá</div>').appendTo('#container');
$('.old-element').replaceWith('<span>Novo</span>');
$('.item').remove();
$('.list').empty();

// Vanilla JS
const notice = document.createElement('div');
notice.className = 'notice';
notice.textContent = 'Olá';
container.append(notice);

// Ou usa insertAdjacentHTML para strings HTML
container.insertAdjacentHTML('beforeend', '<div class="notice">Olá</div>');

// Substituir
oldElement.replaceWith(Object.assign(document.createElement('span'), { textContent: 'Novo' }));

// Remover
item.remove();

// Esvaziar
list.replaceChildren();

#Document ready

// jQuery
$(document).ready(function () { /* ... */ });
$(function () { /* atalho */ });

// Vanilla JS
document.addEventListener('DOMContentLoaded', () => {
  // DOM está pronto
});

// Ou simplesmente coloca a tag <script> com type="module" no final do <body>
// Os módulos são diferidos por predefinição, portanto o DOM já está pronto

#Web Components: a substituição moderna dos plugins jQuery

Os plugins jQuery forneciam componentes UI reutilizáveis (sliders, modais, separadores, acordeões). Em 2026, os Web Components oferecem uma alternativa baseada em padrões com melhor encapsulamento.

#Exemplo: um componente de painel expansível

class TogglePanel extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: 'open' });
  }

  connectedCallback() {
    const title = this.getAttribute('title') || 'Alternar';

    this.shadowRoot.innerHTML = `
      <style>
        :host { display: block; margin: 1rem 0; }
        button {
          width: 100%; padding: 0.75rem 1rem;
          background: #f5f5f5; border: 1px solid #ddd;
          cursor: pointer; text-align: left;
          font-size: 1rem; font-weight: 600;
        }
        .content {
          display: none; padding: 1rem;
          border: 1px solid #ddd; border-top: none;
        }
        :host([open]) .content { display: block; }
      </style>
      <button part="trigger">${title}</button>
      <div class="content"><slot></slot></div>
    `;

    this.shadowRoot.querySelector('button').addEventListener('click', () => {
      this.toggleAttribute('open');
    });
  }
}

customElements.define('toggle-panel', TogglePanel);

Utilização em HTML:

<toggle-panel title="Informações de envio">
  <p>Envio gratuito em encomendas acima de 50 EUR.</p>
</toggle-panel>

Os Web Components fornecem encapsulamento Shadow DOM (os estilos não vazam), slots para projeção de conteúdo e callbacks de ciclo de vida. Funcionam em todos os navegadores modernos sem polyfills.

#Quando usar Web Components vs. um framework

#Estratégia de migração para projetos WordPress

#Passo 1: Auditar o uso de jQuery

Executa este comando no diretório do tema para encontrar todas as referências ao jQuery:

grep -rn '\$(\|jQuery\.\|jQuery(' --include='*.js' --include='*.php' .

Categoriza cada utilização:

• O teu código (tema/plugin personalizado): migra isto
• Plugin de terceiros: deixa, o plugin geré as suas próprias dependências
• Admin do WordPress: não mexas, o núcleo do WordPress trata disto

#Passo 2: Criar um plano de migração

Prioriza pelo impacto:

1. Código frontend do tema (afeta cada visitante) - migra primeiro
2. Frontend de plugin personalizado - migra em segundo
3. Personalizações do lado admin - migra por último (menos tráfego)

#Passo 3: Substituir padrões incrementalmente

Não reescrevas tudo dé uma vez. Substitui um ficheiro de cada vez:

1. Remove array('jquery') do array de dependências de wp_enqueue_script do ficheiro
2. Substitui todos os padrões jQuery por equivalentes vanilla JS
3. Testá no Chrome, Firefox, Safari e Edge
4. Testá com todos os plugins ativos
5. Executa Lighthousé antes e depois para medir a melhoria

#Passo 4: Tratar o padrão AJAX do WordPress

O AJAX legado do WordPress usa admin-ajax.php com jQuery:

// Padrão antigo (jQuery + admin-ajax)
jQuery.post(ajaxurl, {
  action: 'my_custom_action',
  nonce: myData.nonce,
  post_id: 123,
}, function (response) {
  console.log(response);
});

// Padrão moderno (fetch + REST API)
async function myCustomAction(postId) {
  const response = await fetch('/wp-json/myplugin/v1/action', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'X-WP-Nonce': myData.nonce,
    },
    body: JSON.stringify({ post_id: postId }),
  });

  return response.json();
}

A abordagem REST API é mais rápida (sem overhead do admin-ajax.php), mais cacheável e segué os padrões modernos de desenvolvimento WordPress.

#Passo 5: Registar scripts corretamente

// Antes (com dependência jQuery)
wp_enqueue_script(
  'my-theme-scripts',
  get_template_directory_uri() . '/js/main.js',
  array('jquery'),
  '1.0.0',
  true
);

// Depois (sem jQuery, com suporté a módulos)
wp_enqueue_script_module(
  'my-theme-scripts',
  get_template_directory_uri() . '/js/main.js',
  array(),
  '2.0.0'
);

O WordPress 6.5+ suporta wp_enqueue_script_module() que carrega scripts como módulos ES com type="module", permitindo a sintaxe nativa de import/export.

#Quando manter o jQuery ainda faz sentido

O jQuery pode continuar a ser justificado se:

• Base de código legada com mais de 50 dependências de plugins jQuery: O custo de migração supera o benefício de desempenho. Planeia uma eliminação gradual ao longo de 6-12 meses.
• Personalizações do admin WordPress: A área dé administração já carrega jQuery. Adicionar scripts dé admin próprios com dependência jQuery não custa nada extra.
• Requisitos de plugins de terceiros: Alguns plugins populares (certos construtores de formulários, construtores de páginas) requerem jQuery. Não lutes contra a dependência se não a consegues controlar.
• Lacuna de competências da equipa: Sé a tua equipa de desenvolvimento não está à vontade com JS moderno, investe em formação antes de forçar uma migração. Compreender o que faz um programador WordPress ajuda a definir expectativas realistas para as competências necessárias duranté a migração.

O objetivo é a melhoria pragmática, não a pureza ideológica. Remove jQuery onde te custa desempenho e não acrescenta valor. Mantém-no onde removê-lo quebraria coisas ou custaria mais do que poupa.

#Funcionalidades ES2024+ que substituem utilitários comuns do jQuery

#Clone estruturado (cópia profunda)

// jQuery
const copy = $.extend(true, {}, original);

// ES2024+
const copy = structuredClone(original);

#Iteração tipo array

// jQuery
$.each(items, function (index, item) { /* ... */ });

// ES2024+
items.forEach((item, index) => { /* ... */ });

// Ou com Array.from para NodeLists
Array.from(document.querySelectorAll('.item')).map(item => item.textContent);

// Ou operador spread
[...document.querySelectorAll('.item')].filter(item => item.dataset.active);

#Padrões Deferred/Promise

// jQuery
const deferred = $.Deferred();
deferred.resolve('feito');
deferred.promise().then(val => console.log(val));

// ES2024+
const promise = new Promise((resolve) => resolve('feito'));
promise.then(val => console.log(val));

// Promise.withResolvers() - funcionalidade ES2024
const { promise, resolve, reject } = Promise.withResolvers();

#IntersectionObserver (substitui handlers de scroll do jQuery)

// jQuery (handler de scroll dispendioso)
$(window).scroll(function () {
  $('.lazy-image').each(function () {
    if ($(this).offset().top < $(window).scrollTop() + $(window).height()) {
      $(this).attr('src', $(this).data('src'));
    }
  });
});

// Vanilla JS (eficiente, fora da thread principal)
const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const img = entry.target;
      img.src = img.dataset.src;
      observer.unobserve(img);
    }
  });
});

document.querySelectorAll('.lazy-image').forEach(img => observer.observe(img));

#Alternativas de bibliotecas utilitárias (se precisas dé um auxiliar)

Se te encontras a escrever os mesmos padrões vanilla JS repetidamente, considera uma micro-biblioteca em vez de jQuery:

Para temas WordPress em 2026, a recomendação é vanilla JS para interações simples e Alpine.js ou htmx se precisas de comportamento declarativo sem um framework completo.

#Melhores práticas de jQuery em 2026

Sé ainda manténs código jQuery - quer por escolha ou porqué uma base de código legada o exige - estas práticas minimizam os danos:

1. Carrega jQuery do núcleo do WordPress, nunca dé um CDN. O WordPress inclui uma versão compatível. Carregar uma segunda cópia do cdnjs ou code.jquery.com significa o dobro do peso e potenciais conflitos de versão.
2. Usa jQuery em vez de $ no WordPress. O WordPress executa jQuery em modo no-conflict. Envolver o código em jQuery(function($) { ... }) previne colisões com outras bibliotecas.
3. Evita aninhar .ready(). Um único jQuery(function($) { ... }) é suficiente. Chamadas aninhadas a .ready() criam pirâmides de callbacks e confundem a ordem de execução.
4. Faz cache dos seletores. Cada chamada a $('.my-class') percorré o DOM. Armazena os resultados numa variável quando usas o mesmo seletor mais do qué uma vez.
5. Delega eventos em vez dé os vincular a elementos individuais. Usa $(parent).on('click', '.child', handler) em vez de $('.child').click(handler). Isto trata elementos adicionados dinamicamente e usa menos listeners de eventos.
6. Não uses jQuery para animações CSS. Usa transições CSS ou a Web Animations API. O .animate() do jQuery corre na thread principal e causa jank.
7. Define jquery como dependência apenas quando necessário. Sé um ficheiro de script não usa jQuery, remove-o do array de dependências do wp_enqueue_script para evitar carregar jQuery desnecessáriamente.

#Versão mais recente do jQuery é o que mudou

Em 2026, jQuery 3.7.1 é a versão estável mais recente (lançada em agosto de 2023). jQuery 4.0.0-beta.2 está em beta desde fevereiro de 2024, sem data de lançamento estável anunciada.

Alterações do jQuery 4.0 que importam para WordPress:

O núcleo do WordPress atualmente inclui jQuery 3.7.1 e não se comprometeu a incluir a 4.0. A conclusão prática: não esperes pelo jQuery 4 para melhorar o desempenho. Migra para vanilla JS onde possível e usa as melhores práticas do jQuery 3.7.1 ondé a migração ainda não é viável.

#Quem ainda usa jQuery em 2026

O jQuery continua a ser carregado em cerca de 77% de todos os sites (segundo W3Techs), em grande parte porque WordPress, Shopify e sites empresariais legados o incluem por predefinição. Mas “carregado” não significa “necessário.”

A discriminação:

• Sites WordPress: O jQuery carrega em praticamente todas as páginas WordPress porqué a barra dé admin e muitos plugins populares dependem dele. No frontend, a dependência real é frequentementé apenas um ou dois scripts.
• Temas Shopify: A maioria dos temas Shopify inclui jQuery para interações do carrinho. A Shopify não se moveu para o descontinuar.
• Sistemas empresariais legados: Bancos, portais governamentais e grandes plataformas de e-commerce frequentemente têm jQuery incorporado em bases de código que datam de 2010-2015. A migração é dispendiosa e de baixa prioridade.
• Projetos novos: Quase nenhum. React, Vue, Svelte e vanilla JS dominam o desenvolvimento de novos projetos. Nenhum framework moderno ou template inicial inclui jQuery.

Se estás a iniciar um novo tema ou plugin WordPress em 2026, não há razão para adicionar jQuery como dependência. As APIs do navegador são suficientes para cada padrão comum. Para mais informações sobre como construir plugins corretamente, consulta a secção de melhores práticas para plugins WordPress no nosso guia de stack de plugins.

#Conclusão: a lista de verificação da migração

1. Audita todo o uso de jQuery no teu tema e plugins personalizados
2. Medé os Core Web Vitals atuais como referência
3. Substitui o código frontend do tema primeiro (maior impacto nos visitantes)
4. Usa querySelector, addEventListener, fetch, classList e Web Animations API
5. Considera Web Components para elementos UI reutilizáveis
6. Usa wp_enqueue_script_module() para suporté a módulos ES
7. Testá em todos os navegadores principais após cada migração de ficheiro
8. Medé os Core Web Vitals novamente e documenta a melhoria
9. Mantém jQuery apenas para scripts dé admin e dependências de plugins de terceiros
10. Forma a tua equipa em padrões modernos de JavaScript

A plataforma web em 2026 fornece tudo o qué o jQuery oferecia, e mais. Cada kilobyte de JavaScript desnecessário que removes torna o teu site WordPress mais rápido, mais acessível e mais fácil de manter.