Ok, hier in Nairobi ist “business as usual”. Also zumindest “Corona usual”. Spricht alles dafür nochmal ein WordPress Thema anzupacken. Machen wir doch da weiter, wo ich zuletzt bei der Auswahl eines Starter Themes aufgehört hatte. Nämlich, wie es sich ausgezahlt hat, genau auf dieses Pferd zu setzen. Vor allem wenn es um PageSpeed geht, hilft ein Starter Theme.
Die Kundenanforderungen
Wir brauchen eine mehrsprachige Seite, super gestyled, weil wir im künstlerischen Bereich publizieren. Das ganze muss responsive und ultraschnell sein, weil die Seite auch in langsamen, afrikanischen Mobilfunknetzen funktionieren muss. Wir sind öffentliche Hand, also bitte auch Barrierefreiheit und DSGVO beachten! Ach ja: wir gehen online am 10. Juli 2020
Sinngemässes erstes Briefing Ende Mai 2020
Aber das sind ja gleich 3 4 5 6 Wünsche auf einmal:
- multilingual
- barrierefrei
- responsive
- schnell
- gestalterisch hochwertig
- DSGVO konform
Ok, beschränktes Budget und kurzer Entwicklungszeitraum kommen nochmal oben drauf, passten aber bei uns durch die Tür. Aber schon im Rest ist klar erkennbar: da stecken ein paar Zielkonflikte drin. Wenn Bilder ins Spiel kommen, kann das mit “schnell” schon mal schiefgehen. Multilingual heisst bei mir so gut wie immer Multilingual Press (MLP3) – also Multisite. Multisite kann bekanntermassen auch eher mal zum unzähmbaren und langsamen Monster geraten. BTW: die allererste Idee an der Stelle seitens des Kunden hiess: können wir ausgehend von einer rein deutschen Version die englischen und französische automatisiert aus einem Translator Plugin ausspielen? Kann man grundsätzlich, allerdings kosten auch die API-Anbindungen an Google Translate oder Deepl Geld und der Mehrwert einer echten fremdsprachigen Version ist natürlich das ordentliche SEO. Selbst wenn die Übersetzungen z.T. auf der Basis von Maschinenversionen gemacht wurden, die dann nur noch redigiert wurden. Die Qualität der Texte ist damit aber auf jeden Fall eine Stufe besser.
Die gute und die schlechte Nachricht: Agentur hilft mit
Das ist insoweit eine wirklich gute Nachricht, als das wir hier keine Gestalter sind (noch nicht). Aufbauend auf dem Hauptprojekt bekamen wir daher die Vorgaben, wie die Seiten denn auszusehen hätten übermittelt. Die schlechte Nachricht dabei: Grafikagenturen haben nur begrenzt eine Ahnung von Programmierung. Ihnen ist schlicht nicht bewusst, welche Limits einem ein Konstrukt von Header, Content, Sidebar, Footer auferlegt. Und welchen Aufwand es bedeutet, ein paar locker flockig gezogene Striche, die aus diesem Konstrukt ausbrechen, zu programmieren. Oder auch einfach nur wegzudiskutieren. Erfreulicherweise gab es jemanden am anderen (Kunden)Ende, der das Projektmanagement in der Hand hatte und als sachverständiger Filter einiges von sich aus relativierte oder Einwände unsererseits verstand. Egal wie: bis wir die ersten Zeilen Code aus einem allseits abgestimmten Entwurf ableiten konnten, war es KW26. Das Releasedatum 10.7. wo ein virtual Event stattfinden sollte war immer noch gesetzt.
Barrierefreiheit
Das Thema Barrierefreiheit war mit dem Agentur Entwurf zumindest schon mal relativiert. Versalien an fast allen Ecken und Enden, softe Farben auf denen die Schriften sicher nicht immer den passenden Kontrast finden. Dazu ein paar Sachen, die unter Usabilitygesichtspunkten nicht gerade glücklich gewählt waren. Da helfen auch keine Labels an Elementen, die man dort schlicht nicht vermutet oder denen man auf den ersten Blick eine andere Funktion unterstellt. Immerhin: das Gutenberg Starter Theme bringt auf den ersten Blick schon mal ein paar Sachen mit, die bei der Barrierefreiheit helfen, hat aber auch da noch deutlich Luft nach oben. Es wird Zeit für die erste Ableitung davon!
Ein weiteres, das ich dabei unterwegs lernen durfte: Auszeichnungen von fremdsprachigen Texten innerhalb des Contents. Klar, MLP3 setzt die korrekten Language Tags für die Website und damit für alle darin befindlichen Posts und Pages. Was aber wenn innerhalb des deutschen Contents französische Originalzitate auftauchen? Juiz Lang Attribute heisst die Lösung, mit der entsprechende hreflang Attribute entweder für einen kompletten Post oder auch inline für einzelne Elemente im Content gesetzt werden können. Inklusive entsprechendem Menüpunkt – anders als die Pluginbeschreibung nahelegt – innerhalb von Gutenberg.
Keine Pagebuilder
Ok, mal ganz abgesehen von der zunehmenden persönlichen Aversion: das Thema PageSpeed steht dem für mich klar entgegen. Immer noch eine gefühlte Wahrnehmung, aber ich arbeite am Nachweis ;-). Gutenberg sollte im vorliegenden Fall dem Kunden genügend Gestaltungsmöglichkeiten für den Content liefern und tat dies, bis auf eine Ausnahme auch. So sehr es mir wiederstrebte, aber für ein Element “IconList” kam dann doch der komplette Kadenz Blocks da rein. Immerhin kann die ungenutzten Blocks bei Kadenz weg schalten um Benutzer nicht unnötig auf dumme Ideen zu bringen.
Schnell und responsive
Zum Glück mal eine Zielkongruenz. An der Stelle hilft es dem PageSpeed schon ungemein, ein Starter Theme einzusetzen und nicht über Child Theme Verrenkungen rein zu kommen. Alle Anpassungen laufen direkt in den Code, es müssen nicht erst Funktionen wieder aus der dequeue oder unloaded oder überfahren werden. CSS und Funktionen werden direkt in die Ausgangsbasis geschrieben. An der Stelle ein großes Dankeschön an Kirsten Schelper, die mich in SASS genötigt hat. Die Verteilung auf einzelne kleine Datei-Häppchen macht das CSS sehr gut pflegbar und logisch im Aufbau. Ein paar einfache Regeln legen den Farbraum fest (auch wenn wir unterwegs lernen mussten, dass die Prozentangaben der Agentur die Farbdichte nicht die Transparenz meinte) und der Preprozessor übersetzt alles in eine einzige CSS-Datei. Womit wir wieder beim Speed wären: so etwas lässt sich zum einen prima minifizieren und zum anderen sinkt die Zahl der Request.
Kann nur noch der Content zum Killer werden
In der Tat braucht es ein bisschen Fingerspitzengefühl um Kunden da mit ins Boot zu bekommen. Bilder müssen zumindest mal auf ein halbwegs passendes Format gestutzt werden um bei der Suche nach Geschwindigkeit nicht das Konstrukt aus der Kurve zu werfen. Texte müssen richtig strukturiert werden und Überschriften nicht nach Gestaltung sondern nach HTML-Semantik gewählt werden. Die Möglichkeiten der Fehlbedienung die Gutenberg an der Stelle bietet sind auf einer Stufe mit jedem Pagebuilder. Wenn der Kunde entscheidet H5 als erste Überschrift zusätzlich noch kursiv zu machen, dann erlaubt auch Gutenberg das. Gut das man ihn dann auf den ⓘ-Button aufmerksam machen kann, der die Gliederung aufzeigt und auf semantische Fehler hinweist.
Das Ergebnis
Die Seite ging – noch nicht in allen Belangen vollständig – am 10. Juli online. Immerhin die Desktopversion war komplett fertig gestellt, Mobil ist seit gestern vollständig und ein paar Kleinigkeiten in Sachen Barrierefreiheit kommen im Laufe dieser Woche noch dazu.
Was wir auf jeden Fall beimThema PageSpeed hilft ist das Starter Theme. Google zeigt 100 für die mobile Version, 99 für den Desktop. Auch GTmetrix liefert einen 100er PageSpeed Wert und 92 für YSlow, was wohl entweder nur mit einem anderen Server oder einem CDN zu verbessern sein dürfte. Die Zahl der Request lässt sich mit einem eigenen Theme jederzeit unter Kontrolle halten. Die Seitengröße lag am Ende bei etwas rund um 750 kB (abhängig von den Bildern, die gerade auf der Eingangsseite präsentiert werden).
Die Bilder wurden mit Imagify optimiert und in WebP Versionen übersetzt. Aus dem gleichen Haus kommt noch WP-Rocket für’s Caching dazu. Für mich das absolute Dreamteam. Cacheaufbau anhand der sitemap.xml? Oh, ich sehe Du nutzt Yoast SEO – lass uns das doch gleich mitverwenden. Ah, Du hast schon Imagify am Start – dann ist das Thema WebP dort besser aufgehoben. Solche intelligenten Dinge sind es, die mir WP-Rocket sympatisch machen.
Und nur nebenbei: mein “langsames, afrikanisches Mobilfunknetz” kommt meistens auf stabile 50 Mbit/s Up- und Download.