mavicon.pl - WordPress Projekt | WPPoland

#mavicon.pl, Content-Portal mit klarer Struktur

Bei einer Firmenwebsite landet die Diskussion über Geschwindigkeit fast immer bei Minifizierung und Bildkompression, also bei den gut zehn Prozent, die ein Messwerkzeug anzeigt. Der eigentliche Aufwand liegt woanders, und er ist bei WordPress-Projekten dieser Klasse fast immer derselbe. Deshalb steht er hier am Anfang statt in einer Randnotiz.

Der erste Posten ist die Zahl der Datenbankabfragen pro Aufruf. Ein Theme, das Menü, Projektliste und verwandte Leistungen mit einzelnen Abfragen innerhalb von Schleifen aufbaut, erzeugt Dutzende, wo drei genügen würden. Auf einer leeren Installation sieht man davon nichts, weil jede Tabelle eine Handvoll Datensätze enthält. Nach zwei Jahren Redaktionsarbeit ist der Unterschied deutlich und zeigt sich als allgemeine Trägheit ohne erkennbare Einzelursache, also als die unangenehmste Sorte Leistungsproblem.

Der zweite Posten sind global geladene Ressourcen. Ein Kontaktformular-Plugin hängt sein Stylesheet und sein Skript standardmäßig an jede Unterseite, auch an die ohne Formular. Das Galerie-Plugin tut dasselbe, das Slider-Plugin ebenfalls. Zusammen ergeben sie einige hundert Kilobyte, die nie jemand nutzt, und keines davon sieht für sich genommen schuldig aus.

Der dritte Posten ist der unauffälligste und betrifft fremde Skripte. Analysewerkzeuge, Chat-Widgets und Werbepixel kommen über Code in den Seitenkopf und entziehen sich damit jeder Versionskontrolle. Eine Störung beim Anbieter eines solchen Skripts kann das Rendern einer Seite blockieren, an der sonst nichts fehlt, und die Fehlersuche beginnt beim eigenen Code, weil sich an eine vor einem Jahr eingefügte Zeile niemand erinnert.

Die Reihenfolge der Optimierungsarbeiten folgt daraus unmittelbar: zuerst ganze Seiten aus dem Cache für anonymen Verkehr, dann Ordnung in den Abfragen für die Ansichten, die sich nicht cachen lassen, und erst zum Schluss die Kompression der Ressourcen. Wer diese Reihenfolge umdreht, bekommt ein ansehnliches Ergebnis im synthetischen Test und ändert nichts an dem, was Besucher tatsächlich spüren.

#Schlüssel-Funktionalitäten und verwendete Technologien

Ein Unternehmen, das technische Lösungen verkauft, hat auf seiner Website das umgekehrte Problem eines Shops. Der Shop zeigt Produkt und Preis, und der Besucher weiß in Sekunden, ob es für ihn passt. Ein technischer Dienstleister verkauft etwas, das sich nicht fotografieren lässt, an jemanden, der sein eigenes Problem meist noch nicht benennen kann. Er kommt mit einem Symptom, nicht mit einer Bestellung.

Daraus folgt das gesamte Inhaltsmodell. Das Angebot muss von der Symptomseite her lesbar sein und nicht nur unter dem Namen der Leistung, denn wer ein unerträglich langsames Lagersystem hat, sucht nicht nach der Technologie, die ausgetauscht gehört. Fallbeispiele leisten dabei mehr als Leistungsbeschreibungen, weil sie es erlauben, die eigene Lage in einer fremden wiederzuerkennen. Und die Seite muss standhalten, wenn eine technisch versierte Person prüft, ob der Anbieter weiß, wovon er spricht. An dieser Prüfung scheitern Allgemeinplätze sofort und dauerhaft.

Das Inhaltsmodell trennt deshalb drei Dinge, die auf einer üblichen Firmenseite zusammenliegen: die Leistungsbeschreibung, den Beleg in Form eines umgesetzten Projekts und das erklärende Material zum Thema. Jedes hat andere Leser, einen anderen Aktualisierungsrhythmus und einen anderen Platz auf dem Weg zur Anfrage. WordPress mit eigenen Inhaltstypen trägt diese Trennung. Sie rechnet sich erst nach etwa zwei Jahren: Im ersten Monat wirkt sie wie unnötige Komplexität, weil Kategorien dasselbe leisten. Nach zweihundert Einträgen besteht der Unterschied darin, dass eine Änderung am Projekt-Template den Blog nicht berührt und eine Redakteurin beim Anlegen einer Leistung ein Formular mit den Feldern einer Leistung sieht statt eines universellen Textfeldes mit Anweisungen im Kommentar.

Die Präsentationsmodule laden Inhalte nach, ohne die Seite neu zu laden. Die Kehrseite wird selten benannt: Nachgeladener Inhalt ist Inhalt, den eine Suchmaschine womöglich nie sieht, und auf einer Seite, deren einzige Aufgabe die Gewinnung von Anfragen aus der Suche ist, ist das eine kaufmännische und keine technische Entscheidung. Die Auflösung lautet, dass Navigation, Filter und weitere Listenseiten nachgeladen werden, der Fließtext einer Leistungsseite dagegen nie. Der erste Bildschirm ist im Quelltext vollständig.

Das Kontaktformular prüft die Eingaben im Browser und auf dem Server und leitet Anfragen an die zuständige Abteilung. Die Doppelung ist keine Verschwendung. Die Prüfung im Browser gibt es, damit niemand auf eine Serverantwort wartet, um von einem Tippfehler zu erfahren. Die Prüfung auf dem Server gibt es, weil sich die erste umgehen lässt und ein Kontaktformular ohne sie schlicht eine offene Tür für Bots ist.

#Was die Technologieliste nicht sagt

Die Werkzeugliste weiter unten beschreibt die Seite im Zustand nach Jahren der Pflege und nicht den Stand zum Start. Diese Unterscheidung ist wichtig genug, um sie auszusprechen, statt sie dem Leser zu überlassen.

Das Projekt ging 2012 online. Das war WordPress ohne REST-API im Kern, ohne Block-Editor, mit zwei Jahre alten eigenen Inhaltstypen und mit responsivem Layout, das gerade erst aufgehört hatte, eine Neuheit zu sein. React wurde erst 2013 veröffentlicht. Die REST-API kam Ende 2016 mit Version 4.7 in den WordPress-Kern. Tailwind CSS entstand 2017, und PHP 7 erschien 2015, weshalb der Wechsel weg vom 5.x-Zweig eine eigenständige Wartungsaufgabe Jahre nach dem Start war und keine Entscheidung bei der Umsetzung.

Projektbeschreibungen geben regelmäßig den heutigen technischen Unterbau als den ursprünglichen aus. Die Folge ist, dass sich eine Entwurfsentscheidung nicht mehr von einem späteren, durch Zeitablauf erzwungenen Austausch unterscheiden lässt. Bei einem Projekt, das über ein Jahrzehnt gepflegt wurde, überwiegt die zweite Sorte deutlich.

#Programmierherausforderungen und unsere Lösungen

Dynamische Inhalte brauchten eigene Endpunkte. Ohne REST-API im Kern bedeutete das eine handgeschriebene Eingangsschicht mit eigener Rechteprüfung und eigenem Antwortformat. Diese Arbeit alterte schneller als alles andere im Projekt, und genau das ist daran lehrreich: Code, der entsteht, weil der Plattform etwas fehlt, ist der erste Löschkandidat an dem Tag, an dem die Plattform es bekommt. Die Alternative, eine eigene Umsetzung neben dem Kern weiterzuführen, kostet bei jeder Aktualisierung Miete.

Die Leistungsarbeit stützte sich auf mehrschichtiges Caching mit Redis und Memcached, auf Kompression und auf Auslieferung über ein CDN. Zwei Caches in einer Installation klingen nach Übermaß, bis man sieht, dass sie Verschiedenes bedienen, der eine einen Objekt-Cache für Datenbankabfragen, der andere Sessions und Ansichtsfragmente. Der Gewinn aus einem Objekt-Cache fällt auf einer Marketing-Seite allerdings kleiner aus als allgemein angenommen, weil der größte Teil des Verkehrs aus anonymen Besuchern auf einem guten Dutzend Seiten besteht, und die lassen sich billiger bedienen, indem man die ganze Seite aus dem Cache ausliefert und PHP gar nicht erst betritt.

Die Anbindung externer Systeme umfasste den beidseitigen Austausch mit CRM und Analyseplattformen. Die entscheidende Frage war das Verhalten im Störungsfall. Die meisten Erweiterungen zeigen dann standardmäßig einen Fehler oder einen leeren Abschnitt, was auf einer Vertriebsseite aussieht, als sei die gesamte Website ausgefallen. Hier hat jede Verbindung einen Rückfallwert: die zuletzt bekannte Antwort, und wenn auch die fehlt, eine statische Fassung des Abschnitts. Der Besucher sieht dann eine Seite ohne ein Modul und keine Fehlermeldung.

Die Übernahme von Inhalten aus früheren Fassungen der Seite nutzte Import- und Exportwerkzeuge sowie das Web Archive. Dabei lauert eine Falle, die erst nach der Veröffentlichung sichtbar wird: Das Archiv bewahrt den Text, aber nicht die Adressen, unter denen dieser Text indexiert war, und auch nicht Bilder, die von fremden Domains geladen wurden. Ohne Weiterleitungen auf die alten Adressen wirkt die Migration gelungen und löscht gleichzeitig die gesamte Ranking-Geschichte der Seite.

#Was auf dieser Seite bewusst fehlt

Ein Teil der Arbeit an einer Firmenwebsite besteht darin, Dinge nicht zu bauen, und dieser Teil taucht in Projektbeschreibungen fast nie auf, obwohl er genauso eine Entscheidung ist wie jede umgesetzte Funktion.

Es gibt keinen Preisrechner. Der Umfang dieser Leistungen ergibt sich aus einer Bestandsaufnahme und nicht aus einer Parameterliste, und ein Rechner würde eine Zahl liefern, die später niemand bestätigt. Eine unbestätigte Zahl auf einer Angebotsseite kostet mehr, als sie einbringt: Sie erzeugt Anfragen mit falscher Erwartung und zwingt das erste Gespräch dazu, mit einer Korrektur zu beginnen.

Es gibt keinen Zähler abgeschlossener Projekte. Solche Zahlen führen ein Eigenleben. Nach einem Jahr weiß niemand mehr, was hineingezählt wurde, ob kleine Wartungsaufträge dazugehörten und ab wann gezählt wurde, und eine Zahl, deren Herkunft sich nicht mehr rekonstruieren lässt, ist als Beleg wertlos, solange sie nicht jemand prüfen kann.

Es gibt keinen automatisch eingebundenen Nachrichtenstrom aus der Branche. Solche Module altern schlecht: Sie sehen im ersten Monat lebendig aus und im dritten Jahr wie ein verlassenes Gebäude, weil die Quelle das Format geändert hat oder abgeschaltet wurde. Ein leerer Bereich auf einer Firmenseite sagt über den Anbieter mehr aus als der Inhalt, der dort einmal stand.

Der gemeinsame Nenner dieser drei Auslassungen ist derselbe: Jede von ihnen hätte beim Start gut ausgesehen und wäre über die Laufzeit zu einer Verbindlichkeit geworden. Der bewusste Verzicht ist hier ein vollwertiges Arbeitsergebnis und keine Lücke im Umfang.

#Werkzeuge und Technologien

WordPress bleibt die Grundlage, weil der Kunde Inhalte ohne Entwicklerin bearbeiten kann, und das ist auf einer Marketing-Seite das Kriterium, das alle anderen schlägt. PHP und MySQL tragen die Serverschicht. HTML5, CSS3, SASS und JavaScript bilden die Darstellungsschicht, wobei SASS seinen Platz nicht durch kürzere Schreibweise verdient, sondern dadurch, dass die Markenfarbe einen Ort hat statt vierzig. Bootstrap und Tailwind CSS beschleunigen den Aufbau eines einheitlichen Layouts, mit dem oben genannten Vorbehalt, wann welches davon ins Projekt kam.

Redis und Memcached halten die Zwischenspeicher, Git hält den Code. Versionskontrolle gilt bei einem Projekt dieser Größe manchmal als Formalie, und es verhält sich umgekehrt: Sie ist der einzige Mechanismus, durch den sich eine in Eile gemachte Korrektur zurücknehmen lässt, ohne raten zu müssen, was genau geändert wurde.

#Support und Wartung der WordPress-Seite

Die laufende Betreuung umfasst die Reaktion auf technische Probleme und die Behebung von Fehlern nach Aktualisierungen, regelmäßige Updates von Kern, Theme und Erweiterungen, die Auswertung der Protokolle, planmäßige Sicherungen sowie kleinere funktionale und gestalterische Anpassungen.

Ein Punkt daraus verdient Ausführung, denn er verursacht die meisten Zwischenfälle bei Seiten dieses Zuschnitts. Ein Plugin-Update beschädigt eine Seite selten von sich aus. Es beschädigt sie, wenn das Theme das Verhalten dieses Plugins überschrieben hat und sich dabei auf ein Umsetzungsdetail stützte, dessen Fortbestand der Autor nie zugesagt hat. Deshalb gehen Aktualisierungen zuerst auf eine Testumgebung, die eine Kopie der Produktion ist und keine leere Installation. Auf einer leeren Installation mit Standard-Theme funktioniert alles, und der Test sagt nichts darüber aus, was in der Produktion geschieht.

Sicherungen erhalten ihren Wert erst, wenn jemand mindestens einmal tatsächlich aus ihnen wiederhergestellt hat. Eine nie zurückgespielte Sicherung ist eine Absichtserklärung und keine Absicherung, und der Unterschied zwischen beidem zeigt sich stets im denkbar ungünstigsten Moment.

#Zusammenfassung und vorläufige Anforderungsanalyse

Die vorbereitende Analyse legte mehrere Punkte fest, die zur Grundlage des Projekts wurden. Ziel war es, das Unternehmen als Anbieter anspruchsvoller Lösungen zu positionieren und Kunden für solche Arbeiten zu gewinnen. Die Anforderungen umfassten eine dynamische Darstellung des Angebots, die Anbindung externer Systeme und ein flexibles Redaktionssystem. Der Umfang deckte die Modernisierung der Seitenarchitektur, responsive Ansichten und Präsentationsmodule ab. Das Projekt wurde in Etappen geteilt, sodass Funktionen schrittweise live gehen konnten. Der Kunde benannte Referenzseiten mit klarer Angebotsdarstellung, und das prägte das Ergebnis.

Rückblickend ist dieser letzte Punkt der interessanteste. Vom Kunden genannte Referenzen werden üblicherweise als Material für ein Moodboard behandelt. Tatsächlich tragen sie eine Information über etwas ganz anderes als Ästhetik: Sie sagen, in welcher Reihenfolge der Kunde das Lesen eines Angebots für natürlich hält, wo er einen Preis erwartet und wo die Kontaktmöglichkeit. Das sind Entscheidungen über das Inhaltsmodell und nicht über das Aussehen, und sie übertragen sich auf spätere Projekte weit besser als jedes Layout.

Die Seite entstand als Marketing-Instrument mit klarer Angebotsstruktur, Platz für Fallbeispiele und der Grundlage für fortlaufende Inhaltspflege. Was aus dieser Umsetzung weiterträgt, ist die Arbeitsweise: Inhaltsmodell vor Template, Tests gegen eine Kopie der Produktion und eine klare Grenze zwischen dem, was in den Quelltext gehört, und dem, was später nachkommen darf. Der Stack selbst trägt nicht weiter, denn die Hälfte eines Stacks von 2012 sieht heute anders aus, und das ist der normale Lauf der Dinge und kein Mangel des Projekts.