Webkrauts

Frühjahrsputz in einem Hochhaus

Webseiten sind nie fertig. Immer ist was zu tun – zu streichen, zu aktualisieren, zu löschen. Manche Webseiten sind über Jahre immer größer geworden; eine wilde Sammlung an Einzelseiten, die nun irgendwie gepflegt werden müssen. Martin Labuschin stellt Gedanken, Erfahrungen und Ideen vor, wie solch organisch gewachsene Webseiten modernisiert werden können.

Ein Teil meiner Arbeit besteht darin, die komplexen und organisch gewachsenen Webseiten von Trusted Shops daraufhin zu optimieren, dass sie leichter erweiterbar sind und dem technischen Stand von heute entsprechen. Die Webseiten bestehen zu einem Teil aus »semi-statischen« HTML/PHP-Dateien, zum anderen aus WordPress-Blogs. Die einzelnen Lokalisierungen der B2B-Webseite (deutsch, englisch, französisch etc.) und die B2C-Webseite laufen jeweils eigenständig.

Welche Herausforderungen bestehen konkret?

Der Großteil der Unterseiten hat jeweils eigene Header, Sidebars und Footer. Zentrale Dateien (php-includes) für Bereiche, die sich auf jeder Seite wiederholen, gibt es nicht. Trotz identischer Layouts werden in jeder Webseite eigene Javascript-, CSS- und Grafikdateien, sowie Inline-Javascript und -CSS verwendet. Dass es bessere Vorgehensweisen gibt, wissen wir natürlich mittlerweile.

Da wir zur Zeit an vielen umfangreichen Erweiterungen aller Bereiche der Webseite arbeiten, ist die Entwicklung schlanker Work-Flows ein wichtiges Ziel. Es sind sehr viele RewriteRules im Einsatz, die teilweise mehrfach weiterleiten. Das macht die Organisation der URLs sehr umfangreich. Es finden sich etwa sehr viele Wiederholungen aufgrund der Mehrsprachigkeit auf den Webseiten wieder.

Außerdem müssen alle Optimierungen im laufenden Betrieb erfolgen.

Was tun mit bestehenden Seiten?

Der Einsatz eines CMS kommt für uns vorerst nicht in Frage, da uns die Zeit fehlt, die große Auswahl an System auf Basis unserer Sicherheits- und Flexibilitätsansprüche zu evaluieren. Es gilt, einen guten Kompromiss zu finden – einerseits wollen wir die bestehenden Work-Flows optimieren, andererseits müssen wir den laufenden Betrieb aufrechterhalten. Wir gehen bei bestehenden Seiten, an denen Änderungen vorgenommen werden müssen, wie folgt vor:

Sich wiederholende Bereiche – wie Header, Navigation, Sidebar oder Footer – ersetzen wir durch Include-Dateien. CSS-Angaben holen wir aus dem Body-Element und sammeln die Angaben im Head-Element. So sparen wir wiederholte Angaben und können Gestaltungsänderungen schneller vornehmen. Wenn der Umfang der CSS-Angaben zu groß wird, lagern wir diese in einer seperaten CSS-Datei aus. Analog sammeln wir die Javascript-Angaben am Ende des Body-Elements. Wenn auch hier der Umfang zu groß wird, greifen wir hier ebenso auf eine seperate Datei zurück. Javascript-Dateien werden am Ende des Dokuments eingebunden, um die Performance zu steigern.

Aufgrund eines eingespannten Zeitplanes können wir meist nicht die gesamte Datei nach Optimierungsmöglichkeiten durchsuchen. Wenn uns jedoch während unserer Arbeit Syntaxfehler auffallen, korrigieren wir diese. Wenn wir bspw. Teile der deutschen Webseite für fremdsprachige Seiten benötigen, überprüfen wir den Code vor dem Kopieren auf Fehler und bereinigen ihn ggf.

Wir erreichen somit zwar kein absolut valides Markup, aber eine höhere Performance und werden flexibler für künftige Weiterentwicklungen. Bestehendes Markup wird stetig qualitativ hochwertiger, Fehler werden nicht weitergetragen.

Was tun mit neuen Seiten?

Neue Unterseiten erhalten automatisch eine höhere Priorität in der Entwicklungsphase. Daher kann hier die Qualität gesteigert werden. Hier gilt folgendes Vorgehen:

Wir wenden möglichst häufig das DRY-Prinzip an. Daher nutzen wir fertige Templates. Diese fügen wiederholte Elemente mittels Include-Dateien zu einem Layout zusammen. Bevor wir mit der formalen Qualitätssicherung beginnen, legen wir ein besonderes Augenmerk auf valides Markup. Wir evaluieren den Bedarf an externen Resourcen (CSS, Javascript), um Overhead zu vermeiden, und setzen auf Open-Source-Lösungen (jQuery, Kirby), um Zeit einzusparen, die wir dann weiteren Optimierungen widmen.

Was tun mit mittlerweile ungenutzen Seiten?

Zunächst ist zu definieren, ab wann eine Unterseite als nicht mehr verwendet gilt und ggf. gelöscht werden kann.

1. Wenn sie nicht mehr intern verlinkt ist?
2. Wenn sie durch eine neue Seite ersetzt wurde?
3. Wenn sie keine Besucher mehr hat?
4. Wenn sie ihre Bedeutung verloren hat, da der Inhalt abgelaufen ist?

Dabei kamen wir zu folgendem Ergebnis: Wenn sowohl 1. als 3. zutreffen, können wir die Datei höchstwahrscheinlich löschen. Doch letztendlich ist das Risiko, Fehler zu produzieren höher, als der Vorteil, der durch das Löschen entsteht.

Der Großteil dieser mittlerweile unnützen Dateien besteht aus Seiten für Aktionen, ehemaligen Partner und anderen zeitlich begrenzten Inhalten. Wenn ein solcher Fall eintrifft, sehen wir folgende Optionen vor:

• Wenn es sich um eine Seite handelt, die Teil einer Sammlung ist (z. B. eine Partnerseite), leiten wir auf die Übersichtsseite weiter. Meist mit einer permanenten Weiterleitung.
• Wenn es sich um eine abgelaufene Aktion oder Ähnliches handelt, wird auf die Startseite der jeweiligen Webseite weitergeleitet, wo dann ein Hinweis erscheint.
• Wenn es sich um Informationen handelt, die nicht mehr kommuniziert werden (Produktentfernung) entscheiden wir von Fall zu Fall, ob wir einen 404-Fehler-Code ausliefern oder zur entsprechenden Startseite weiterleiten.

Diese Ansätze führen dazu, dass sich der Umfang der RewriteRules weiter erhöhen wird. Das Refactoring der RewriteRules und das damit zusammenhängende Anpassen ihrer Tests ist in der Prioritätenliste nachgeordnet.

Fazit: Ist das der heilige Gral?

Die verfügbare Zeit für das Verbessern von bestehenden Seiten ist ausschlaggebend. Je ambitionierter die Zeitpläne für eine Optimierung veranschlagt sind, desto sorgsamer müssen die Prioritäten festgelegt werden: Validität? Semantik? Performance? Das muss jedes Web-Entwicklungs-Team für sich selbst entscheiden.