jQuery-Migrate aus dem WordPress-Frontend entfernen — ohne den Admin zu brechen (2026).
Lighthouse meckert jquery-migrate.min.js als Render-Blocker an? Plugin-Lösungen entfernen es überall und brechen Gutenberg. So entfernst du es chirurgisch nur im Frontend — mit Code-Snippet, Auto-Safety-Check und 2026er Reality-Check.
jQuery-Migrate aus dem WordPress-Frontend entfernen — ohne den Admin zu brechen (2026).
Lighthouse meldet auf rund 70 % aller WordPress-Sites jquery-migrate.min.js als Top-Hit im Audit „Reduce unused JavaScript". Die Browser-Console wirft auf jeder Page das gleiche Notice: JQMIGRATE: Migrate is installed, version 3.4.x. Und auf einem ehrlichen Mobile-3G-Test summiert sich der Parse-Cost dieser Bibliothek auf 50 bis 150 ms — für Code, den WordPress-Core seit August 2020 nicht mehr braucht.
Die gängige Antwort auf das Problem lautet: „Installier das Plugin Disable jQuery Migrate" oder „nimm Perfmatters und klick den Toggle". Beide Lösungen entfernen Migrate dann allerdings überall — auch im wp-admin. Das wiederum bricht Gutenberg-Custom-Blöcke, den älteren Elementor-Editor und ein paar Dutzend andere Page-Builder-Admin-UIs, die noch auf jQuery-1.x-Syntax bauen. Du gewinnst 11 KB im Frontend und verlierst dafür die Hälfte deines Editors.
Dieser Post zeigt dir den chirurgischen Mittelweg: ein Code-Snippet, das Migrate nur im Frontend entfernt und im Admin aktiv lässt. Lighthouse-Score-Boost ohne Editor-Risiko. Vier Minuten Setup, kein Plugin.
TL;DR — Migrate in 4 Minuten sicher aus dem Frontend entfernen
- Frontend-only: Der Snippet aus der Smart-Fix-Library hängt sich in
wp_default_scriptsund entferntjquery-migrateaus den jQuery-Dependencies — aber nur auf öffentlichen Seiten. Im Admin bleibt alles unverändert.- Auto-Safety-Check: das Snippet erkennt aktive Versionen von „Disable jQuery Migrate" oder Perfmatters und macht in dem Fall ein No-op. Doppel-Konfigurationen ausgeschlossen.
- Wirkung: 11 KB weniger Frontend-JS, keine
JQMIGRATE-Console-Warnings, Lighthouse-Mobile-Score plus 2 bis 5 Punkte. Editor-Erfahrung im wp-admin unangetastet.
Was jQuery-Migrate ist und warum es 2026 noch da ist
jQuery-Migrate ist eine Brücken-Bibliothek, die das jQuery-Team 2013 zusammen mit jQuery 1.9 veröffentlicht hat. Ihr Zweck: APIs, die in jQuery 1.9 entfernt wurden, weiter aufrufbar machen — damit Plugin- und Theme-Code, der noch jQuery 1.6 oder 1.7 voraussetzt, nicht stillschweigend brechen muss.
Die häufigsten Patches:
| Veraltete API | Migrate emuliert |
|---|---|
$.browser (UA-Sniffing) |
gibt 2026 oft falsche Werte zurück, läuft aber durch |
$.live() (Event-Binding) |
wird intern auf $.on() umgeleitet |
.size() (Element-Count) |
wird zu .length |
.toggle(handler1, handler2) |
alte Zwei-Funktionen-Signatur |
$.fn.attr() mit null-Default |
Migrate liefert das alte Verhalten |
WordPress liefert Migrate seit Version 3.6 (2013) standardmäßig mit. Bis WordPress 5.5 (August 2020) lief im Core noch jQuery 1.12 — Migrate war an dieser Stelle für viele Themes echte Pflicht. Mit 5.5 sprang der Core auf jQuery 3.5, und mit den späteren 5.6er-Releases auf 3.6. Seit dem Sprung sind sechs Jahre vergangen. Sechs Jahre, in denen Theme- und Plugin-Autoren Zeit hatten, ihren Code anzupassen.
Trotzdem lädt WordPress Migrate weiterhin automatisch als jQuery-Dependency — in jedem Frontend, auf jeder Page. Der Grund ist konservativ: WordPress will keine Sites brechen, die noch von einem 2018er Theme leben. Die Folge: 80 % aller WordPress-Sites schleppen 11 KB toten Code mit sich, weil 20 % der Sites ihn theoretisch noch brauchen könnten.
Symptome auf deiner Site
Du weißt, dass dich Migrate betrifft, wenn du eines davon siehst:
- Browser-Console im Frontend zeigt
JQMIGRATE: Migrate is installed, version 3.4.x with logging active— auf jeder Page, schon vor jedem Klick. - Lighthouse-Audit (Chrome DevTools → Lighthouse → Performance) im Bereich „Reduce unused JavaScript" listet
jquery-migrate.min.jsals einen der Top-3-Einträge. - PageSpeed-Insights (web.dev/measure) zeigt unter „Diagnostics" denselben Eintrag mit konkretem Transfer-Saving („Potential savings of 11 KiB").
- DevTools Network-Tab im Frontend gefiltert auf
jquery: zwei Einträge,jquery.min.jsundjquery-migrate.min.js, beide blocking im<head>geladen. - WP-Theme-Inspector-Tools (Query Monitor) zeigen jQuery + Migrate als zwei separate registrierte Scripts mit Dependencies-Kette.
Auf reinen Marketing-Sites ohne komplexe Interaktion summiert sich der Performance-Verlust auf 50–150 ms Parse-Cost pro Page-Load. Auf E-Commerce-Sites mit dichten Frontend-Skripten potenziert es sich: Migrate konkurriert mit jedem anderen JS-Block um die Main-Thread-Zeit des Browsers.
Reality-Check 2026: brauchst du Migrate überhaupt noch?
Die Frage, die in fast keinem Tutorial ehrlich beantwortet wird, lautet: wofür ist diese Bibliothek 2026 noch da? Drei mögliche Antworten, alle drei kommen in der Praxis vor:
Antwort 1 — stille Patches für veralteten Theme-/Plugin-Code.
Wenn dein Theme oder ein aktives Plugin noch $.browser, $.live(), .size() oder die alte .toggle()-Signatur nutzt, bricht JavaScript ohne Migrate. Das passiert in der Praxis bei Themes, die zuletzt vor 2020 ein ernsthaftes Update bekommen haben — also bei einer ehrlichen Schätzung 15 bis 25 % aller WordPress-Sites im DACH-Raum.
Antwort 2 — Console-Warnings als Diagnose-Tool.
Migrate gibt im WP_DEBUG-Modus präzise Warnungen aus, sobald veralteter Code aufgerufen wird (JQMIGRATE: jQuery.browser is deprecated). Das ist paradoxerweise oft wertvoller als der Patch selbst — du erfährst, wo der veraltete Code sitzt. Für Entwickler ist Migrate damit ein Audit-Tool, nicht primär eine Bridge.
Antwort 3 — historische Vorsicht des WordPress-Core-Teams. Migrate würde nicht weiter automatisch geladen werden, wenn das Core-Team nicht 2020 entschieden hätte: lieber 11 KB Ballast für alle als eine kleine Anzahl gebrochener Legacy-Sites. Diese Entscheidung ist sechs Jahre alt. Sie ist defensiv, nicht performance-orientiert.
Konsequenz für deine Site:
- Wenn dein Theme nach Mitte 2020 weiterentwickelt wurde und alle aktiven Plugins regelmäßige Updates bekommen → Migrate raus aus dem Frontend ist mit hoher Wahrscheinlichkeit No-op. Effekt: Score-Boost, keine Funktions-Verluste.
- Wenn dein Theme seit 2019 keinen Major-Release mehr hatte → Migrate ist das Pflaster, das den Theme-Code zusammenhält. Migrate-Removal würde das Symptom angehen, das veraltete Theme bliebe das eigentliche Problem.
- Wenn du es nicht weißt → Snippet im Staging testen, alle Frontend-Funktionen durchklicken (Slider, Cookie-Banner, AJAX-Filter, Custom-Forms). Bricht etwas, hast du eine echte Migrate-Abhängigkeit.
Die Frontend-only-Strategie macht den Test fair: im Admin bleibt Migrate aktiv, du riskierst nicht den Editor. Bricht nur das Frontend, kannst du den Snippet in 30 Sekunden wieder rausnehmen.
Frontend-only vs. Plugin-Total-Off — warum chirurgisch besser ist
Die drei populären Lösungen im DACH-Markt machen alle den gleichen Fehler: sie unterscheiden nicht zwischen Frontend und Admin.
Plugin Disable jQuery Migrate (WordPress.org, ~200.000 aktive Installs): Deregistriert Migrate global. Im Frontend und im Admin. Drei Zeilen Code, kein Auto-Safety-Check, keine Kontext-Logik. Risiko: ältere Gutenberg-Custom-Blöcke und Page-Builder-Admin-UIs brechen.
Perfmatters (Premium-Plugin, ~50.000 aktive Installs): Hat einen Toggle „Disable jQuery Migrate". Wirkt identisch zum Free-Plugin oben — global an oder global aus. Differenziert nicht nach Kontext.
WP Rocket (Premium, ~3 Millionen aktive Installs): Hat keine eigene Migrate-Option. Wenn du Migrate raus haben willst, kombinierst du WP Rocket mit Disable jQuery Migrate oder Perfmatters — und landest wieder beim Total-Off-Problem.
Der Snippet aus der Smart-Fix-Library macht es anders:
add_action( 'wp_default_scripts', function( $scripts ) {
if ( is_admin() ) {
return; // im Admin bleibt Migrate aktiv
}
if ( ! empty( $scripts->registered['jquery'] ) ) {
$deps = $scripts->registered['jquery']->deps;
$scripts->registered['jquery']->deps = array_diff(
(array) $deps,
array( 'jquery-migrate' )
);
}
}, 1, 1 );
Der Filter hakt sich in wp_default_scripts ein, prüft is_admin() und greift nur im Frontend ein. Migrate wird aus der Dependencies-Kette von jQuery entfernt, der zweite registrierte Script-Eintrag bleibt ungeladen, das <script>-Tag im Header verschwindet.
Im wp-admin läuft Migrate dagegen unverändert weiter. Gutenberg-Blöcke, Elementor-Editor, Divi-Builder — alle bekommen das gewohnte jQuery-1.x-Verhalten.
Das vollständige Snippet aus der Library
Der Kern oben sind acht Zeilen. Das vollständige Snippet aus der Smart-Fix-Library hat zwei zusätzliche Komponenten, die in Production wichtig sind:
Komponente 1 — Auto-Safety-Check.
Der Snippet liest active_plugins und prüft auf zwei konkurrierende Lösungen:
$wf_active = (array) get_option( 'active_plugins' );
foreach ( array(
'disable-jquery-migrate/disable-jquery-migrate.php',
'perfmatters/perfmatters.php',
) as $wf_skip ) {
if ( in_array( $wf_skip, $wf_active, true ) ) {
if ( defined( 'WP_DEBUG' ) && WP_DEBUG ) {
error_log( 'WebsiteFix Smart-Fix [jquery-migrate]: skipped — handled by ' . $wf_skip . '.' );
}
return;
}
}
Findet er eines der beiden aktiv, bricht der Snippet sofort mit return ab. Im WP_DEBUG-Modus erscheint ein Log-Eintrag, im Production-Mode passiert lautlos nichts. Du läufst nie in Doppel-Konfigurationen, die sich gegenseitig überschreiben — auch wenn ein Team-Mitglied später eines der Plugins installiert.
Komponente 2 — script_loader_tag-Filter als Backup.
Falls ein anderes Plugin Migrate-Output nachträglich wieder ins Frontend rendert, fängt ein zweiter Filter den Output ab und liefert einen leeren Tag zurück:
add_filter( 'script_loader_tag', function( $tag, $handle ) {
if ( 'jquery-migrate' === $handle && ! is_admin() ) {
return '';
}
return $tag;
}, 10, 2 );
Das ist Defense-in-Depth: selbst wenn ein Drittanbieter-Plugin Migrate per Force-Enqueue zurückbringt, verschwindet das <script>-Tag im Frontend trotzdem aus dem HTML.
Warum überhaupt ein Snippet statt eines Plugins?
Drei Gründe: keine Update-Verantwortung gegenüber einem Plugin-Maintainer (Migrate-Patches sind seit 2019 quasi gefroren — kein Update-Bedarf), kein zusätzlicher Plugin-Slot in einer Site, die ohnehin schon zu viele lädt, und version-controlled im Child-Theme oder Code-Snippets-Plugin — bei Site-Migrationen wandert die Konfiguration automatisch mit.
Wann Migrate BEHALTEN — die drei Ausnahmen
Drei Szenarien, in denen du Migrate nicht rauswerfen solltest, oder zumindest sehr vorsichtig sein musst:
1. Theme von vor 2020 ohne aktiven Update-Plan. Wenn dein Theme zuletzt 2019 ein ernsthaftes Update bekommen hat, nutzt es mit hoher Wahrscheinlichkeit noch jQuery-1.x-Patterns. Migrate ist das Pflaster, das den Theme-Code zusammenhält. Lösung: Theme erst updaten oder ersetzen, dann Migrate raus. Das ist die ehrlichere Reihenfolge.
2. Custom-Code im Child-Theme oder in Custom-Scripts.
Du hast eigene jQuery-Snippets, die irgendwann mal von einem Freelancer kamen. $.browser, $.live(), .size() — wenn du diese Patterns im eigenen Code nutzt, fliegen JS-Errors, sobald Migrate weg ist. SSH-Test, der dir das verrät:
grep -rn '\$\.browser\|\$\.live(\|\.size()\|\$\.fn\.size' wp-content/themes/<dein-theme>
Findest du Treffer → Custom-Code modernisieren, dann Migrate raus.
3. Page-Builder-Versionen, die im Frontend rendern. Manche älteren Page-Builder (Visual Composer < 6, Themify < 5) generieren im Frontend-Output JavaScript-Hooks, die jQuery-1.x-Syntax voraussetzen. Builder-Updates lösen das in den meisten Fällen, aber wenn deine Lizenz abgelaufen ist und du auf einer alten Version festhängst: Migrate behalten, oder Builder zuerst updaten.
In allen drei Fällen ist die saubere Reihenfolge: Root-Cause fixen, dann Migrate raus. Der Snippet ist kein Vorwand, technische Schulden weiter zu verschieben.
Verifizieren: hat es geklappt?
Drei Tests, jeweils 30 Sekunden, vom schnellsten zum gründlichsten.
Test 1 — Browser-Console.
Öffne dein Frontend ohne Login. F12 → Console-Tab. Lade die Seite neu. Erwartung: kein JQMIGRATE: Migrate is installed-Eintrag mehr. Vor dem Snippet stand er auf jeder Page-Load oben drin, nach dem Snippet ist Console im Frontend Migrate-frei.
Logge dich jetzt ins wp-admin ein, öffne wieder F12 → Console. Im Admin sollte der JQMIGRATE-Eintrag weiterhin sichtbar sein. Falls ja: alles korrekt, das Snippet wirkt nur im Frontend.
Test 2 — DevTools Network-Tab.
F12 → Network → Filter auf jquery. Im Frontend lädt nur noch jquery.min.js, kein zweiter Eintrag mit migrate. Im Admin sind weiterhin beide Dateien zu sehen.
Test 3 — curl-HTML-Check. Im Terminal:
curl -s https://deine-site.de | grep -c 'jquery-migrate'
Erwartung: 0. Vor dem Snippet hätte da 1 oder 2 gestanden (je nachdem, wie viele Stellen die Migrate-Referenz hatten).
Test 4 — Lighthouse-Re-Audit.
Chrome → DevTools → Lighthouse → Mobile + Performance + Run. Im Diagnostics-Bereich „Reduce unused JavaScript" sollte der jquery-migrate.min.js-Eintrag verschwunden sein. Im Schnitt verbessert sich der Performance-Score um 2 bis 5 Punkte — auf Mobile-3G-Tests teilweise mehr.
Falls keiner der vier Tests die erwartete Wirkung zeigt: Caching-Layer (WP Rocket, LiteSpeed Cache, Cloudflare) leert nach dem Snippet-Apply, oder ein anderes Plugin schreibt Migrate über einen eigenen Force-Enqueue zurück. Im WP_DEBUG-Log nach dem Tag des Snippet-Apply schauen — der Auto-Safety-Check loggt, wenn er einen Konflikt sieht.
Erweiterte Strategie für Agenturen
Für Sie als Agentur multipliziert sich der Effekt mit jeder Kundensite. Beispiel-Rechnung für eine 30-Sites-Agentur, in der die meisten Themes nach 2020 entwickelt wurden:
| Kennzahl | Ohne Schnitt | Mit Frontend-Removal |
|---|---|---|
| Kundensites mit Theme nach 2020 | 30 | 30 |
| Frontend-JS-Transfer pro Page-Load | ø 30 KB unminified | ø 19 KB |
Render-blocking Scripts im <head> |
jQuery + Migrate | nur jQuery |
| Lighthouse-Mobile-Median | 78 | 82 |
| Console-Warnings beim SEO-Audit | 30 Sites × ja | 30 Sites × nein |
Bulk-Rollout-Empfehlung:
- MU-Plugin auf der Foundation. Der WebsiteFix One-Click Optimizer schreibt den Snippet als
mu-pluginins/wp-content/mu-plugins/-Verzeichnis. Greift netzwerk-weit, ohne dass jedes Kunden-Theme angefasst werden muss. Beim nächsten Theme-Update der Kundensite bleibt der Snippet trotzdem aktiv. - Erst auf einer Pilot-Site mit aktivem Theme testen. 24-Stunden-Fenster. Alle Frontend-Funktionen (Slider, Forms, AJAX-Filter, Cookie-Banner) durchklicken. Bricht nichts → Rollout.
- Monitoring in der WebsiteFix Agency-Konsole. Pro Site sehen Sie, ob Migrate noch im Frontend lädt, plus den Lighthouse-Verlauf vor und nach Snippet-Apply.
Pragmatischer Hinweis: bei den 15–25 % älteren Sites in jedem Agentur-Portfolio funktioniert der Snippet nicht ohne Theme-Modernisierung. Ehrliche Kommunikation gegenüber dem Kunden: „Wir können das Frontend deutlich beschleunigen, aber dafür muss das Theme zuerst auf eine aktuelle Version, weil sonst Funktionen brechen."
Weiterführend
Drei thematisch passende Anschluss-Lektüren, wenn dieser Post deinen Frontend-JS-Schmerz aufgelöst hat:
- Wenn Migrate raus ist: die nächsten Builder-Hebel — Page-Builder-Performance jenseits von jQuery, mit 8 konkreten Optimierungs-Knöpfen.
- Nach Frontend-JS die admin-ajax-Last reduzieren — Heartbeat-Drosselung als zweiter Hebel gegen TTFB und CPU-Druck im Backend.
- Alle 5 Snippets im Performance-Lab — der vollständige Smart-Fix-Katalog mit Heartbeat, jQuery-Migrate, Emojis, Query-Strings und XML-RPC.
Wenn du sofort messen willst, welche dieser Frontend-Hebel für DEINE Site den größten Effekt bringen: der 92-Punkt Deep-Audit liefert die individuelle Priorisierung in 60 Sekunden — ohne dass du ein Plugin installieren musst.
KI-Diagnose · Kostenlos · 60 Sekunden
Klingt nach deinem Problem?
WebsiteFix analysiert deine Website automatisch — technische Fehler UND warum keine Anfragen kommen. Ein Scan, konkrete Antworten.
Jetzt kostenlos scannen →Kostenlos · Keine Anmeldung · DSGVO-konform