jQuery vs Vanilla JS 2026: Migration, Risiken und wann es bleibt

jQuery vs Vanilla JS 2026: Migration, Risiken und wann es bleibt

Zuletzt überprüft: 20. Oktober 2026
17 Min. Lesezeit
Leitfaden
Full-Stack-Entwickler

jQuery hat über ein Jahrzehnt lang echte Browser-Kompatibilitätsprobleme gelöst. 2008, als dieser Artikel erstmals veröffentlicht wurde, war das Schreiben von Cross-Browser-JavaScript ohne jQuery wirklich schmerzhaft. Internet Explorer 6 behandelte Events anders, CSS-Selektoren waren inkonsistent und AJAX erforderte browserspezifische XMLHttpRequest-Implementierungen.

Erfahren Sie mehr über WordPress-Geschwindigkeitsoptimierung bei WPPoland.

2026 wird jedes Problem, das jQuery löste, nativ von Browsern behandelt. Die Frage ist nicht mehr ob man migrieren sollte, sondern wie man es sicher tut, ohne bestehende Funktionalität zu beschädigen.

#Bremst jQuery WordPress-Seiten aus?

jQuery 3.7 wiegt 87KB unkomprimiert (30KB gzipped). Das mag wenig klingen, aber bedenken Sie, was es kostet:

  • Total Blocking Time (TBT): jQuery muss geparst und ausgeführt werden, bevor abhängiger Code laufen kann. Auf Mittelklasse-Mobilgeräten fügt das 150-300ms zur TBT hinzu.
  • Interaction to Next Paint (INP): jQuerys Event-Delegationssystem fügt jeder Benutzerinteraktion Overhead hinzu und verschlechtert messbar die INP-Werte.
  • Abhängigkeitskette: Das Laden von jQuery bedeutet, dass jedes davon abhängige Script warten muss, was eine Kaskade blockierender Ressourcen erzeugt.
  • Redundanter Code: Jede jQuery-Methode, die Sie aufrufen, hat ein natives Äquivalent, das der Browser bereits mitbringt. Sie bezahlen doppelt für dieselbe Funktionalität.

#Performance-Benchmarks: jQuery vs Vanilla JS

Reale Messungen an einem WordPress-Theme mit typischen Interaktionen (Menü-Toggle, Tab-Wechsel, Formularvalidierung, AJAX-Nachladen):

MetrikMit jQueryOhne jQueryVerbesserung
Gesamte JS-Grösse142KB55KB-61%
TBT (mobil)480ms180ms-62%
INP (p75)220ms95ms-57%
LCP2.1s1.7s-19%
Lighthouse Performance7294+22 Punkte

Diese Zahlen stammen von einer produktiven WordPress-Website mit GeneratePress und WooCommerce, getestet auf einem Moto G Power (einem repräsentativen Mittelklassegerät).

#Was ist der Unterschied zwischen jQuery und JavaScript?

JavaScript ist die Programmiersprache, die der Browser ausführt; jQuery ist eine Bibliothek, die in dieser Sprache geschrieben wurde. Beide stehen nicht als konkurrierende Optionen auf derselben Ebene. jQuery-Code wird als JavaScript ausgeführt, jeder $()-Aufruf ist nur eine kürzere Art, die native DOM-API des Browsers anzusprechen.

jQuery, erstmals 2006 veröffentlicht, entstand, um die DOM-, Event- und AJAX-Inkonsistenzen zu überbrücken, die den Internet Explorer und frühe Browser plagten. $('.btn') kapselt document.querySelectorAll('.btn'); $.ajax() kapselt XMLHttpRequest. Wenn Entwickler nach dem Unterschied zwischen jQuery und JavaScript suchen, meinen sie meist den Unterschied zwischen der jQuery-API und der nativen Browser-API, also genau die Gegenüberstellung, die dieser Leitfaden jQuery vs Vanilla JS nennt.

Die praktische Folge: Sie können alles, was jQuery tut, in reinem JavaScript ausdrücken, aber jQuery läuft nicht ohne JavaScript darunter. 2026 decken die nativen APIs (querySelector, addEventListener, fetch, classList, IntersectionObserver) ab, was jQuery einst abstrahierte, weshalb das Laden der 87KB-Bibliothek über der Sprache, aus der sie gebaut ist, heute optional statt notwendig ist.

#Wie ersetzt man jQuery durch Vanilla JavaScript?

Die ES2024-Spezifikation, vollständig unterstützt in Chrome 124+, Firefox 126+, Safari 17.4+ und Edge 124+, bietet native Alternativen für jedes gängige jQuery-Muster.

#DOM-Selektion

// 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');

// Scoped-Selektion (wie jQuery .find())
const navLinks = container.querySelectorAll('a.nav-link');

Wichtiger Unterschied: querySelectorAll gibt eine statische NodeList zurück, keine Live-Collection. Das ist tatsächlich sicherer, weil sich die Liste nicht unerwartet ändert, wenn der DOM mutiert.

#Event-Handling

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

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

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

// Event-Delegation (ersetzt .on() mit Selektor)
document.querySelector('.menu').addEventListener('click', (e) => {
  const item = e.target.closest('.menu-item');
  if (item) {
    // Menüelement-Klick behandeln
  }
});

Die Methode closest() ist das moderne Äquivalent zum delegierten Event-Matching von jQuery. Sie traversiert den DOM-Baum nach oben, um den nächsten Vorfahren zu finden, der einem Selektor entspricht.

#Klassen-Manipulation

// 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');

// Mehrere Klassen gleichzeitig
el.classList.add('active', 'highlighted', 'animate-in');
el.classList.remove('hidden', 'collapsed');

#AJAX mit fetch API und 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 (modernes async/await)
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('Laden der Beiträge fehlgeschlagen:', error);
  }
}

// POST mit Nonce (WordPress-Muster)
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();
}

#Animationen ohne jQuery

jQuerys .fadeIn(), .slideDown() und .animate() können durch CSS-Transitions, CSS-Animationen oder die Web Animations API ersetzt werden.

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

// CSS-Ansatz (bevorzugt für Performance)
// In CSS:
// .panel { max-height: 0; overflow: hidden; transition: max-height 0.3s ease; }
// .panel.open { max-height: 500px; }

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

// Web Animations API (für komplexe, programmatische Animationen)
modal.animate(
  [
    { opacity: 0, transform: 'scale(0.95)' },
    { opacity: 1, transform: 'scale(1)' },
  ],
  { duration: 200, easing: 'ease-out', fill: 'forwards' }
);

Die Web Animations API läuft auf dem Compositor-Thread, was bedeutet, dass Animationen den Haupt-Thread nicht blockieren. jQuery-Animationen laufen auf dem Haupt-Thread und verursachen Jank auf langsameren Geräten.

#DOM-Manipulation

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

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

// Oder insertAdjacentHTML für HTML-Strings verwenden
container.insertAdjacentHTML('beforeend', '<div class="notice">Hallo</div>');

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

// Entfernen
item.remove();

// Leeren
list.replaceChildren();

#Document ready

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

// Vanilla JS
document.addEventListener('DOMContentLoaded', () => {
  // DOM ist bereit
});

// Oder platziere dein <script>-Tag mit type="module" am Ende des <body>
// Module werden standardmäßig deferred, sodass der DOM bereits bereit ist

#Wie ersetzt man jQuery-Plugins durch Web Components in WordPress?

jQuery-Plugins boten wiederverwendbare UI-Komponenten (Slider, Modals, Tabs, Akkordeons). 2026 bieten Web Components eine standardbasierte Alternative mit besserer Kapselung.

#Beispiel: eine Toggle-Panel-Komponente

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

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

    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);

Verwendung in HTML:

<toggle-panel title="Versandinformationen">
  <p>Kostenloser Versand bei Bestellungen über 50 EUR.</p>
</toggle-panel>

Web Components bieten Shadow-DOM-Kapselung (Styles lecken nicht nach aussen), Slots für Content-Projektion und Lifecycle-Callbacks. Sie funktionieren in jedem modernen Browser ohne Polyfills.

#Wann Web Components vs. ein Framework verwenden

SzenarioEmpfehlung
Einfaches interaktives Widget (Akkordeon, Tabs, Modal)Web Component
Vollständige SPA (Single Page Application)React / Vue / Svelte
WordPress-Block (Gutenberg)React (WordPress-Standard)
Geteilte Komponente über mehrere WebsitesWeb Component
Komplexes State ManagementFramework mit State-Bibliothek

#jQuery aus WordPress entfernen, Schritt für Schritt

#Schritt 1: jQuery-Nutzung prüfen

Führen Sie diesen Befehl in Ihrem Theme-Verzeichnis aus, um alle jQuery-Referenzen zu finden:

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

Kategorisieren Sie jede Nutzung:

  • Ihr Code (Theme/eigenes Plugin): migrieren Sie das
  • Drittanbieter-Plugin: lassen Sie es, das Plugin verwaltet seine eigenen Abhängigkeiten
  • WordPress-Admin: nicht anfassen, der WordPress-Core kümmert sich darum

#Schritt 2: Migrationsplan erstellen

Priorisieren Sie nach Auswirkung:

  1. Frontend-Theme-Code (betrifft jeden Besucher) - zuerst migrieren
  2. Eigenes Plugin-Frontend - als zweites migrieren
  3. Admin-Anpassungen - zuletzt migrieren (weniger Traffic)

#Schritt 3: Muster schrittweise ersetzen

Schreiben Sie nicht alles auf einmal um. Ersetzen Sie eine Datei nach der anderen:

  1. Entfernen Sie array('jquery') aus dem Abhängigkeits-Array der Datei in wp_enqueue_script
  2. Ersetzen Sie alle jQuery-Muster durch Vanilla-JS-Äquivalente
  3. Testen Sie in Chrome, Firefox, Safari und Edge
  4. Testen Sie mit allen aktiven Plugins
  5. Führen Sie Lighthouse vorher und nachher aus, um die Verbesserung zu messen

#Schritt 4: Das WordPress-AJAX-Muster behandeln

WordPress Legacy-AJAX verwendet admin-ajax.php mit jQuery:

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

// Modernes Muster (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();
}

Der REST-API-Ansatz ist schneller (kein admin-ajax.php-Overhead), besser cachebar und folgt modernen WordPress-Entwicklungsstandards.

#Schritt 5: Scripts korrekt einbinden

// Vorher (mit jQuery-Abhängigkeit)
wp_enqueue_script(
  'my-theme-scripts',
  get_template_directory_uri() . '/js/main.js',
  array('jquery'),
  '1.0.0',
  true
);

// Nachher (ohne jQuery, mit Modul-Unterstützung)
wp_enqueue_script_module(
  'my-theme-scripts',
  get_template_directory_uri() . '/js/main.js',
  array(),
  '2.0.0'
);

WordPress 6.5+ unterstützt wp_enqueue_script_module(), das Scripts als ES-Module mit type="module" lädt und native import/export-Syntax ermöglicht.

#Wann man jQuery in WordPress behalten sollte

jQuery kann weiterhin gerechtfertigt sein, wenn:

  • Legacy-Codebasis mit über 50 jQuery-Plugin-Abhängigkeiten: Die Migrationskosten übersteigen den Performance-Gewinn. Planen Sie ein schrittweises Auslaufen über 6-12 Monate.
  • WordPress-Admin-Anpassungen: Der Admin-Bereich lädt jQuery bereits. Eigene Admin-Scripts mit jQuery-Abhängigkeit hinzuzufügen kostet nichts extra.
  • Anforderungen von Drittanbieter-Plugins: Einige beliebte Plugins (bestimmte Formular-Builder, Page-Builder) erfordern jQuery. Kämpfen Sie nicht gegen die Abhängigkeit, wenn Sie sie nicht kontrollieren können.
  • Wissenslücken im Team: Wenn Ihr Entwicklungsteam nicht vertraut mit modernem JS ist, investieren Sie in Schulung vor einer erzwungenen Migration. Das Verständnis dessen, was ein WordPress-Entwickler tut, hilft dabei, realistische Erwartungen an die während der Migration benötigten Fähigkeiten zu setzen.

Das Ziel ist pragmatische Verbesserung, nicht ideologische Reinheit. Entfernen Sie jQuery dort, wo es Performance kostet und keinen Mehrwert bietet. Behalten Sie es dort, wo das Entfernen Dinge kaputt machen oder mehr kosten würde, als es einspart.

#Häufige JQMIGRATE-Fehler in WordPress und wie man sie behebt

Beim Debuggen einer WordPress-Seite in 2026 erscheinen in der Konsole fast immer Warnungen von jquery-migrate. Die häufigsten: Breiteres Hardening (WAF, Login, Plugins) steht im WordPress-Sicherheitshärtungsleitfaden.

#JQMIGRATE: jQuery.fn.on() event shorthand is deprecated

Vollständiger Text in der Browserkonsole:

JQMIGRATE: jQuery.fn.on() event shorthand is deprecated

Das erscheint, wenn ein Skript eine Event-Kurzform nutzt, die der Migrate-Shim zur Entfernung markiert hat (klassisches Muster: .bind(), .live() oder ein Event-Name als Methode). Die Korrektur ist ein explizites .on() oder schlichtes addEventListener. Beispiel: $el.click(handler) wird zu $el.on('click', handler), und $(document).on('click', '.selector', handler) ist die moderne Delegation. Sobald alle Aufrufe explizit sind, können Sie jquery-migrate mit wp_deregister_script('jquery-migrate') abmelden oder WordPress es fallen lassen, wenn kein Skript es mehr als Abhängigkeit meldet.

#JQMIGRATE: jQuery.fn.on is deprecated

Eine leicht andere Formulierung derselben Familie. Sie zeigt meist auf ein Plugin oder Theme, das jQuery.fn.on patcht, oder auf einen Migrate-Build, der eine bestimmte Signatur markiert. Die Lösung ist dieselbe: Aufrufer prüfen, Kurzformen durch .on() oder addEventListener ersetzen, den Shim entfernen, wenn die Konsole ruhig ist.

#Ist jQuery 2026 noch relevant?

Für neue WordPress-Themes und -Plugins nein; für die Pflege großer bestehender Codebasen manchmal. jQuery ist immer noch auf einem großen Teil des Webs präsent, aber diese Präsenz ist Trägheit, keine Notwendigkeit.

Bei Neuentwicklungen gibt es 2026 keinen technischen Grund, jQuery hinzuzufügen. Jedes Muster, das es bietet, hat ein natives Äquivalent, das der Browser mitbringt, und das aktuelle WordPress-Tooling startet Sie mit null jQuery: Block-Themes rendern ohne es, das create-block-Gerüst und wp-scripts bauen auf React auf, und Vite-basierte Setups ziehen nichts jQuery-Ähnliches nach. Der WordPress-Core bündelt weiterhin jQuery 3.7.1 aus Gründen der Rückwärtskompatibilität, und der Block-Editor läuft auf React statt auf jQuery.

Relevanz überlebt in der Wartung, nicht in neuer Architektur. Ein Legacy-Theme mit Dutzenden jQuery-abhängigen Plugins, ein Page-Builder, der es zwingend voraussetzt, oder reine Admin-Skripte, in denen jQuery bereits geladen ist, das sind alles Fälle, in denen es weniger kostet, es zu behalten, als es zu entfernen. Die ehrliche Antwort für 2026: jQuery ist relevant wie eine tragende Wand in einem alten Gebäude. Sie arbeiten darum herum, aber Sie fügen nicht mehr davon hinzu.

#Native JavaScript-Alternativen zu jQuery-Utilities

#Strukturierter Klon (Deep Copy)

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

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

#Array-ähnliche Iteration

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

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

// Oder mit Array.from für NodeLists
Array.from(document.querySelectorAll('.item')).map(item => item.textContent);

// Oder Spread-Operator
[...document.querySelectorAll('.item')].filter(item => item.dataset.active);

#Deferred/Promise-Muster

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

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

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

#IntersectionObserver (ersetzt jQuery-Scroll-Handler)

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

// Vanilla JS (performant, außerhalb des Haupt-Threads)
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));

#Welche JavaScript-Bibliotheken neben jQuery Sie entfernen können

jQuery ist selten die einzige Abhängigkeit, die der Browser bereits ersetzt. Jad Joubran beschreibt im Smashing Magazine (7. August 2026) ein Abhängigkeits-Audit nach Gruppen und schätzt, dass in einer typischen mittelgroßen Anwendung 60 bis 90 KB (gzip) Bibliothekscode zur Plattform zurückwandern können. Für jede Bibliothek stellt er drei Fragen: Ist die native Funktion für Ihr tatsächliches Publikum Baseline, was kostet der Wechsel einschließlich eines Polyfills, und deckt die native Funktion ab, wie Sie die Bibliothek wirklich nutzen?

GruppeBibliothekenNativer Ersatz
Relative Datumsangaben, Zahlen, Pluraltimeago.js, pluralize, numeral, humanize-durationIntl.RelativeTimeFormat, Intl.PluralRules, Intl.NumberFormat, Intl.DurationFormat, Intl.ListFormat
HTTP-Anfragenaxios, superagentfetch mit AbortController und AbortSignal.timeout()
Dialoge, Tooltips, Fokusfallena11y-dialog, tippy.js, focus-trap, body-scroll-lock<dialog>, Popover API, CSS Anchor Positioning, body:has(dialog:modal)
Lodash-Funktionenlodash, lodash.clonedeep, lodash.groupbyObject.groupBy, Map.groupBy, structuredClone, native Set-Methoden

Der Wechsel hat Grenzen. fetch lehnt bei HTTP-Fehlern nicht ab und hat weder Interceptors noch Wiederholungen oder Upload-Fortschritt. Lodash hat kein natives debounce oder throttle, lodash.debounce darf also bleiben. structuredClone kopiert weder Funktionen noch DOM-Knoten. Datumsangaben zeigen, wann die Bibliothek bleiben sollte: Temporal ist noch nicht Baseline, und sein Polyfill wiegt 44 KB, ein Ersatz für dayjs (etwa 3 KB) würde also Code hinzufügen statt ihn zu entfernen.

In einem WordPress-Theme oder -Plugin listet npm ls --omit=dev --depth=0 die Produktionsabhängigkeiten auf, Bundlephobia zeigt ihre Größe, und das Paket web-features, webstatus.dev oder die Baseline-Kennzeichnungen auf MDN zeigen den Status einer Funktion.

#Leichte jQuery-Alternativen wie Alpine.js und htmx

Wenn Sie dieselben Vanilla-JS-Muster immer wieder schreiben, ziehen Sie eine Micro-Library statt jQuery in Betracht:

BibliothekGrösseZweck
Alpine.js15KBDeklarative Reaktivität (x-data, x-on)
htmx14KBAJAX, WebSocket, SSE über HTML-Attribute
Petite-Vue6KBVue-kompatible Template-Syntax
Keine (Vanilla)0KBBeste Performance, volle Kontrolle

Für WordPress-Themes 2026 ist die Empfehlung Vanilla JS für einfache Interaktionen und Alpine.js oder htmx, wenn Sie deklaratives Verhalten ohne volles Framework benötigen.

#jQuery best practices in 2026

Wenn Sie noch jQuery-Code pflegen - ob aus eigener Wahl oder weil eine Legacy-Codebasis es erfordert - minimieren diese Praktiken den Schaden:

  1. Laden Sie jQuery aus dem WordPress-Core, niemals von einem CDN. WordPress bündelt eine kompatible Version. Eine zweite Kopie von cdnjs oder code.jquery.com zu laden bedeutet doppeltes Gewicht und potenzielle Versionskonflikte.
  2. Verwenden Sie jQuery statt $ in WordPress. WordPress führt jQuery im No-Conflict-Modus aus. Code in jQuery(function($) { ... }) zu wrappen verhindert Kollisionen mit anderen Bibliotheken.
  3. Vermeiden Sie verschachteltes .ready(). Ein einziges jQuery(function($) { ... }) reicht aus. Verschachtelte .ready()-Aufrufe erzeugen Callback-Pyramiden und verwirren die Ausführungsreihenfolge.
  4. Cachen Sie Selektoren. Jeder $('.my-class')-Aufruf durchläuft den DOM. Speichern Sie Ergebnisse in einer Variablen, wenn Sie denselben Selektor mehr als einmal verwendest.
  5. Delegieren Sie Events statt sie an einzelne Elemente zu binden. Verwenden Sie $(parent).on('click', '.child', handler) statt $('.child').click(handler). Das behandelt dynamisch hinzugefügte Elemente und verwendet weniger Event-Listener.
  6. Verwenden Sie jQuery nicht für CSS-Animationen. Verwenden Sie CSS-Transitions oder die Web Animations API. jQuerys .animate() läuft auf dem Haupt-Thread und verursacht Jank.
  7. Setzen Sie jquery als Abhängigkeit nur wenn nötig. Wenn eine Script-Datei jQuery nicht verwendet, entfernen Sie es aus dem Abhängigkeits-Array von wp_enqueue_script, um unnötiges Laden von jQuery zu vermeiden.

#Aktuelle jQuery-Version 2026 und jQuery 4

Stand 2026 ist jQuery 3.7.1 die neueste stabile Version (veröffentlicht im August 2023). jQuery 4.0.0-beta.2 befindet sich seit Februar 2024 in der Beta-Phase, ohne angekündigtes stabiles Release-Datum.

jQuery-4.0-Änderungen, die für WordPress relevant sind:

ÄnderungAuswirkung
Lässt IE-11-Support fallenKein Effekt - WordPress 6.6+ hat IE 11 bereits abgeschafft
Entfernt veraltete APIs (.click(), .bind(), .delegate())Plugins, die diese verwenden, werden nicht mehr funktionieren
Kleineres Bundle (~68KB vs 87KB)Bescheidene Verbesserung, immer noch schwerer als kein jQuery
FormData-basiertes $.ajax() für Datei-UploadsSchöneres API, aber fetch() kann das nativ

Der WordPress-Core liefert derzeit jQuery 3.7.1 aus und hat sich nicht verpflichtet, Version 4.0 zu bündeln. Die praktische Erkenntnis: Warten Sie nicht auf jQuery 4, um die Performance zu verbessern. Migrieren Sie zu Vanilla JS wo möglich und verwenden Sie jQuery-3.7.1-Best-Practices dort, wo eine Migration noch nicht machbar ist.

#Wer verwendet jQuery noch in 2026

jQuery wird auf geschätzten 77% aller Websites geladen (laut W3Techs), hauptsächlich weil WordPress, Shopify und Legacy-Enterprise-Websites es standardmäßig einbinden. Aber “geladen” bedeutet nicht “benötigt”.

Die Aufschlüsselung:

  • WordPress-Websites: jQuery wird auf praktisch jeder WordPress-Seite geladen, weil die Admin-Bar und viele beliebte Plugins davon abhängen. Im Frontend ist die tatsächliche Abhängigkeit oft nur ein oder zwei Scripts.
  • Shopify-Themes: Die meisten Shopify-Themes bündeln jQuery für Warenkorb-Interaktionen. Shopify hat keine Pläne, es abzuschaffen.
  • Legacy-Enterprise-Systeme: Banken, Regierungsportale und große E-Commerce-Plattformen haben oft jQuery in Codebasen eingebettet, die aus den Jahren 2010-2015 stammen. Migration ist teuer und hat niedrige Priorität.
  • Neue Projekte: Fast keine. React, Vue, Svelte und Vanilla JS dominieren die Neuentwicklung. Kein modernes Framework oder Starter-Template enthält jQuery.

Wenn Sie 2026 ein neues WordPress-Theme oder -Plugin beginnen, gibt es keinen Grund, jQuery als Abhängigkeit hinzuzufügen. Die Browser-APIs reichen für jedes gängige Muster aus. Mehr zum richtigen Erstellen von Plugins finden Sie im Abschnitt WordPress-Plugin-Best-Practices in unserem Plugin-Stack-Leitfaden.

#Checkliste für die Migration von jQuery zu Vanilla JS

  1. Prüfen Sie die gesamte jQuery-Nutzung in Ihrem Theme und eigenen Plugins
  2. Messen Sie die aktuellen Core Web Vitals als Referenzwert
  3. Ersetzen Sie den Frontend-Theme-Code zuerst (grösster Besuchereinfluss)
  4. Verwenden Sie querySelector, addEventListener, fetch, classList und Web Animations API
  5. Ziehen Sie Web Components für wiederverwendbare UI-Elemente in Betracht
  6. Verwenden Sie wp_enqueue_script_module() für ES-Modul-Unterstützung
  7. Testen Sie in allen großen Browsern nach jeder Dateimigration
  8. Messen Sie die Core Web Vitals erneut und dokumentieren Sie die Verbesserung
  9. Behalten Sie jQuery nur für Admin-Scripts und Drittanbieter-Plugin-Abhängigkeiten
  10. Schulen Sie Ihr Team in modernen JavaScript-Mustern

Die Web-Plattform 2026 bietet alles, was jQuery bot, und mehr. Jedes Kilobyte unnötiges JavaScript, das Sie entfernen, macht Ihre WordPress-Website schneller, barrierefreier und einfacher zu warten.

Steckt das jQuery in einem Theme oder Plugin, das jemand anderes geschrieben hat, ist das genau die Arbeit an übernommenem Code, die ich als Softwareentwickler mache: Repository und eine Liste der Seiten, die weiter funktionieren müssen, reichen, und der erste Schritt ist eine Prüfung jedes jQuery-Aufrufs, keine Neuentwicklung.

Nächster Schritt

Machen Sie aus dem Artikel eine echte Umsetzung

Dieser Block stärkt die interne Verlinkung und führt Nutzer gezielt zum nächsten sinnvollen Schritt im Service- und Content-System.

Soll das Thema auf Ihrer Website umgesetzt werden?

Wenn Sie Headless WordPress, Frontend-Entkopplung oder eine Migration zu Astro planen, übernehme ich Architektur, WP-API und das Frontend.

Häufig gestellte Fragen

Praktische Antworten zur Umsetzung des Themas.

Was ist der Unterschied zwischen jQuery und JavaScript?#
JavaScript ist die Programmiersprache, die Browser nativ ausführen; jQuery ist eine in JavaScript geschriebene Bibliothek, die DOM-, Event- und AJAX-Operationen eine kürzere, browserübergreifende Syntax gibt. Beide sind keine Alternativen auf derselben Ebene: jQuery läuft auf JavaScript auf, daher ist jede jQuery-Methode (wie $('.btn')) ein Wrapper um eine native API (document.querySelectorAll('.btn')). Sie können alles, was jQuery tut, in reinem JavaScript umsetzen, aber jQuery läuft nicht ohne JavaScript darunter.
Ist jQuery 2026 noch relevant?#
Für neue WordPress-Projekte nein. Jedes jQuery-Muster hat ein natives Browser-Äquivalent (querySelector, addEventListener, fetch, classList), und das aktuelle WordPress-Tooling (Block-Themes, das create-block-Gerüst, wp-scripts) startet mit null jQuery. Relevant bleibt es nur für die Wartung: Legacy-Themes mit vielen jQuery-abhängigen Plugins, Page-Builder, die es zwingend voraussetzen, oder Admin-Skripte, in denen WordPress es bereits lädt. Der WordPress-Core bündelt weiterhin jQuery 3.7.1 zur Rückwärtskompatibilität, aber der Block-Editor verwendet React, nicht jQuery.
Brauche ich jQuery 2026 noch für die meisten WordPress-Frontend-Aufgaben?#
Nein. Moderne Browser unterstützen querySelector, addEventListener, classList, fetch, IntersectionObserver und die Web Animations API nativ. WordPress 6.7+ enthält eine jQuery-Kompatibilitätsschicht, ermutigt Entwickler aber, in neuem Code Vanilla JS zu verwenden.
Was ist der sicherste Weg, um von jQuery in WordPress zu migrieren?#
Verwenden Sie einen schrittweisen Ansatz: Prüfen Sie, welche Skripte von jQuery abhängen, ersetzen Sie zuerst die einfachsten Muster (Selektoren, Klassen-Toggles, Klick-Handler), testen Sie jede Änderung im Browser und entfernen Sie die jQuery-Abhängigkeit aus wp_enqueue_script erst, wenn der gesamte Code in einer Datei migriert ist.
Verbessert das Entfernen von jQuery die Core Web Vitals?#
Ja. Das Entfernen von jQuery eliminiert 87KB unkomprimiertes JavaScript (30KB gzipped), reduziert die Total Blocking Time (TBT) und verbessert Interaction to Next Paint (INP). In Benchmarks laden Seiten ohne jQuery 200-400ms schneller auf Mobilgeräten.
Können Web Components jQuery-Plugins ersetzen?#
Für viele Anwendungsfälle ja. Web Components bieten gekapselte, wiederverwendbare UI-Elemente mit Shadow DOM, benutzerdefinierten Events und Lifecycle-Callbacks. Sie funktionieren nativ in allen modernen Browsern ohne Bibliotheksabhängigkeit.
Hängt der WordPress-Core noch von jQuery ab?#
Der WordPress-Core reduziert aktiv jQuery-Abhängigkeiten. Der Block-Editor (Gutenberg) verwendet React, nicht jQuery. Allerdings laden der Admin-Bereich und viele Legacy-Plugins noch jQuery. Die WordPress 7.x-Roadmap beinhaltet weitere jQuery-Reduzierung.
Was sind die jQuery best practices in 2026?#
Verwenden Sie jQuery aus dem WordPress-Core (niemals von einem CDN), cachen Sie Selektoren, delegieren Sie Events, vermeiden Sie jQuery für Animationen (verwenden Sie stattdessen CSS-Transitions), verwenden Sie jQuery im No-Conflict-Modus und deklarieren Sie jquery nur dann als Script-Abhängigkeit, wenn die Datei es tatsächlich verwendet.
Was ist die neueste jQuery-Version in 2026?#
jQuery 3.7.1 ist die neueste stabile Version (August 2023). jQuery 4.0.0-beta.2 befindet sich seit Februar 2024 in der Beta-Phase, ohne angekündigtes stabiles Release-Datum. Der WordPress-Core liefert jQuery 3.7.1 aus.
Wer verwendet jQuery noch in 2026?#
jQuery wird auf etwa 77% aller Websites geladen, hauptsächlich weil WordPress, Shopify und Legacy-Enterprise-Websites es standardmäßig einbinden. Allerdings fügen fast keine neuen Projekte jQuery als Abhängigkeit hinzu. React, Vue, Svelte und Vanilla JS dominieren die Neuentwicklung.

Sie brauchen ein FAQ für Branche und Zielmarkt? Ich erstelle eine Version passend zu Ihren Business-Zielen.

Kontakt aufnehmen

Ähnliche Artikel