Die Jagd nach der perfekten Punktzahl
Wie ich in diesem Blog-Post bereits angedeutet habe, stand ein ganz besonderes Ziel ganz oben auf meiner Prioritätenliste: die Performance dieser Website. Es gibt diesen einen Moment im Leben eines Entwicklers, in dem man die eigene Seite zum ersten Mal durch Google PageSpeed Insights jagt und mit einer Mischung aus Hoffnung und Angst auf das Ergebnis wartet. Mein Ziel war von Anfang an klar definiert. Ich wollte die magische 100 in allen vier Kategorien sehen: Leistung, Barrierefreiheit, Best Practices und SEO.
Der Weg dorthin fühlte sich anfangs wie ein gemütlicher Spaziergang an, entwickelte sich jedoch schnell zu einem digitalen Marathon. Während SEO bereits bei der ersten Analyse voll punktete, gab es bei der Barrierefreiheit noch kleine Baustellen. Das Hauptproblem waren hier die Buttons, mit denen man die Bilder auf der Homepage umschalten kann. Diese lagen für die Algorithmen von Google schlichtweg zu nah beieinander. Ein klassisches Problem der mobilen Bedienbarkeit: Wer zu dicke Finger hat, verklickt sich. Also habe ich die Abstände angepasst, die Touch-Targets vergrößert und siehe da, die Barrierefreiheit rutschte prompt auf die 100.
Doch dann kam die Performance. Auf dem Desktop sah alles noch rosig aus. Ein leistungsstarker Prozessor und eine schnelle Leitung verzeihen viele Sünden. Aber die mobile Ansicht ist gnadenlos. Sie ist der Endgegner jeder Web-Optimierung. Mobile Endgeräte haben oft schwächere Prozessoren und kämpfen mit instabilen Netzwerkverbindungen. Hier trennt sich die Spreu vom Weizen. Wer hier die 100 erreichen will, muss tief in die Trickkiste greifen und bereit sein, jedes einzelne Byte zu hinterfragen.
Debuggen mit Täterblick
Performance-Tuning ist eine ganz spezielle Art des Debuggens. Normalerweise ist man beim Debuggen wie ein Detektiv, der einen Mordfall lösen muss, bei dem man seltsamerweise selbst der Täter ist. Man sucht den einen logischen Fehler, die eine Zeile Code, die alles zum Einsturz bringt. Beim Optimieren der Geschwindigkeit bleibt die Detektivrolle gleich, aber das Verbrechen ist subtiler. Die Tat war nie beabsichtigt. Man hat nicht absichtlich langsamen Code geschrieben. Man war einfach blauäugig. Ich habe vor mich hin programmiert, Features hinzugefügt und Bibliotheken eingebunden, ohne mir jemals ernsthafte Gedanken über Metriken wie den First Contentful Paint oder den Largest Contentful Paint zu machen.
Diese Abkürzungen, FCP und LCP, klingen zunächst wie technisches Kauderwelsch, aber sie entscheiden darüber, ob ein Nutzer auf der Seite bleibt oder frustriert abspringt. Der First Contentful Paint misst, wann das erste Element auf dem Bildschirm erscheint. Der Largest Contentful Paint gibt an, wann das Hauptinhaltselment geladen ist. Wenn diese Werte im roten Bereich liegen, fühlt sich die Website zäh und leblos an. Meine Reise in die Welt der Millisekunden begann genau hier.
WebP, Lazy Loading und das JavaScript-Bundle
Eine der ersten Lektionen, die ich lernen durfte, betraf das Bildformat WebP. Wenn man sich in Foren umschaut, gibt es immer wieder Stimmen, die behaupten, WebP sei kompliziert oder bringe nicht viel. Doch meine Erfahrung war eine völlig andere. WebP ist absolut fantastisch, wenn es darum geht, die Dateigröße bei gleichbleibender Qualität drastisch zu reduzieren. Früher habe ich mir kaum Gedanken über die Kompression gemacht. Heute weiß ich, dass jedes Kilobyte zählt. Ein Bild, das als JPEG noch 500 Kilobyte wog, schrumpft als WebP oft auf unter 50 Kilobyte zusammen, ohne dass das menschliche Auge einen Unterschied bemerkt.
Parallel dazu habe ich angefangen, das Prinzip des Lazy Loadings auf die Spitze zu treiben. Die Idee ist simpel: Lade nur das, was der Nutzer gerade sieht. Warum sollte das Bild im Footer geladen werden, wenn der Nutzer noch ganz oben am Header liest? Anfangs war ich skeptisch, ob man wirklich alles verzögert laden sollte. Aber im Kampf um die 100 Punkte auf dem Smartphone ist diese Strategie Gold wert. Es entlastet die initiale Bandbreite und sorgt dafür, dass der Browser sich auf die wichtigen Elemente konzentrieren kann, die sofort sichtbar sein müssen.
Doch die größte Herausforderung wartete an einer Stelle, die ich völlig unterschätzt hatte: das JavaScript-Bundling. Bundling klingt in der Theorie super. Man packt alle kleinen Skripte in eine große Datei, um die Anzahl der Serveranfragen zu minimieren. Das Problem entsteht jedoch dann, wenn dieses Bundle zu einem unüberschaubaren Monster anschwillt. Bei mir waren es am Ende etwa 73 Kilobyte an ungenutztem JavaScript. Das klingt im ersten Moment nach wenig, aber für die Analyse-Tools von Google ist das ein gefundenes Fressen für Punktabzug.
Das Problem beim ungenutzten Code ist, dass man oft gar nicht weiß, wo er herkommt. Er versteckt sich in den Tiefen der Abhängigkeiten, die man über die Monate angesammelt hat. Man installiert eine Bibliothek für eine kleine Funktion, und plötzlich schleppt man ein riesiges Paket an Logik mit sich herum, die niemals ausgeführt wird. Die Suche nach diesem "toten Fleisch" im Code war mühsam. Ich musste lernen, Analyse-Tools zu nutzen, die mir genau aufschlüsselten, welche Funktionen tatsächlich gebraucht werden und welche nur Platz wegnehmen.
Sprachdateien und doppelter Ballast
In diesem Prozess stieß ich auf ein weiteres, fast schon peinliches Problem: meine Sprachdateien. Da diese Website zweisprachig ist, hatte ich anfangs die Texte für Deutsch und Englisch in einem gemeinsamen Paket geladen. Ein klassischer Anfängerfehler. Ein Nutzer, der die deutsche Version liest, braucht die englischen Übersetzungen nicht im Arbeitsspeicher seines Browsers. Die Lösung war ein radikaler Umbau der Ladestruktur. Jetzt werden die Sprachdateien strikt getrennt. Es wird nur das geladen, was gerade aktiv ist. Dieser Schritt allein hat die Ladezeiten spürbar verbessert und die Performance-Metriken nach oben getrieben.
Aber die Reise war hier noch nicht zu Ende. Während ich meine Sprachdateien aufräumte, fiel mir auf, wie rücksichtslos ich mit externen Bibliotheken umgegangen war. Ich hatte über die Zeit hinweg eine regelrechte Sammlung angelegt. Der Tiefpunkt war die Erkenntnis, dass ich gleich zwei verschiedene Bibliotheken für Benachrichtigungen installiert hatte: Toast und Sonner. Beide tun im Grunde das Gleiche, sie lassen kleine Meldungen am Bildschirmrand aufpoppen. Warum ich beide im Projekt hatte? Ich wusste es nicht mehr. Wahrscheinlich habe ich eine ausprobiert, die andere vergessen zu löschen und am Ende beide mitgeschleppt.
Der Gipfel der Ironie war jedoch, dass ich nach einer genauen Analyse feststellen musste, dass ich derzeit überhaupt keine Benachrichtigungen mehr auf der Website verwende. Ich hatte also zwei Bibliotheken geladen, die miteinander um Ressourcen konkurrierten, für ein Feature, das gar nicht aktiv war. Ein rüdes Erwachen. Das Entfernen dieser Altlasten fühlte sich an wie ein digitaler Hausputz. Jede gelöschte Zeile Code, jede entfernte Bibliothek war ein kleiner Sieg auf dem Weg zur perfekten Punktzahl.
Diese Phase des Aufräumens lehrte mich eine wichtige Lektion über Disziplin in der Softwareentwicklung. Es ist leicht, neue Dinge hinzuzufügen. Es ist schwer, Dinge wieder zu entfernen, wenn man nicht mehr genau weiß, warum sie dort sind. Die Angst, etwas kaputt zu machen, hält einen oft davon ab, radikal zu kürzen. Aber genau diese Radikalität ist notwendig, wenn man eine Website bauen will, die nicht nur funktioniert, sondern die auch im Bereich der Geschwindigkeit zur Spitzenklasse gehört.
Vier grüne Kreise
Nach unzähligen Stunden des Testens, Optimierens und erneuten Testens war es dann schließlich so weit. Ich drückte erneut auf den Analyse-Button von PageSpeed Insights. Der Ladebalken bewegte sich langsam. Die Spannung stieg. Und dann leuchteten sie nacheinander auf: Vier grüne Kreise, jeweils mit der Zahl 100 in der Mitte. Ein Moment purer Erleichterung. Es war ein langer Weg, geprägt von kleinen Frustrationen und großen Lerneffekten. Aber am Ende habe ich es geschafft, wie man auch im aktuellen PageSpeed Insights Report sehen kann.
Diese Erfahrung hat meine Sicht auf das Webdesign grundlegend verändert. Es geht nicht mehr nur darum, dass etwas schön aussieht. Es geht darum, wie effizient die Technik dahinter arbeitet. Eine schnelle Website ist ein Zeichen von Respekt gegenüber dem Nutzer und seiner Zeit. Man zwingt ihn nicht dazu, unnötige Daten zu laden oder auf lahme Skripte zu warten.
Die Optimierung auf die volle Punktzahl war mehr als nur eine technische Spielerei. Es war ein tiefes Eintauchen in die Funktionsweise moderner Browser. Ich habe gelernt, wie wichtig die Priorisierung von Ressourcen ist. Welche Skripte müssen sofort ausgeführt werden? Welche können warten, bis die Seite fertig gerendert ist? Diese Fragen klingen banal, aber die Antworten darauf machen den Unterschied zwischen einer guten und einer exzellenten Nutzererfahrung aus.
Rückblickend betrachtet war die Entscheidung, SEO und Barrierefreiheit zuerst anzugehen, genau richtig. Diese Bereiche bilden das Fundament. Ohne Barrierefreiheit schließt man Menschen aus, und ohne SEO findet niemand die Seite. Aber die Performance ist der Motor, der alles antreibt. Ein Auto mit einer tollen Lackierung und bequemen Sitzen bringt nichts, wenn der Motor ständig stottert. Mein digitaler Motor schnurrt jetzt wie ein Kätzchen, und das Gefühl, ein optimiertes Produkt im Netz zu haben, ist unbezahlbar.
Besonders fasziniert hat mich am Ende die Wirkung der kleinen Dinge. Oft denkt man, man müsse das gesamte Framework austauschen oder einen Teil komplett neu schreiben. Aber meistens sind es die kumulierten Effekte von kleinen Korrekturen. Ein falsch skaliertes Bild hier, ein vergessenes Skript dort und eine unsaubere CSS-Datei addieren sich schnell zu einer sekundenlangen Verzögerung. Wer lernt, diese kleinen Stellschrauben zu finden, hat den Schlüssel zur Performance in der Hand.
Der Prozess hat mir auch gezeigt, dass man niemals wirklich fertig ist. Das Web entwickelt sich ständig weiter, neue Standards entstehen und die Anforderungen der Nutzer steigen. Was heute eine 100 ist, könnte morgen durch ein neues Update der Algorithmen schon wieder eine 95 sein. Aber das ist in Ordnung. Jetzt, da ich die Werkzeuge und das Wissen besitze, macht mir dieser kontinuierliche Verbesserungsprozess sogar Spaß. Es ist ein ständiger Wettlauf gegen die eigene Bequemlichkeit und für eine bessere technische Qualität.
Abschließend kann ich nur jedem Entwickler raten, sich einmal die Zeit zu nehmen und die eigene Seite wirklich unter die Lupe zu nehmen. Schaut euch an, was im Hintergrund passiert. Versteht euer JavaScript-Bundle. Hinterfragt jede Bibliothek. Es lohnt sich nicht nur für die Statistik oder die Eitelkeit, die volle Punktzahl zu erreichen. Es lohnt sich, weil man dabei lernt, ein besserer Programmierer zu werden. Man entwickelt ein Gespür für Effizienz, das weit über die Webentwicklung hinausgeht. Es war ein harter Weg, aber die 100 bei PageSpeed Insights zu knacken, war jeden einzelnen Schritt wert. Die Website fühlt sich jetzt so leichtfüßig an, wie ich es mir immer gewünscht habe. Ein Projekt ist eben erst dann wirklich fertig, wenn man nichts mehr weglassen kann, ohne die Funktion zu beeinträchtigen.