10 Dinge, die du heute von deiner Website löschen kannst

Die mediane Webseite hat im Juli 2025 auf dem Desktop 697 KB JavaScript ausgeliefert und wog insgesamt 2,86 MB, laut dem HTTP Archive Web Almanac. Von diesem JavaScript hat die mediane Seite 280 KB nie ausgeführt. Sie hat es heruntergeladen, geparst und dann darauf gesessen.

Diese letzte Zahl ist die interessante. Die durchschnittliche Seite ist nicht langsam, weil jemand etwas Ambitioniertes gebaut hat. Sie ist langsam, weil sie Dinge trägt, die niemand zu tragen beschlossen hat. Ein Widget aus einer beendeten Kampagne. Eine Bibliothek, geladen für eine einzige Zeile Code. Ein Schriftschnitt, der im Design nirgends vorkommt.

Der billigste Weg, Website-Ballast loszuwerden, ist Löschen. Kein Refactoring, keine Migration, kein Neubau. Du entfernst ein Ding, die Seite wird leichter, und nichts geht kaputt, weil nichts es benutzt hat. Das hier ist eine Liste von zehn dieser Dinge, mit dem, was jedes davon tatsächlich kostet, und was man stattdessen macht.

Manches davon trifft auf dich nicht zu. Der Punkt ist, dass vier oder fünf davon vermutlich zutreffen und du sie alle vor dem Mittagessen erledigen kannst.

Lieber zum Ausdrucken? Lade den kompletten Leitfaden als PDF — 9 Seiten, alle zehn Punkte mit den Zahlen, den Prüfungen und einem Zehn-Minuten-Audit, ohne Login.

1. Der Karussell-Slider auf der Startseite

Erik Runyon hat 2013 Klickdaten vom Startseiten-Karussell der University of Notre Dame veröffentlicht, und es ist aus gutem Grund immer noch die meistzitierte Zahl in dieser Diskussion: gut 1% der Besucher haben das Karussell überhaupt angeklickt, und von denen haben rund 84% die erste Folie geklickt. Folien zwei bis fünf haben sich einen Rundungsfehler geteilt.

Die Kosten sind nicht nur Aufmerksamkeit. Ein Slider liefert eine JavaScript-Bibliothek aus, meistens ein eigenes Stylesheet und vier oder fünf herogroße Bilder, die alle laden, ob sie jemand sieht oder nicht. Bei einem typischen WordPress-Build sind das 60 bis 150 KB Skript und CSS plus mehrere hundert KB Bilder, die nur dafür existieren, vorbeizurotieren.

Wie du das prüfst: Öffne dein Analytics und such nach Klick-Events auf Folie zwei und aufwärts. Wenn das Karussell überhaupt kein Event-Tracking hat, ist das die Antwort. Niemand hat je nachgeschaut, was heißt, dass es niemanden interessiert hat.

Was du stattdessen machst: Behalte Folie eins. Das haben die Leute ohnehin gesehen. Mach daraus ein statisches Hero mit einer Überschrift und einem Button. Die anderen Folien enthalten meistens Dinge, die weiter unten einen eigenen Abschnitt verdienen, also schieb sie dorthin, wo man sie lesen statt erhaschen kann.

2. Das Live-Chat-Widget, das niemand beantwortet

DebugBear hat die populären Chat-Widgets gemessen und festgestellt, dass die schwersten 500 bis 750 KB JavaScript laden. Ein separater Test von zehn Live-Chat-Werkzeugen durch CueForGood hat Parse- und Ausführungszeit des Skripts je nach Anbieter zwischen 129 ms und 820 ms gemessen. Das ist Main-Thread-Zeit, in direkter Konkurrenz dazu, dass der Browser auf einen Fingertipp reagiert.

Und das macht es zu einer einfachen Löschung: Die meisten Chat-Widgets kleiner Unternehmen sind nicht besetzt. Sie wurden während eines Wachstumsschubs installiert, jemand hat drei Wochen lang geantwortet, und jetzt sammelt das Widget um 2 Uhr nachts "hallo ist da wer" und schickt es in ein Postfach, das niemand liest.

Wie du das prüfst: Schau im Anbieter-Dashboard nach den Konversationen der letzten 90 Tage und getrennt davon nach deiner medianen ersten Antwortzeit. Wenn die Antwort "eine Handvoll" und "elf Stunden" lautet, zahlst du ein halbes Megabyte für ein schlechteres Erlebnis als ein Kontaktformular.

Was du stattdessen machst: eine Telefonnummer und eine E-Mail-Adresse im Header, oder ein schlichtes Formular. Wenn du Chat wirklich besetzt, lade das Widget nur auf den Seiten, auf denen Gespräche tatsächlich beginnen, und lade es bei Interaktion statt beim Seitenaufbau. Die meisten Anbieter dokumentieren genau dafür eine manuelle Initialisierung.

3. Das dritte Analytics-Werkzeug, das niemand liest

GA4 über Google Tag Manager, dazu ein Heatmap-Werkzeug, dazu ein Session Recorder, dazu was auch immer die letzte Agentur eingebaut hat. Jedes davon ist eine eigene Verbindung, ein eigenes Skript und eigene Main-Thread-Arbeit. Das Third-Parties-Kapitel des Web Almanac 2025 hat festgestellt, dass über 90% der Seiten mindestens einen Drittanbieter einbinden und dass die mediane Drittanbieter-Kette drei Ebenen tief ist, die Skripte, die du hinzugefügt hast, also Skripte laden, die du nie gewählt hast.

Session Recorder sind die schlimmsten Übeltäter. Sie lauschen auf jeder Seite für jeden Besucher auf Mausbewegungen, Scrolls, Klicks und DOM-Änderungen, für immer, damit du dir einmal neun Aufzeichnungen ansiehst.

Wie du das prüfst: Liste jedes Drittanbieter-Skript auf deiner Seite und schreib neben jedes den Namen der Person, die dieses Quartal in seine Daten geschaut hat. Jedes Skript ohne Namen wird gelöscht. Es ist der schnellste Weg, Website-Ballast loszuwerden, den ich kenne, und er ist brutal im guten Sinn.

Es gibt einen zweiten Grund, diese Liste kurz zu halten. Jedes Drittanbieter-Skript ist Code, den du nicht geschrieben hast, ausgeführt auf deiner Domain mit vollem Zugriff auf deine Seiten, und das ist dieselbe Risikofläche, über die ich in Your Website Is One Compromised npm Package Away From Disaster geschrieben habe. Weniger Skripte heißt weniger Dinge, die feindselig werden können, ohne dass du es merkst.

Was du stattdessen machst: Nimm ein Analytics-Werkzeug. Wenn du Heatmaps brauchst, lass das Werkzeug zwei Wochen laufen, hol dir deine Antworten und entfern es. Heatmap-Daten sind eine Untersuchung, keine Dauerinstallation.

4. Tracking-Pixel für beendete Kampagnen

Metas Pixel, ein LinkedIn Insight Tag, ein TikTok-Pixel, ein Google-Ads-Remarketing-Tag und eines aus einem Partnerprogramm, das 2023 geschlossen wurde. Jedes davon sind typischerweise 50 bis 200 KB Skript plus eigene Netzwerkanfragen, und sie sind das klassische Ding, das niemand entfernt, weil sich niemand erinnert, es installiert zu haben.

Das verschärfende Problem ist, dass sie meistens über den Tag Manager feuern, in deinen Theme-Dateien also unsichtbar sind. Du kannst den ganzen Tag die Codebasis durchsuchen und nichts finden, weil die Tags in einer Weboberfläche leben, die jemand anders eingerichtet hat.

Wie du das prüfst: Öffne den Tag Manager, sortier deine Tags nach letzter Änderung und schau dir alles an, was älter als ein Jahr ist. Dann prüf die Werbeplattform selbst. Wenn ein Pixel Events empfängt, aber seit zwölf Monaten keine Kampagne Geld ausgegeben hat, sammelt es Daten für niemanden.

Was du stattdessen machst: Pausiere das Tag statt es zu löschen, wenn du nervös bist, vergewissere dich eine Woche lang, dass nichts kaputt ist, und lösch es dann richtig. Behalte Pixel nur für Plattformen, auf denen du aktiv Geld ausgibst. Wenn du eine Kampagne neu startest, fügst du das Tag wieder ein. Das dauert vier Minuten.

5. jQuery, geladen für zwei Selektoren

jQuery ist minifiziert rund 87 KB und komprimiert über die Leitung rund 30 KB, und auf sehr vielen Seiten existiert es, um ein Mobile-Menü-Toggle und ein sanftes Scrollen zu unterstützen. Beides ist seit Jahren nativ.

$('.menu').toggleClass('open') ist document.querySelector('.menu').classList.toggle('open'). $.ajax ist fetch. $(document).ready ist ein defer-Attribut am Script-Tag. Das sind keine cleveren Umwege mehr, das ist einfach, wie die Plattform funktioniert.

Wie du das prüfst: Durchsuch dein Theme und dein eigenes JS nach $( und jQuery(. Unter dreißig Treffer ist das ein Nachmittag. Dreihundert Treffer, lass es in Ruhe, diese Liste handelt von einfachen Siegen.

Der Vorbehalt ist real: Bei WordPress können Plugins von jQuery abhängen, auch wenn dein Theme es nicht tut, und es auszuhängen bricht sie still. Prüf die Plugin-Liste, bevor du etwas anfasst. Dieselbe Übung habe ich mit Plugins in 20 WordPress Plugins You Can Replace With a Few Lines of PHP gemacht, und dieselbe Regel gilt: Prüf die Abhängigkeit, bevor du die Abhängigkeit entfernst.

Dieselbe Logik gilt für Animationsbibliotheken. Die meisten Seiten laden eine, um ein Ein- und ein Ausblenden zu machen, und beides kann CSS nativ, was ich Zeile für Zeile in Every JavaScript Animation Library You Can Replace With 3 Lines of CSS durchgegangen bin.

6. Vier deiner sechs Schriftschnitte

Der Web Almanac hat das mediane Schriftgewicht 2025 mit 139 KB pro Desktop-Seite angegeben. Das sind meistens zwei Familien mit je drei Schnitten, oder eine Familie in Light, Regular, Medium, SemiBold, Bold und Black geladen, weil der Google-Fonts-Einbettungscode sie alle angeboten hat und niemand etwas abgewählt hat.

Öffne dein Stylesheet und grep nach font-weight. Die meisten Seiten benutzen zwei Werte. Jeder ungenutzte Schnitt ist eine eigene Datei, eine eigene Anfrage und eine weitere Chance auf einen Blitz ungestylten Texts.

Wie du das prüfst: Öffne in den Chrome DevTools den Netzwerk-Tab, filter nach Font und lade neu. Zähl die Dateien. Vergleiche diese Zahl dann mit der Anzahl unterschiedlicher font-weight-Werte in deinem CSS. Die Lücke ist deine Löschliste.

Was du stattdessen machst: zwei Schnitte, eine Familie, in WOFF2, selbst gehostet mit font-display: swap und einem preload auf den, der für deinen größten Text benutzt wird. Wenn du einen dritten Schnitt für Überschriften willst, nimm eine Variable Font, die eine Datei ausliefert und dir den ganzen Bereich gibt.

7. Die Hälfte deines Cookie-Banners

DebugBears Tests von Consent-Plattformen haben echten Schaden bei den schwereren gefunden, darunter einen Fall, in dem LCP von 1,43 Sekunden auf 3,61 Sekunden gestiegen ist, weil der Bannertext zum größten Inhaltselement wurde. OneTrust allein liefert über 184 KB JavaScript aus. Cookiebots Skript ist rund 34 KB und lädt synchron.

Und jetzt die ehrliche Frage. Braucht deine Broschürenseite mit einem Kontaktformular und GA4 eine Enterprise-Consent-Management-Plattform, die für Ad-Tech-Firmen mit Dutzenden Anbietern gebaut wurde? Meistens nicht. Du betreibst die Compliance-Maschinerie eines Geschäftsmodells, das du nicht hast.

Ich bin kein Anwalt, und wenn du in der EU echtes Ad-Targeting betreibst, brauchst du das echte Ding. Aber die Compliance-Theater-Version, in der das Banner schwerer ist als das Tracking, dem es zustimmt, ist verbreitet und eine Frage wert.

Was du stattdessen machst: Reduzier zuerst, was du erhebst. Wenn du die Werbepixel aus Punkt vier rauswirfst, schrumpft deine Einwilligungspflicht mit. Dann erledigt ein kleines selbstgehostetes Banner, oder in manchen Setups gar kein Banner, die Aufgabe. Die leichteste Einwilligungsumsetzung ist, weniger zu haben, dem zugestimmt werden muss.

8. Die Icon-Font

Font Awesomes komplettes WOFF2 ist rund 130 KB für einen Satz, aus dem du neun Icons benutzt. Ein Inline-SVG-Icon sind typischerweise 100 bis 300 Byte Markup, komprimiert weniger. Neun Icons inline sind unter 3 KB, und sie rendern mit dem HTML, also keine unsichtbaren Icons während des Font-Ladens und keine Kästchen, wenn die Font-Anfrage scheitert.

Wie du das prüfst: Durchsuch dein Markup nach Klassennamen mit fa- oder icon- und zähl die eindeutigen. Unter rund dreißig eindeutigen Icons gewinnt Inline-SVG klar.

Was du stattdessen machst: Kopier die SVG-Pfade der Icons, die du benutzt, in ein Sprite oder direkt in deine Komponenten. Wenn dir der Icon-Font-Workflow gefällt, subsette die Schrift auf die Glyphen, die du benutzt, was sie meistens unter 10 KB bringt.

9. Das automatisch startende Hintergrundvideo

Ein Hero-Video ist normalerweise das mit Abstand schwerste Asset einer Seite, häufig mehrere Megabyte, und es läuft hinter Text, der über einem Standbild genauso gut lesbar wäre. Auf dem Handy weigert sich der Browser womöglich ohnehin, es automatisch abzuspielen, die Hälfte deiner Besucher bekommt also das Posterbild, was dir sagt, dass das Posterbild gereicht hat.

Ich habe hier keine Herstellerstudie zum Zitieren. Öffne deinen eigenen Netzwerk-Tab, filter nach Media und schau dir die Zahl an. Sie ist meistens größer als erwartet, und sie konkurriert mit allem anderen, was die Seite in der ersten Sekunde braucht.

Was du stattdessen machst: Nimm das Posterbild als statisches Hero. Wenn das Video das Ding wirklich verkauft, stell es weiter unten auf die Seite hinter einen Play-Button, was auch das ehrliche Signal ist, dass es sehenswert ist.

10. Jedes Embed, das lädt, bevor jemand hinschaut

Zach Leatherman hat ein einzelnes Standard-YouTube-Embed mit fast 1,2 MB gemessen. Eine Fassaden-Umsetzung wie lite-youtube-embed erledigt dieselbe Aufgabe mit rund 30 KB, bis jemand auf Play klickt. Das sind 97% weniger für eine Änderung, die zehn Minuten dauert und identisch aussieht.

Dasselbe Muster gilt für Google-Maps-Einbettungen, Instagram-Feeds, Twitter-Timelines und Bewertungs-Widgets. Alle laden bei jedem Seitenaufruf Drittanbieter-JavaScript, damit ein kleiner Bruchteil der Besucher damit interagieren kann.

Wie du das prüfst: Lass PageSpeed Insights laufen und schau dir die Punkte "Auswirkungen von Drittanbieter-Code reduzieren" und "Drittanbieter-Ressourcen mit Fassaden verzögert laden" an. Lighthouse benennt die Übeltäter und schätzt die Ersparnis.

Was du stattdessen machst: eine Fassade. Ein statisches Bild oder ein gestalteter Platzhalter, der beim Klick das echte Embed einsetzt. Bei Karten ist ein Screenshot mit Link zu Google Maps meistens besser als das Embed, denn auf dem Handy wollen Leute die Route in ihrer Karten-App, kein winziges verschiebbares Rechteck.

Finde deine in zehn Minuten

Du musst nicht raten, welche davon auf dich zutreffen. Öffne die Chrome DevTools, drück Cmd+Shift+P, tipp "Coverage" und lade die Seite mit laufender Aufzeichnung neu. Du bekommst eine Aufschlüsselung pro Datei, wie viel CSS und JavaScript geladen wurde und wie viel davon tatsächlich lief.

Auf einer Page-Builder-Seite sind die roten Balken alarmierend. Page Builder liegen deutlich über dem Almanac-Median von 280 KB ungenutztem JavaScript, weil sie CSS und JS jedes Moduls auf jeder Seite laden, für den Fall, dass du dieses Modul benutzt hast. Coverage sagt dir nicht, was gefahrlos entfernt werden kann, aber es sagt dir, wo du schauen sollst, und der größte rote Balken ist fast immer eine Datei, die du bedingt statt global laden kannst.

Dann lass PageSpeed Insights vorher und nachher laufen. Nicht wegen des Scores, sondern wegen der Drittanbieter-Tabelle, die jede externe Domain mit Übertragungsgröße und blockierender Main-Thread-Zeit auflistet. Diese Tabelle ist deine Löschliste, bei der das Streiten schon erledigt ist.

Mach das einmal, und es wird zur Gewohnheit, so wie das Durchgehen der Blog Post SEO Checklist vor dem Veröffentlichen verhindert, dass jedes Mal dieselben fünf Fehler mitgehen.

Was dir das tatsächlich bringt

Einen Slider und zwei Pixel zu entfernen macht aus einer langsamen Seite keine schnelle. Wenn dein Stack grundsätzlich schwer ist, kauft dir Löschen ein paar hundert Millisekunden und keine neue Seite. Wo die strukturelle Lücke sitzt, habe ich in Astro-Seiten bestehen die Core Web Vitals zu 67 Prozent. WordPress zu 49. angeschaut, und die ehrliche Antwort dort war, dass die Plattformwahl viel davon erklärt.

Aber Löschen ist kostenlos, es ist umkehrbar, und es ist die einzige Performance-Arbeit ohne Nachteil. Jeder Punkt auf dieser Liste macht die Seite kleiner und lässt ein Ding weniger übrig, das kaputtgehen, ausgenutzt werden oder aktualisiert werden muss. Die meisten machen die Seite auch klarer, und das ist der Teil, der bei Conversions auftaucht statt in Lighthouse.

Fang mit der Drittanbieter-Tabelle an. Lösch, wofür niemand einen Verantwortlichen nennen kann. Dann mach das Karussell, denn ein Karussell zu löschen hat noch nie eine Website schlechter gemacht.

Wenn du die Liste durchgearbeitet hast und die Zahlen immer noch schlecht aussehen, sitzt das Problem tiefer als die Widgets, und du brauchst jemanden, der ordentlich misst statt zu raten. Leuten zu helfen, Website-Ballast loszuwerden und dann zu reparieren, was übrig ist, ist ein guter Teil dessen, was ich bei Wunderlandmedia mache. Ich sage dir gerne, wann Löschen reicht und wann nicht.