Travel & Tourism Site: zamki-szkocji.com

#zamki-szkocji.com, Ihr Leitfaden zu den magischen Schlössern Schottlands

zamki-szkocji.com ist ein Informationsportal über die Schlösser und Burgen Schottlands: historische Texte, eine interaktive Karte, Foto- und Videogalerien sowie praktische Hinweise für die Reiseplanung. Das Portal ging 2012 online, läuft auf WordPress, nutzt Redis als Objekt-Cache und liegt auf AWS-Infrastruktur mit einem CDN vor den Mediendateien. Die Umsetzung dauerte rund sechs Wochen. Layout und Elementanordnung kamen vom Kunden; meine Aufgabe war es, daraus ein Inhaltsmodell, Templates und Integrationen zu bauen, die auch nach Jahren weiterer Einträge noch tragen.

#Die Redaktion entscheidet über die Architektur

Bei einem Archivprojekt wird der wichtigste Teil der Technik von der redaktionellen Arbeit bestimmt, nicht umgekehrt. Wer ein Schloss erfasst, sitzt vor einer Quelle, hat die Jahreszahlen im Kopf und weiß gerade jetzt, ob das Objekt ganzjährig zugänglich ist. Zwei Wochen später weiß er es nicht mehr, und niemand liest den Artikel noch einmal, um die Information nachzutragen.

Deshalb wurde ein Schloss nicht als Blogbeitrag angelegt, sondern als eigener Inhaltstyp mit eigenen Feldern: Koordinaten, Anfahrtshinweise, Region, Epoche, Baustil, Galerie, Videomaterial, Zeitleiste der Ereignisse. In WordPress heißt das Custom Post Type mit eigenen Taxonomien. Das Eingabeformular ist dadurch länger und unbequemer als ein leeres Editorfenster, und genau das ist der Punkt: Es zwingt die Entscheidung in den Moment, in dem die Quelle noch offen ist.

Der Unterschied zeigt sich erst mit der Menge. Bei zwanzig Objekten reichen Schlagwörter, und jede Alternative wirkt übertrieben. Bei mehreren Hundert sind Schlagwörter keine Klassifikation mehr, sondern eine Sammlung von Beinahe-Synonymen. Ein Teil der Einträge sagt Highlands, ein Teil sagt Norden, einige sagen beides, und keine Liste ist mehr nachweisbar vollständig. Eine geschlossene Taxonomie verhindert das, kostet aber Beweglichkeit: Das Vokabular muss vorab durchdacht werden, und eine spätere Änderung ist eine Datenmigration, keine Textkorrektur.

Für dieses Projekt war der Handel einfach. Die Geografie Schottlands und die Einteilung der Wehrarchitektur ändern sich nicht von Jahr zu Jahr. Bei einem Portal über Veranstaltungen oder Angebote, dessen Vokabular sich mit dem Markt bewegt, wäre dieselbe Entscheidung ein Fehler.

Ein Detail mit Langzeitwirkung ist die Zeitleiste. Es ist verlockend, sie als fertiges Markup in den Text zu schreiben. Am ersten Tag sieht das gut aus und ist überall sonst unbrauchbar. Als Datensatz aus Daten und Ereignissen gespeichert, lässt sie sich in mehreren Layouts ausgeben, sortieren und an einer einzigen Stelle korrigieren, wenn auffällt, dass zwei Quellen den Umbau eines Flügels unterschiedlich datieren.

#Hauptfunktionen und technische Lösungen

Die interaktive Karte arbeitet mit der Google Maps API und mit eigenen Endpunkten, die Standortdaten in einer Form liefern, die zum Zeichnen von Markern passt. Diese Trennung ist keine Kosmetik. Würde die Karte vollständige Beiträge abfragen, zöge sie bei jedem Aufruf den gesamten historischen Text über die Leitung, um einen Punkt und drei Sätze im Infofenster darzustellen. Der eigene Endpunkt liefert nur, was gezeichnet wird: kleine Antwort, gut cachebar, unabhängig von jeder Korrektur im Artikeltext.

Der zweite Grund ist Wartung. Standortdaten laufen durch eine einzige Stelle, also stehen Regeln wie “kein Objekt ohne Koordinaten auf der Karte” oder “keine Ruine ohne Anfahrtshinweis” im Code statt in der Gewohnheit der Redaktion. Bei einem Portal, das über ein Jahrzehnt wächst, ist das der Unterschied zwischen einer Karte, die den Datenbestand abbildet, und einer Karte, die jemand einmal im Jahr von Hand prüfen muss.

Jede externe Kartenanbindung bringt denselben Kompromiss mit. Der Anbieter liefert Kacheln, Geokodierung und ein Bedienverhalten, das die Nutzer von anderen Seiten kennen, und bindet das Projekt im Gegenzug an fremde Kontingente und fremde Schlüsselpolitik. Statt so zu tun, als gäbe es diesen Preis nicht, wird die Zahl der Aufrufe begrenzt: Die Karte lädt erst, wenn sie gebraucht wird, nicht auf jeder Listenseite, und die Antworten des eigenen Endpunkts werden zwischengespeichert, damit Scrollen in der Liste keinen Verkehr zum Anbieter erzeugt.

Galerien und Medienwechsel laufen über AJAX, das Blättern durch Fotos lädt also nicht die ganze Seite neu. Der Nutzen liegt auf der Hand, der Preis weniger. Inhalte, die erst nach einem Skriptlauf existieren, existieren für einen Teil der Besucher gar nicht: im schlechten Fall für einen Crawler, im schlechteren für einen Screenreader. Adresse und Beschreibung eines einzelnen Bildes müssen deshalb im normalen HTML-Dokument stehen. AJAX beschleunigt die Navigation, ersetzt sie aber nicht.

Kommentare und Bewertungen lassen Besucher ihre eigene Erfahrung mit einem Ort hinterlassen. Die Funktion ist schnell aktiviert und dauerhaft teuer, denn jedes offene Formular auf einer in Suchmaschinen sichtbaren Seite wird binnen Wochen von automatisiertem Verkehr gefunden. Die praktische Lehre aus diesem Projekt: lieber streng moderieren und später lockern, als nach Monaten dreißig Shoplinks unter der Beschreibung einer Höhenburg wegräumen.

#Herausforderungen und implementierte Programmierlösungen

Die eigentliche Einschränkung war die Ladezeit, und sie ließ sich nicht durch eine leichtere Seite lösen. Die Fotos sind der Inhalt. Sie zu entfernen hätte die Messung verbessert und den Grund beseitigt, aus dem jemand die Seite besucht.

Redis übernimmt das Objekt-Caching. Eine WordPress-Seite entsteht aus vielen kleinen Lesezugriffen: Optionen, Metadaten, Taxonomiebeziehungen. Auf einer Archivseite mit Dutzenden Objekten und deren Feldern wächst die Zahl dieser Zugriffe schneller, als die Zahl der sichtbaren Elemente vermuten lässt. Liegen die Ergebnisse außerhalb der Datenbank, wiederholt der nächste Aufruf diese Arbeit nicht. Das hilft genau dort, wo ein vollständiger Seiten-Cache nicht greift: bei parametrisierten Ansichten, beim Kartenendpunkt, bei jeder Anfrage einer angemeldeten Redakteurin.

Das CDN übernimmt die Medien. Schlossfotografie ist schwer, und das Publikum verteilt sich über Polen, die Britischen Inseln und jeden Ort, an dem gerade eine Reise geplant wird. Werden diese Dateien von einem einzigen Ursprung ausgeliefert, wartet die Hälfte der Leser jedes Mal auf eine Übertragung quer durch Europa. Auslieferung aus Standorten nahe am Leser nimmt dem Anwendungsserver zusätzlich Arbeit ab, die dort nie hingehörte.

Der Verkehr eines Reiseportals verteilt sich nicht gleichmäßig, und das ändert, welche Optimierung sich lohnt. Er steigt saisonal und springt nach einer Erwähnung in der Presse oder nach dem Teilen in einer großen Interessengruppe. Eine Abstimmung auf den Monatsdurchschnitt bringt wenig. Es zählt die Stunde, in der ein Vielfaches der üblichen Last ankommt, und in dieser Stunde rettet nicht schnellerer Code, sondern der Umstand, dass die meisten Antworten die Anwendung gar nicht erreichen.

Cache-Laufzeiten wurden bewusst gesetzt und nicht aus einem Plugin-Standard übernommen. Eine Schlossbeschreibung darf Stunden im Cache liegen, sie ändert sich einige Male im Jahr. Ein Hinweis auf eine vorübergehende Schließung darf das nicht, denn genau dafür ruft jemand die Seite am Abend vor der Fahrt auf. Diese beiden Fälle zu trennen ist billiger, als die globale Lebensdauer zu verkürzen und damit überall Leistung zu verschenken, um eine einzige Ansicht zu reparieren.

Gemessen wurde auf einer Kopie der Produktion, nicht auf einer leeren Installation. Ein leeres WordPress mit Theme und zwei Beiträgen antwortet immer schnell, unabhängig davon, wie die Abfragen geschrieben sind. Erst eine Datenbank mit dem vollständigen Objektbestand, den Metadaten, den Taxonomiebeziehungen und der Kommentarhistorie zeigt, welche Abfrage einen halben Tabellenscan auslöst und welche einen Index nutzt.

Auf der Suchmaschinenseite standen semantisches HTML5, saubere Metaangaben, aus der Struktur abgeleitete lesbare Adressen und strukturierte Daten nach schema.org für die Schlossartikel. Der Zweck ist eng gefasst: einer Maschine beschreiben, was ein Mensch am Layout ablesen kann. Strukturierte Daten stellen keinen schwachen Text vor einen guten. Sie verhindern, dass ein guter Text übersehen wird, weil ein Crawler nicht erkennen konnte, um welche Art von Seite es sich handelt. Belastbare Messwerte zur Wirkung dieser Arbeit liegen mir nicht vor, deshalb nenne ich hier keine.

#Support und Wartung der Webseite

Die laufende Betreuung umfasst Updates von Kern, Theme und Plugins, die Durchsicht der Logs, Sicherungen sowie kleinere funktionale und gestalterische Änderungen. Bei einem Portal, das seit 2012 läuft, ist die Wartung der größere Teil der Geschichte, und sie gehört entsprechend in die Planung, nicht in eine Fußnote nach der Abnahme.

Updates werden auf einer Kopie getestet. Ein Projekt mit eigenem Inhaltstyp, eigenen Taxonomien und externer Kartenanbindung hat mehrere Stellen, an denen eine Änderung im Kern oder in einem Plugin das Verhalten ändert, ohne einen Fehler zu melden: Eine Abfrage wird anders zusammengesetzt, ein Filter, auf dem eine Ansicht beruhte, verschwindet, der Kartenanbieter stellt ein altes Authentifizierungsverfahren ein.

Ein Backup ist eine Wiederherstellungsprozedur, keine Datei auf einer Platte. Eine Sicherung, aus der nie zurückgespielt wurde, ist eine Absichtserklärung. Wert hat die, aus der schon einmal eine lauffähige Kopie der Seite entstanden ist, samt Notiz, wie lange das gedauert hat.

#Zusammenfassung

Tragfähig geblieben ist zamki-szkocji.com wegen Entscheidungen, die von außen unsichtbar sind: Schlösser als Datensätze statt als Artikel, Kartendaten in einem eigenen Endpunkt, Objekt-Cache getrennt von der Medienauslieferung, Inhalte im HTML-Dokument auch dort, wo AJAX die Navigation beschleunigt.

Übertragbar auf das nächste Projekt sind die technische Schicht und die Methode: WordPress, Redis, AWS und CDN, strukturierte Daten, Messung gegen eine Produktionskopie. Nicht übertragbar sind das Inhaltsmodell dieses Portals und seine Integrationen, denn sie wurden für einen Datenbestand und eine Leseweise geschrieben. Ein neues Vorhaben beginnt mit der Aufnahme des Umfangs, und das Angebot folgt darauf, nicht davor.