Die Technik hinter einer Website ist für die meisten, solange nebensächlich, bis sie mal nicht funktioniert. Um trotzdem ein paar Einblicke in den Maschinenraum von MTB-News.de zu geben, beleuchten wir an dieser Stelle exemplarisch ein paar Dinge, die uns im vergangenen Jahr beschäftigt haben. Wir wünschen viel Spaß an diesem seltenen Blick hinter die Kulissen!
Das Jahr 2018 war derart vollgepackt mit Arbeiten an Website und Infrastruktur, dass wir an dieser Stelle nur auf einige wenige Beispiele genauer eingehen können. Wir haben nach so vielen Jahren MTB-News.de auch 2018 wieder eine Menge #Neuland betreten und haben dabei natürlich auch sehr viel lernen können. Daran wollen wir euch in diesem Beitrag teilhaben lassen.
Am Ende gibt es einen kleinen Ausblick auf das kommende Jahr, denn wir werden auch im Jahr 2019 nicht Rast machen, sondern weiter fleißig an der Verbesserung von MTB-News.de arbeiten!
Podcast „Pokal oder Spital“
Pünktlich zum Beginn des Jahres starteten Hannes, Moritz und Marcus mit dem MTB-News.de-Podcast „Pokal oder Spital“. Die Idee für einen Podcast ist schnell geboren, die technische Umsetzung erfordert dann schon etwas Gehirnschmalz: Aufnahme-Setup, Audio-Schnitt und Podcast-Hosting sind alles Dinge, mit denen sich niemand von uns vorher beschäftigt hatte.
Zum Glück gibt es mit der deutschen Podcast-Community Sendegate eine Plattform, auf der mittlerweile so viel Wissen versammelt ist, dass der technische Einstieg in die Podcast-Welt deutlich erleichtert wird. So verbrachte Marcus dann auch den einen oder anderen Abend mit der Recherche und fand heraus, wie wir den Podcast technisch bei MTB-News.de umsetzen würden.
Drei Leute, drei Orte, eine Aufnahme
Die erste zu lösende Aufgabe war dabei gleich eine recht anspruchsvolle: Wie sollen wir den Podcast überhaupt aufnehmen? Hannes, Moritz und Marcus befinden sich normalerweise alle an verschiedenen Orten, es ist also nicht möglich, sich einfach an einen Tisch zu setzen, ein Mikrofon in die Mitte zu stellen und drauf los zu quatschen. Mit Studio-Link gibt es zum Glück eine sehr gut funktionierende und einfach einzurichtende Lösung, um Audio in hoher Qualität über Internetverbindungen zu übertragen.
Die Studio-Link-Kanäle landen dann bei Marcus auf dem Rechner, wo sie mit der Ultraschall-Software in einzelnen Spuren aufgezeichnet werden. Ultraschall ermöglicht es dabei schon während der Aufnahme Kapitelmarken zu setzen und bietet überhaupt alle Features, die man sich als Podcaster vorstellen kann – inklusive eines Soundboards (welches wir übrigens hauptsächlich mit Audioschnipseln aus dem besten deutschen Film „Bang Boom Bang“ gefüllt haben).
Jetzt fängt die Arbeit erst an
Nach der Aufnahme fängt der Spaß dann überhaupt erst an: der Podcast benötigt einen begleitenden Artikel bei MTB-News.de (die sogenannten „Shownotes“), welcher einen Überblick über die Themen im Podcast gibt und mit weiterführenden Links alle angesprochenen Informationen erreichbar macht. Das Erstellen der Shownotes beginnt meist schon während der Aufnahme. Um unserem Qualitätsanspruch zu genügen, wird die Podcast-Aufnahme nachträglich aber noch einmal abgehört und die Shownotes ausformuliert und vervollständigt.
Die Veröffentlichung ist jetzt nicht mehr weit entfernt, es müssen nun nur noch die einzelnen Spuren der Aufnahme in der Lautstärke angeglichen und schließlich zusammengemischt werden. Hierfür nutzten wir anfangs den Dienst Auphonic, erledigen das aber mittlerweile selbst direkt in Ultraschall.
Sind Shownotes und die Audiodateien schließlich veröffentlichungsreif, wird in unserem Redaktionssystem der Artikel angelegt und die Dateien (AAC- und MP3-Audio-Dateien sowie die Kapitelmarken für den Web-Player) hochgeladen. Kurze Zeit später hämmern dann schon eure Podcast-Apps auf unsere Server ein und laden den Podcast herunter.
Im Laufe des Jahres haben unsere Server bereits etliche Terabyte Audiodaten zu euch übertragen. Wir sind mit der technischen Lösung sehr zufrieden – sie arbeitet von Tag eins an absolut problemlos.
Das Schönste ist aber die Tatsache, dass wir mittlerweile eine vierstellige Stammhörerschaft haben und immer noch jede Folge so motiviert von uns produziert wird wie die Erste. Unser Podcast wird euch also auch 2019 regelmäßig begleiten!
Zweiteilige Titel – die simple Lösung am Ende eines langen, steinigen Weges
Seit einiger Zeit haben unsere Artikel zweiteilige Titel. Dieses Konzept ist seit Ewigkeiten im Print-Bereich etabliert, neben der eigentlichen Überschrift („Schlagzeile“) gibt es zusätzlich die sogenannte „Dachzeile“.
Wir haben die Aufteilung in Schlagzeile und Dachzeile eingeführt, um zum einen das Erfassen der Überschrift zu vereinfachen und zum anderen etwas mehr Platz zur Verfügung zu haben. Um eine Kategorisierung beim Lesen der Überschrift zu ermöglichen, haben wir zum Beispiel bei Veranstaltungen den Namen des Events in die Überschrift aufgenommen. Das führte dazu, dass der Platz für die eigentliche Schlagzeile sehr knapp wurde. Nachfolgend ist das an einem Beispiel illustriert:
Downhill-WM 2018 Lenzerheide: Highspeed mit Felsgarten – Die Streckenvorschau mit Johann Potgieter
Die Überschrift ist mit 98 Zeichen viel zu lang, um sie zum Beispiel in einem Artikel-Teaser sinnvoll darstellen zu können. Haben wir sie früher teilweise bis zur fast kompletten Abwesenheit von Information eingekürzt, können wir heute den Event-Namen mit kleinerer Schriftgröße in die Dachzeile packen und haben so genügend Platz für die echte Schlagzeile:
Die Vorteile einer zweiteiligen Überschrift liegen also auf der Hand, fehlt also nur noch die Umsetzung.
Erster Akt: die naheliegende Lösung
Unser Redaktionssystem WordPress unterstützt erst mal keine zweiteiligen Überschriften, ist aber zum Glück sehr einfach erweiterbar, sodass sich diese Funktion leicht nachrüsten lässt. Wir haben uns für den Einsatz des Plugins WP Subtitle entschieden: Es stellt für einen Artikel ein zusätzliches Eingabefeld zur Verfügung, in welches die Dachzeile eingegeben wird.
Damit ist der erste Schritt getan – wir konnten die zweiteiligen Überschriften erst mal in der Artikeldatenbank speichern. Der zweite Teil der Aufgabe bestand darin, alle Stellen an denen die Artikelüberschrift ausgegeben wird derart anzupassen, dass die Dachzeile zusammen mit der Hauptüberschrift angezeigt wird. Dies betrifft natürlich die Artikelseiten, die Startseite, die Kategorieübersichten, Suchergebnisse und vieles mehr.
Zweiter Akt: ein Rattenschwanz an Abhängigkeiten
Das „vieles“ in „vieles mehr“ ist dabei wörtlich zu verstehen. Und das in einer Art und Weise, dass wir nach über einem Jahr immer noch Stellen gefunden haben, bei denen die Dachzeile nicht angezeigt wurde. WordPress-KennerInnen werden jetzt vermutlich etwas sagen wie „nehmt doch einfach den the_title-Hook und feiert das darüber ab“. So einfach ist es dann aber doch nicht, da wir die einzelnen Teile der zweiteiligen Überschrift oft in verschiedene HTML-Elemente legen müssen; auch hier gäbe es viele Ausnahmen zu berücksichtigen, die auch weit über die reine Darstellung hinausgehen. So werden z. B. werden bei der Volltextsuche in WordPress die Textbestandteile der Dachzeile nicht berücksichtigt – auch eine Sache, die wir nachrüsten mussten.
Dritter Akt: die schlaue weil einfache Lösung
Eines Nachts kam Marcus dann eine Idee, die eine derart simple Lösung für unser Problem der zweiteiligen Überschriften darstellt, dass er sie selbst noch sehr skeptisch erst mal Thomas vorstellen musste. Marcus ging fest davon aus, sich anhören zu müssen, welchen offensichtlichen Fall er übersehen hatte und warum sein Ansatz nicht taugen würde. Thomas’ Reaktion zeigte aber, dass wir durchaus auf dem richtigen Weg waren. Wir hatten offensichtlich doch die Lösung für uns gefunden:
Zuerst entfernten wir zusätzliche Eingabefelde für die Dachzeile wieder. Der Inhalt der Dachzeile wurde ab sofort zusammen mit der Hauptüberschrift im selben Feld eingegeben: Die Dachzeile wird der Schlagzeile einfach vorangestellt, beide Teile werden durch einen Doppelpunkt voneinander abgetrennt.
Die Überschrift wird jetzt erst einmal überall in der Form Dachzeile: Schlagzeile ausgegeben. Alle Stellen, an denen wir explizit die zweiteiligen Überschriften besonders gestaltet ausgeben wollen (z. B. in Teasern oder auf den Artikelseiten), teilen wir die komplette Überschrift am ersten Doppelpunkt gefolgt von einem Leerzeichen und nutzen den ersten Teil als Dach- und den zweiten Teil als Schlagzeile. Im Gegensatz zur vorherigen Lösung treten Dach- und Schlagzeile jetzt also immer gemeinsam auf und nur, wenn wir beide separat darstellen wollen trennen wir den Titel entsprechend auf. Vorher mussten wir umgekehrt die Dachzeile ausdrücklich an jeder Stelle hinzufügen.
Da wir als Trennzeichen den Doppelpunkt gefolgt von einem Leerzeichen nehmen, lassen sich spezielle Produktnamen wie z. B. „Canyon Neuron:ON“ auch in der Dachzeile nutzen, da hier dem Doppelpunkt kein Leerzeichen folgt.
Die Umstellung auf die simple Lösung war sehr einfach (wegnehmen ist meist leichter als hinzutun) und funktioniert jetzt seit einigen Wochen reibungslos.
Performance-Tuning
Ein Thema, welches in den letzten Jahren immer wichtiger wurde, sind die Ladezeiten von Webseiten. Nicht nur Google bezieht diese in die Bewertung der Position in Suchergebnissen ein, auch unsere LeserInnen wollen, dass sich die Seiten schnellstmöglich aufbauen. Dies wird umso wichtiger, je mehr mobile Endgeräte zum Einsatz kommen – gerade in Deutschland ist die Qualität der Mobilfunknetze nämlich nicht dort, wo sie eigentlich sein müsste und so quält man sich oft genug mit 3G-Verbindungen und den einhergehenden hohen Latenzzeiten herum.
Wir arbeiten jetzt seit einiger Zeit an Performance-Verbesserungen und wollen euch hier mal einen kurzen Einblick über unsere Fortschritte geben.
Die Ausgangsposition
Wir setzen seit einigen Jahren WordPress als Redaktionssystem ein, dieses haben wir durch eine Vielzahl von Plugins erweitert, um unsere Anforderungen an die Funktionalität zu erfüllen. Wenn eine Seite (z. B. die MTB-News.de-Startseite oder ein beliebiger Artikel) aufgerufen wird, baut WordPress die Seite dynamisch zu diesem Zeitpunkt zusammen und liefert sie an das Endgerät aus. Hierbei hat jedes aktive WordPress-Plugin einen negativen Einfluss auf die benötigte Zeit, eine Seite komplett zu erstellen.
Wir benötigen für das Erstellen einer Artikelseite trotz ziemlich schneller Hardware aktuell circa 0,5 Sekunden bis 1 Sekunde. In dieser Zeit passiert im Webbrowser nichts Sichtbares, sie ist für die Besucher und Besucherinnen also komplett verschwendete Zeit. Nachdem die Seite zum Webbrowser übertragen wurde, fängt dieser aber erst an zu arbeiten: er muss zuerst die Informationen zur Gestaltung der Seite nachladen („CSS“, Cascading Style Sheets: diese geben dem Browser die Anweisungen, wie er die Seite auf dem Bildschirm darzustellen hat, also Layout-Informationen, Typografie-Anweisungen, Farben usw.). Weiterhin müssen die dynamisch ausgeführten Programme auf der Seite nachgeladen werden (z. B. unsere dynamischen Diashows, es handelt sich dabei um JavaScript-Programme). Schließlich werden auch noch die Bilder vom Server angefordert.
Der gesamte Prozess ist sehr kompliziert – wenn man das jemandem in allen Details erklärt schwanken die Reaktionen meist zwischen Ungläubigkeit („Das kann doch nicht sein, es ist doch nur eine Webseite“) und Überforderung („Geh weg, ich will dann doch lieber nur den neuen Testbericht lesen!“)
Schritt für Schritt zu schnelleren Seiten
Das Ziel ist also, die Website so schnell wie möglich auf dem Endgerät darzustellen. Wir haben dazu eine Inventur gemacht und geschaut, welche Sachen wir verbessern können, um die Performance zu steigern. Die Liste haben wir dann sortiert, sodass die Punkte mit dem besten Verhältnis zwischen Aufwand und Nutzen („low hanging fruits“) oben standen und dann begonnen diese einen nach dem anderen abzuarbeiten.
Das Ergebnis – so viel kann man schon mal vorwegnehmen – ist beeindruckend.
Die erste Aufgabe bestand darin, die angesprochene Wartezeit zwischen Anforderung und Auslieferung der Seite von circa 0,5 Sekunden bis 1 Sekunde zu eliminieren. Hierfür gibt es diverse Möglichkeiten, welche aber alle nach dem gleichen Prinzip arbeiten: die Seiten werden vorab erzeugt und zwischengespeichert. Wird dann eine Seite von einer Leserin angefordert, kann sie sofort ausgeliefert werden, da die gesamte Arbeit ja bereits vorab erledigt wurde. Das Konzept wird als „Page Caching“ bezeichnet.
Wir haben zuerst mit dem eingebauten Caching unseres Webservers nginx gearbeitet, dieses erfüllte unsere Anforderungen aber nur unzureichend. WordPress-Plugins, die diese Aufgabe übernehmen, arbeiteten ebenfalls nicht zufriedenstellend. Wir haben uns schließlich dazu entschieden, eine genau darauf spezialisierte Software einzusetzen: Varnish.
Der Software-Stack auf dem Server wird dadurch etwas komplizierter (Webbrowser und Anwendung sind immerhin fünf HTTP(S)-Verbindungen voneinander entfernt), da wir aber bei 93 von 100 Seiten die Reaktionsgeschwindigkeit des Servers um etwa den Faktor 10.000 verbessern, zahlt sich das mehr an Komplexität mehr als aus! Angeforderte Seiten werden nun anstatt rund einer Sekunde in wenigen Millisekunden ausgeliefert – der Webbrowser kann nun also augenblicklich damit beginnen, die Seite darzustellen.
An dieser Stelle setzt unsere zweite Optimierung an: Entfernen von überflüssigen, nachgeladenen Objekten, um den Seitenaufbau zu beschleunigen. Ein Großteil der WordPress-Plugins bringt eigene Style-Informationen (CSS) und JavaScript-Progrämmchen mit, welche bei jedem Seitenaufbau nachgeladen werden – auch wenn sie überhaupt nicht benötigt werden. Ein Beispiel ist unser Podcast-Plugin, welches den Web-Player zur Verfügung stellt. Im Normalzustand werden alle Dateien für den Web-Player mitgeladen, egal, ob er eingebunden ist oder nicht. Da der Podcast-Player überhaupt nur in den Podcast-Artikeln benötigt wird, ist es in nahezu 100 % der Fälle überflüssig, mehrere hundert Kilobyte Daten nachzuladen. Hier haben wir angesetzt und dafür gesorgt, dass die Player-Dateien auch nur geladen werden, wenn der Podcast-Player angezeigt wird.
Auf diese Art und Weise haben wir dann jedes Plugin geprüft und das Nachladen nicht benötigter Daten auf ein Minimum reduziert. So war es uns möglich, die Seitenladezeiten merklich zu reduzieren. Besonders schwächere Endgeräte mit nicht perfekten Internetverbindungen profitieren davon, aber auch im Webbrowser auf dem Desktop-Rechner werden die Seiten nun blitzschnell aufgebaut. Wir sind hier zwar schon ziemlich weit gekommen, aber noch nicht dort, wo wir hin möchten. Es gibt also in diesem Bereich auch noch eine Menge zu tun.
Bei eMTB-News.de und Rennrad-News.de sind wir bereits einen Schritt weiter gegangen und haben begonnen, den sogenannten „Critical Path“ zu optimieren. Im Grunde geht es dabei darum, die Seite möglichst ohne das Nachladen von weiteren Dateien darzustellen. Das ist aber aktuell noch in einem experimentellen Stadium. Wir werden da sicher 2019 noch einiges in diese Richtung verbessern, dann auch bei MTB-News.de.
Ausblick 2019
Wir haben jetzt exemplarisch drei der unzähligen Aufgaben aus 2018 oberflächlich beleuchtet, dieser Artikel ließe sich noch seitenweise fortführen. Für 2019 haben wir uns natürlich ebenfalls eine Menge vorgenommen. Eine der wichtigsten Änderungen wird das Forum betreffen: Die eingesetzte Software-Version wird seit Kurzem nicht mehr weiterentwickelt und wird ab Ende 2019 keinen Support mehr erhalten. Wir werden daher auf die neue Version 2 derselben Software umsteigen. Das ist aufgrund der sehr tiefen Integration in alle Bereich von MTB-News.de keine triviale Aufgabe, wird sich aber für euch lohnen! Das Forum wird dann auch mobil perfekt bedienbar sein und viele neue praktische Funktionen bieten.
Gibt es etwas, was du schon immer mal aus dem Maschinenraum von MTB-News.de wissen wolltest? Wir antworten gerne in den Kommentaren!
(Titelbild: Bundesanstalt für Wasserbau, lizenziert unter Creative Commons CC BY 2.0 – Originalbild)
34 Kommentare