Sonja P. Radke bietet Beratungen, Vorträge und WorkShops zu benutzerfreundlichem Design, Website-Konzeption und Unternehmenskommunikation. Zudem schreibt sie über den Nutzen von SEO und authentischem Marketing.
Sonja P. Radke
0173. 312 99 38
Denn eine Anbindung mit 50 MBit/s hat immer noch nicht jeder, auch in der Großstadt nicht, in ländlichen Regionen erst recht nicht. Solange Deutschland beim Netzausbau hinterher hinkt, und das dürften die nächsten 3-4 Jahre sein, wird das auch so bleiben. Und dann gibt es ja noch das Smartphone: auch wenn hier die Nutzung der mobilen Endgeräte für das Abrufen von Online-Informationen noch recht bescheiden ist, verglichen mit andere europäischen Ländern oder gar den USA, so ist auch bei uns ein Trend zu erkennen, der zunehmen statt verschwinden wird. Und außerhalb von WLAN-Netzwerken, über eine mobile Anbindung, ist der Datentransfer nun mal kriechend, wobei wir als User unterwegs dazu neigen, noch ungeduldiger zu reagieren, wenn sich gefühlt minutenlang (oft sind es eher Sekunden, 10 Sek. aufwärts) ein Bild aufbaut, als wenn wir am Desktop-Rechner sitzen. Und nicht zu vergessen: google & Kollegen, Stichwort SEO. Schon 2010 hat google offiziell bekannt gegeben, dass Ladegeschwindigkeit ein Ranking-Faktor ist, mit welcher Gewichtung genau ist nach wie vor nicht bekannt und deshalb Gegenstand von Diskussionen unter Web-Experten, aber wenn google das Thema ernst nimmt und ein eigenes Tool zum Testen der Ladegeschwindigkeit anbietet (developers.google.com/speed/…), dann wird es keine kleine Rolle spielen.
Sowohl menschliche Besucher als auch Suchmaschinen bewerten das schnelle Laden einer Webseite positiv bzw. vergeben Minuspunkte, wenn das nicht der Fall ist, weshalb man sich als Betreiber und Produzent einer Website mit dem Thema befassen sollte. Abgesehen davon, dass es noch die ganzen anderen Themen gibt (SEO, Web-Strategie, Web-gerechte Texte, Conversion,…), ist auch das Thema Ladegeschwindigkeit ein komplexes, bei dem es verschiedene Aspekte zu beleuchten gilt. Das ist die anstrengende Botschaft. Die angenehme ist: diese Aspekte sind überschaubar (v.a. wenn man diesen Beitrag gelesen hat), und man muss ja auch nicht alles verinnerlichen, man beherzigt am besten das, was man überschauen und mit den eigenen Mitteln umsetzen kann, optimaler Weise gleich zu Beginn des Web-Projektes.
So, und nun zu den einzelnen Aspekten der Technischen Suchmaschinenoptimierung. In diesem Artikel finden Sie dazu folgende Themen:
Es empfiehlt sich auch bei einem Web-Projekt grundsätzlich, gleich zu Anfang ein paar grundlegende Fragen zu stellen und am besten auch zu beantworten, u.a.:
Dies sind nur einige der strategischen Fragen, die für uns (smart interactive) als Beratungs-Modul grundsätzlich immer zu Anfang eines Projektes stehen, und wir freuen uns, wenn die Kunden sich auch darauf freuen. Das sind dann unsere Wunschkunden.
Vielleicht kann man es schon erkennen, wo einige dieser grundsätzlichen Fragen auch für unser Thema Ladezeiten eine Rolle spielen: sollte sich aus der Zielkunden-Analyse ergeben, dass die potentiellen Kunden (auch) viel mobil unterwegs sind, muss man sich schon mal Gedanken zu den Stichworten responsive / mobile-Version machen, und damit auch zu Ladezeiten. Jedenfalls, wenn sich andeutet, dass es viel „schweres“ Material anzubieten gibt, in Form von reichlich Bildmaterial, Videos, Kunden-Feedback, Partner-Logos, Güte-Siegel, Share-Buttons (facebook u.a.), und weil es so viel ist, irgendwie animiert, damit man alles unterkriegt, möglichst schon auf der Startseite, oder links oder rechts (Sidebars) oder oben (Header). Was designtechnisch und bezüglich Nutzerführung Sinn machen kann, kann aber schnell die Ladezeiten stark belasten. Wo und warum, das kommt jetzt:
Ein Webserver-Paket mit den technischen Grundanforderungen (PHP + MySql-Datenbank) ist bei jedem Provider als Standard kostengünstig zu bekommen, irgendwas zwischen 4 und 8 EUR / Monat. Für kleine Budgets und kleine Websites ist das meist ausreichend, man kommt aber schnell an seine Grenzen, wenn man etwas höhere Ansprüche stellt, auch bezüglich Ladezeiten. Denn die günstigen Web-Pakete sind in der Regel Shared-Hosting-Plattformen und das bedeutet, man teil sich die Rechner-Kapazitäten mit anderen Webseiten-Betreibern. Und in der Hosting-Welt gilt noch mehr als in der normalen Welt: man kann sich seine Nachbarn nicht aussuchen, man kennt sie nicht einmal, wenn z.B. der Nachbar einen Online-Shop betreibt mit einem hohen Datentransfer und vielen Besuchern, dann bleiben auch für die eigene Website wenig Ressourcen für Arbeitsspeicher, CPU und Festplatten-Zugriffe übrig. Deshalb empfiehlt sich aus technischen wie auch strategischen Gründen, auf einen sogenannten dedizierten Server oder Root- bzw. Managed-Server zu wechseln.
Hier fängt das Thema spätestens an techniklastig zu werden, denn jetzt gibt es noch mehr technische Optionen, die mit den eigenen Ansprüchen abzustimmen sind: was möchte man als Endkunde, oder als Web-Dienstleister für den Endkunden (also z.B. wir | smart interactive), elementare Module seitens des Betreibers warten / updaten lassen (Managed Server), oder alles selber machen können (root-Server), und dafür auch erweiterte Eingriffsmöglichkeiten zu bekommen. Die Stichworte hier lauten u.a. PHP/ php.ini, ModRewriteModul / htaccess / Reverse-Proxy-Server, Gzip. Alles Schrauben, an denen man drehen kann, gerade an der php.ini, wobei jeder Provider seine eigenen Regeln dafür hat, und man deshalb bei jedem einzeln nachfragen muss, wenn man es genau wissen will. Einiges steht oft auf der Website des Providers, z.B. unter den FAQs, vieles aber muss man beim technischen Support erfragen.
Und das ist schon das nächste Stichwort: beim Thema Ladezeitengeschwindigkeit kann es bedeutsam sein, dass man nicht nur schnellen sondern vor allem qualifizierten Support bekommt. Hier gehört auch Glück dazu, gute Ansprechpartner sitzen fast überall, bei dem einen Anbieter braucht man halt etwas mehr Glück, bei einigen bestimmten Anbietern braucht man auf dieses Glück gar nicht erst zu hoffen, was aber eher daran liegt, dass die technischen Voraussetzungen einfach nicht gegeben sind, da kann dann auch der motivierteste Mitarbeiter nicht helfen: wenn z.B. kein ModRewriteModul möglich ist. Worst Case aus unserer Sicht als Web-Dienstleister ist, wenn unser Kunde sagt, „Unsere Website läuft irgendwie bei der Telecom | Netcologne“. Denn wenn man bei deren Support nachfragt, kriegt man von diesem selbst zu hören, dass sie ja eigentlich gar keine „richtigen“ Provider sind, Hosting bieten wir „auch“ an, mit den technischen Möglichkeiten ist man aber sehr schnell am Ende. Und ein Server- / Provider-Wechsel hat immer das Potential für einen anstrengenden Akt, auch für den Endkunden, gerade die Neueinrichtung der Email-Konten ist kundenseitig oft der Grund, beim alten Provider zu bleiben.
Hat man mit einem leistungsstarken Webserver die nötige Voraussetzung geschaffen, kann man sich nun Gedanken machen, welche Möglichkeiten und Module Sinn machen. Als erstes sei das Pagespeed-Modul von Google genannt, allerdings eher der Vollständigkeit halber. Denn selbiges ist (noch) zu fehleranfällig und bewirkt zum Teil das Gegenteil, also eine langsamere Ladezeit. Mehr anfangen kann man da schon mit dem Pagespeed-Tool von Google (developers.google.com/speed/…), mit welchem sich die Ladegeschwindigkeit einer Website messen lässt und welches gleichzeitig anhand einer Analyse diejenigen Schwachstellen aufzeigt, bei denen Optimierungspotential besteht.
Eine effektivere Option ist die Nutzung eines Reverse-Proxy-Servers, der vom Hoster eingerichtet werden muss. Idee hierbei: statische Inhalte (immer wiederkehrende Bilder / Logo, javascript-Dateien, u.a.) werden auf den Proxy-Server ausgelagert, der normale Webserver wird dadurch deutlich entlastet und kann sich auf die neuen Anfragen konzentrieren. Nicht zu unterschätzen ist die Frage, was denn genau diese statischen Inhalte sind. Klassischerweise werden dazu das Logo als Bilddatei oder die CSS-Datei, welche für Aussehen und Aufbau einer Webseite zuständig ist, bei diesen beiden Elementen geht man davon aus, dass sich hier nicht viel bis nichts mehr ändert, weil Webdesign und Corporate Identity (zu dem das Logo gehört) schon längst festgelegt worden sind. Wenn man aber dazu neigt, regelmäßig am Webdesign herum zu schrauben, schon allein um den stetigen aktuellen Entwicklungen bezüglich User-Erwartungen und Programmiertechnik gerecht zu werden, dann muss man auch an die CSS-Datei ran, und dann kann es gut sein, dass die aktuellen Änderungen nicht beim User ankommen, weil sie eben noch auf dem Proxy-Server liegen. Oder im Browser-Cache. In letzteren verfrachtet der Browser auch Bild-, CSS- und Javascript-Dateien. Man kann aber auch steuern, welche Dateien bzw. Dateitypen wie lange im Cache verbleiben sollen, bis sie auf Aktualität geprüft werden. Das geht über entsprechende Caching-Angaben im Header-Bereich, wofür es wiederum verschiedene technische Ansätze gibt. Direkt im html-Header einer Webseite kann man für den Tag cache-control die Parameter max-age und expiry-date definieren, also angeben, wie lange bzw. bis was im Cache bleiben soll. Eine andere Möglichkeit ist diejenige über htaccess oder PHP. Über die htaccess-Datei lassen sich auch die beiden Parameter Last.modified und ETag (für entity-tag) setzen, auch in Kombination mit max-age. Über einen Vergleich des in diesem Wert gespeicherten Datums mit demjenigen Daum im Browser-Cache lässt sich für den Browser feststellen, ob er die Date aus dem lokalen Cache nehmen soll oder, weil Verfallsdatum überschritten, neu vom Server.
In jedem Fall ist hier der Web-Programmierer gefragt, was wieder unpraktisch ist, weil in der Regel Redakteure die Inhalte beisteuern, zu denen auch Bilder gehören, und eher wissen, wann und wie regelmäßig was im Cache landet. Gut wäre, die Werte regelmäßig zu prüfen und anzupassen, ob dieser regelmäßige Pflegeaufwand, für den schon mindestens Web-Programmierer und Redakteur gefragt sind, im gewohnten Workflow unter zu bringen sind, muss man als Web-Dienstleister zunächst mit sich selbst und auch dem Kunden ausmachen.
An dieser Stelle sei auch die Keep-Alive-Funktion erwähnt, zur Aufrechterhaltung von TCP-Verbindungen, womit die Anzahl der Abfragen verringert, der Speicherverbrauch allerdings deutlich erhöht wird. An dieser Stelle wäre abzuwägen, wie viel man in Arbeitsspeicher investieren will.
Nächstes Stichwort: php5-memcache. Damit sind wir beim Thema PHP angekommen. Serverseitig lässt sich das benannte Modul einrichten und den eigenen Anforderungen gemäß konfigurieren, anschließend kann man über die PHP-Programmierung Anfragen, z.B. an eine Datenbank, zwischenspeichern und beim nächsten Aufruf diese Anfrage nochmal, ab jetzt schneller verwenden. An diesem Punkt muss die Praxistauglichkeit überprüft werden: es geht um die Frage, wie viele genau gleiche Anfragen sind in welchem Zeitraum zu erwarten? Was nicht zuletzt davon abhängt, wie viele aktuelle Inhalte man selbst produziert bzw. Varianten davon. Wenn man z.B. eine Suchfunktion auf der Webseite anbietet, dann ist eine Such-Anfrage nach „web-design“ eine andere als nach „webdesign“. Und es macht einen Unterschied, ob man alle vier Wochen einen News-Artikel einstellt, der dann auch mal 1h später als veröffentlicht bei dem einen oder anderen User ankommen kann, oder ob man täglich was veröffentlicht, was dann aber in Echtzeit und nicht erst 1h später bei jedem User ankommen sollte. Und nicht zuletzt zu bedenken: all das macht nur Sinn, wenn man alles selber programmiert, auch die php-Abfragen, was inzwischen aber nicht mehr Realität ist. Für redaktionell gepflegte Webseiten gibt es OpenSource-CMS-Systeme, wie WordPress, TYPO3, Drupal und Contao, und diese bringen ihre eigenen Abfragen mit, dass man an diesen rumschraubt ist auch für Programmierer weder vorgesehen noch ratsam.
Ein weiteres Modul, über welches man sich weniger Gedanken machen muss, außer, dass der Hoster es eingeschaltet haben sollte, ist die Gzip-Funktion. Dabei geht es um einen „Handshake“ zwischen Browser (von denen 99% Gzip unterstützen) und Webserver. Letzterer verpackt Dateien (auch Bilddateien) ins gzip-Format, wodurch die Dateigröße teils um ein Vielfaches verringert wird. Also, beim Hoster nachhaken und einschalten (lassen).
Bislang haben wir uns vornehmlich damit beschäftigt, was man bei der Konzeption in strategischer Hinsicht und auf dem Server in technischer Hinsicht machen kann, beides eher abstrakte Themen. Das ist wichtig, weil viel Potential, aber ein weites Feld, in dem vieles mit vielem zusammen hängt und deshalb für normale Menschen, sprich Endkunden, schwer zu verinnerlichen ist.
Greifbarer dagegen, weil unmittelbar sicht- und messbar ist das, was man redaktionell an den Inhalten machen kann. Eine Webseite mit viel „schwerem“ Inhalt lädt länger. Dass es weniger die Textlänge ist, die hier zu Buche schlägt, sondern eher eingebundene Bild-Dateien, ist auch jemandem, der sich „mit sowas“ gar nicht auskennt, schnell vermittelbar, denn bei einem Bild kann man direkt nachschauen, wie viel KByte bzw. Mbyte dieses hat – und 3,4 MB laden logischerweise langsamer als 34 KB. So offensichtlich das ist, so wenig selbstverständlich wird dies berücksichtigt, man findet allzu oft in redaktionell angelegten Blog-Artikeln eingebundene Bild-Dateien mit dem Namen DC23456767.JPG, 4MB groß, also offensichtlich unbearbeitet frisch aus der DigiCam auf den Webserver hoch geladen. Das passiert, wenn suboptimal beratene normale Menschen ihrem verständlichen Wunsch folgen, einen gerade fertig geschriebenen Text mit dem gut gelungenen Schnappschuss möglichst schnell an die Öffentlichkeit zu bringen. Noch drei weitere Bilder dieser Art in den Text eingebunden, und die Seite lädt auch bei schneller Anbindung spürbar langsam, sodass es schon weh tut. Damit solche Dinge nicht passieren, legen wir (smart interactive) Wert darauf, nicht nur Webseiten als Endprodukt an unsere Kunden auszuliefern sondern auch eine umfassende Beratung, wie man mit diesem Produkt umgeht, auch wenn der Beratungsanteil letztendlich einen entsprechend großen Anteil vom Gesamtbudget ausmacht. Aber diese Investition lohnt sich, wenn man die Webseite zu einem effektiven Teil der eigenen Marketing-Strategie machen will. Aber zurück zum Thema Bilder…
Auch wenn CMS-Systeme die mehr oder weniger ausgefeilt Möglichkeit bieten, Bilder auch nach dem Hochladen noch zurecht zu schneiden, empfiehlt es sich, diese schon vor dem Hochladen anzupacken, Stichwort Bildbearbeitung. Für Web-Dienstleister ist das ein gewohnter Vorgang, Bild mit gewohntem Bildbearbeitungsprogramm, meist Photoshop, öffnen, drei bis vier Klicks, SEO-tauglichen Dateinamen vergeben und die Mindestanforderungen sind erfüllt. Für normale Menschen fängt es schon damit an, dass sie in der Regel keine Bildbearbeitungs-Software installiert haben und sowas auch noch nie gemacht haben. Also muss man Ihnen erklären, dass man erstmal etwas installieren und sich mit der neuen Software etwas beschäftigen muss, bevor das erste Bild dann endlich hochgeladen ist. Es muss ja nicht Photoshop sein, es gibt auch Freeware-Tools wie Photofiltre, die mindestens die Grundanforderungen erfüllen.
Soweit so gut. Aber es geht noch besser. Denn sowohl Photoshop als auch andere Software sind auf schöne aber nicht schnell ladende Ergebnisse spezialisiert, unser eigentliches Thema. Inzwischen gibt es entsprechende Software bzw. Online-Dienste, zu nennen sind hier gimp, jpegmini und tinypng. Bei jpegmini und tinypng kann man schon aus dem Namen erlesen, worauf sie sich spezialisiert haben, nämlich auf das jeweilige Dateiformat jpg und png. Bedeutet auch, dass sie nicht beides können und man beide braucht, wenn man beide Formate bedienen will, und das will man. Gimp kann beides, jedenfalls in der Bezahl-Version. An dieser Stelle sei verzichtet auf eine detaillierte Beschreibung dessen was diese Tools jeweils können. Wenn man sich näher mit ihnen beschäftigt, kommt man schnell darauf, dass es hier einiges auszuprobieren und abzuwägen gilt, das Hauptziel ist nach wie vor Datenreduzierung, aber eben möglichst ohne Qualitätsverlust (offizielle Angaben: jpegmini bis 80%, tinypng bis zu 67%). Die gute Nachricht: das geht gerade bei jpgs durchaus, wenn man die Datengröße aber noch weiter runter schrauben will, muss man Prioritäten setzen. Z.B. entfernt tinypng die META-Daten der Bild-Datei, die man aber evtl. behalten will, weil CMS-Systeme diese auslesen und verwerten können. Womit wir bei einer weiteren Möglichkeit wären, nämlich wenn man die von dem jeweiligen CMS gebotenen Zusatz-Features nutzt. Für WordPress-basierte Websites gibt es z.B. das Plugin Optimus, welches Bilder beim Hochladen automatisch komprimiert. Das macht WordPress auch so schon „irgendwie“, mit dem Ergebnis ist aber nicht jeder Web-Designer oder Fotograf glücklich. Also auch hier gilt: ausprobieren und abwägen, wenn alle glücklich werden sollen (Designer, Programmierer, Endkunde, Fotograf, Google) muss halt noch ein wenig mehr ins Detail geschaut und länger abgewogen werden.
Nach Bildern sind PDF-Dateien wohl das in Webseiten meist eingebundene Dateiformat, wobei das nicht ganz korrekt ist, weil sie nicht direkt eingebunden sondern nur verlinkt sind. Heißt, eine Seite mit einem PDF-Link muss nicht die PDF-Datei laden, solange man nicht auf den Link klickt. Da Google aber auch PDFs und deren Textinhalt auslesen kann (jedenfalls wenn man z.B. einen Zeitungsartikel nicht als Bild eingescannt hat), spielen diese auch für das Ranking der Webseite eine Rolle, und auch der User freut sich, wenn ein 150seitiger PDF-Katalog mit Hochglanzbildern dann doch mal geladen ist. Hier gibt es vielleicht aber auch ein Missverständnis: Solch ein PDF ist meist eine Druckvorlage für einen gedruckten Katalog und wo man diese schon mal hat, stellt man sie eben auch schnell auf der Webseite als Download zur Verfügung. Allerdings geht es in der Regel nicht darum, dass der User diesen Katalog in entsprechend hoher Qualität auf seinem Heimdrucker nachdruckt sondern darum, dass er diese Datei als Informationsquelle auf seinem Rechner zur Verfügung hat und nur eventuell das Ganze oder Teile davon ausdruckt, für auf dem Sofa zum Lesen. Dafür müssen aber auch die Bilder nicht in Original-Qualität daher kommen, aus der Druckvorlage sollte eine Web-optimierte Version erstellt werden mit entsprechend geringer Datenmenge. Dazu braucht man Software, klassisch den Acrobat, nicht zu verwechseln mit dem Acrobat Reader, den jeder kostenlos installieren kann. Acrobat kostet was, damit kann man aber nicht nur PDFs lesen sondern u.a. die Datei komprimieren. Es gibt noch mehr Möglichkeiten, die aber hier zu weit führen würden, weil, weites Feld. Kurz erwähnen möchte ich aber das Stichwort PageFlip, welches für verschiedene meist kommerzielle Tools steht, mit denen man PDF-Dateien als Basis zu Online-Durchblätter-Funktionen nutzen kann, mit netten Umblätter-Effekten. Was das für unser Thema Ladegeschwindigkeit bedeutet, vielleicht in einem weiteren Beitrag.
Während so gut wie keine Webseite ohne Bilder auskommt, und wenn es nur das Logo ist, findet man Videos zwar immer noch nicht auf jeder Webseite, macht ja auch nicht überall Sinn, macht aber für mehr Webseiten und deren Betreiber Sinn als diese glauben. Und weil auch jedem klar sein dürfte, dass eine Video-Datei noch größere Datenvolumen beinhaltet als eine Bild-Datei, sind wir hier natürlich beim Thema Ladegeschwindigkeit. Gleich vorab: eine inzwischen übliche Form der Einbindung von Videos ist die über Youtube. Und da Youtube beim Hochladen schon einiges an Vorarbeit bezüglich Web-gerechter Aufarbeitung leistet, und man auf der eigenen Webseite dann diese externe Quelle nur noch über einen iframe einbettet, ist das Thema Ladegeschwindigkeit gar kein soo großes mehr, das läuft dann schon, auch mit Streaming. Andererseits ist hier natürlich auch ohne Ende Potential drin, man muss nicht Youtube alle Entscheidungen überlassen, dafür muss man sich natürlich mit dem Thema Videobearbeitung beschäftigt haben. Auch kein Hexenwerk, aber auch hier gilt, je mehr man sich damit beschäftigt und je höher die Ansprüche werden, auch Richtung Ladezeiten-Reduzierung, weiter wird das Feld. Dann kommt man z.B. auch an den Punkt, ob man für Großbildschirme und Smartphones das gleiche Video mit entsprechenden Kompromissen anbieten soll, auch für die Fullscreen-Ansicht, oder doch für beide eine jeweils optimierte Version. Zudem gibt es ja auch immer noch den Fall, dass man ohne Youtube auskommen will, z.B. weil man die Kontrolle über seine Videos behalten und nicht von diesem Konzern abhängig sein möchte, spätestens ab diesem Zeitpunkt muss man sich nicht nur mit Video-Bearbeitung sondern auch mit der Einbindung bzw. dem Abspielen beschäftigt haben. Seit html5 gibt es einen Video-Tag, der genau dies ermöglicht, aber eine Garantie, dass jeder Browser mit dem ausgewählten Dateiformat (mp4, Quicktime) und der Art der Komprimierung zu recht kommt, gibt es nicht. Der übliche Weg, Video-Dateien einzubinden und abzuspielen, war bis Sommer 2015 noch Flash, doch spätestens seitdem Android-smartphones Flash aus Sicherheitsgründen aussortiert hat, ist diese Technik tot.
Der effektive Umgang mit dem Quellcode von Html, Css und Javascript ist für Web-Programmierer die direkteste Möglichkeit, an der Ladegeschwindigkeit zu drehen. Zu Zeiten, als man noch fast jede Zeile selbst geschrieben oder zumindest aus dem eigenen Projekte-Steinbruch copy-paste-mäßig übernommen hat, hatte man noch alles irgendwie im Blick und wusste was passiert, wenn man an dieser oder jenen Schraube dreht. Seit Responsive und einer zunehmend unüberschaubaren Anzahl von Display-Formaten sind die Anforderungen jedoch so komplex und dynamisch geworden, dass es einfach kein effektiver Arbeitsablauf mehr ist, nach jeder neu auf dem Markt erschienenen Smartphone-Generation mit neuen Formaten alle Fälle neu zu eruieren und die Programmierung daran anzupassen. Schneller geht es, sich in sogenannte Frameworks wie Bootstrap und Foundation einzuarbeiten, und die Vorarbeit von deren Machern zu nutzen. Heißt aber auch: selbst nicht mehr alles im Blick zu haben, was da so programmiert wurde, und einiges an Quellcode gerade in der CSS-Datei mit rumschleppen, was gar nicht benötigt wird. Hinzu kommt, dass in der Regel ein CMS hinter einer Website steckt, für welches wiederum zahlreiche Plugins installiert wurden, alles eigenständige Zusatzsoftwaren, die ihren eigenen Code mitbringen, der nicht immer optimal angelegt ist, auch nicht in Bezug auf Ladezeitengeschwindigkeit. Dennoch kann man auch und gerade hier einiges rausholen, v.a. wenn man einige Grundregeln beachtet, und das schauen wir uns jetzt genauer an.
Auch an dieser Stelle sei nochmal erwähnt: das Thema Ladezeit fängt nicht erst mit der Umsetzung an, hat man dies bereits bei der Konzeption in den Fokus geholt und sich auch aus anderen Gründen für einen schlichten Aufbau und ein unkompliziertes Design entschieden, ist es um so einfacher, einen schlanken Html-Code mit wenigen Zeilen zu produzieren. Da Ladezeit aber nun mal auch andere Kriterien wie ansprechendes Erscheinungsbild und die Präsentation wichtiger Infos eine Rolle spielen, muss man schauen, dass man auch einen komplexeren Aufbau in möglichst wenige Zeilen bekommt. Und mit Html5/Css3 geht das inzwischen noch besser. Hier reicht es, die „neuen“ technischen Möglichkeiten konsequent zu nutzen, im Html-Code selbst mit möglichst wenig Zeichen und Zeilen auszukommen und die Gestaltung mehr über Css-Anweisungen zu steuern. Die Navigation z.B., in der Regel eine „Ungeordnete Liste“ (Html-Sprache), muss nicht unbedingt in einen eigenen Div-Container platziert werden, um sie zu positionieren, das kann man auch über die Liste selbst oder den neuen Html-Tag „nav“ für Navigation machen – wieder 1-2 Zeilen gespart. Insgesamt ist das Einsparpotential bei Html eher gering, spannender wird es bei Css und Javascript, das wir uns deshalb etwas ausführlicher anschauen.
Für Aufbau und Aussehen einer Webseite ist maßgeblich Css zuständig, eingebunden über eine oder – und das ist schon gleich das erste Thema – mehrere Css-Dateien. Denn von der Html-Seite aus wird auf eine andere Datei referenziert, eben die Css-Datei, und das Laden einer anderen Quelle kostet immer Ladezeit, je mehr einzelne externe Quellen desto länger die Ladezeit. Das gilt übrigens auch für Javascript-Dateien, und auch jedes einzelne Bild ist eine eigenständige Datei, die referenziert und eingebunden werden muss. Also: besser eine Css-Datei, z.B. style.css, als drei oder vier, wozu man als Programmierer schon mal neigt, um einen besseren Überblick zu behalten, wenn man die Anweisungen verteilt auf Themengebiete wie Grundgerüsteinstellungen (main.css), Schrifteinstellungen (font.css) und Druckeinstellungen (print.css). Auch wenn in Summe gleich viele Code-Zeilen dabei raukommen, schneller ist wenn nur eine Datei abgerufen werden muss. Offiziell (laut HTTP/1.1-Standard) können nur zwei Ressourcen gleichzeitig von einem Browser geladen werden, alle anderen kommen in die Warteschleife, inzwischen schaffen die meisten Browser zwischen sechs und acht, worauf man sich aber nicht verlassen sollte, und auch diese Anzahl ist ja eine begrenzte. Womit wir auch beim Praxis-Check wären: denn in der Praxis baut man eine Webseite in der Regel nicht von Grund auf neu sondern setzt auf Frameworks, Plugins, Tools und CMS-Systeme, wie schon oben beschrieben. Würde man alles selber programmieren, könnte man alles überblicken und berücksichtigen und wenn dann was hakt schnell die Ursache finden. Setzt man ein Framework wie Bootstrap ein, hat man auch noch alles im Blick, es ist eben die eine bootstrap.css, und eventuell eine Theme-Datei, die man beide zusammen fassen kann. Baut man auf ein CMS, z.B. WordPress, wird die Sache schnell komplizierter, weil hier zahlreiche Plugins mit an Bord sind mit einer jeweiligen Eigendynamik auch bezüglich Css/Javascript, doch dazu mehr im nächsten Abschnitt.
Nochmal zu dem Punkt, möglichst wenige Dateien einbinden, Stichwort Css-Sprites. Dies steht für die Verwendung von Icons (Pfeile, Bulletpoints, Drucker-Symbole), die nicht als einzelne Bilddateien angelegt werden sondern nur als eine einzige, vorstellbar als eine Tafel mit allen Icons, von der nur immer der Ausschnitt mit dem entsprechend gewünschten Icon angezeigt wird. Nachteil: wen man an nur einem Icon was ändern, oder eins dazu haben will, muss man diese eine Datei pixelgenau bearbeiten und das Css anpassen, ein mühseliger Akt. Auch wenn es inzwischen mit Unicode-Symbolen Alternativen zu Bildern als Icons gibt, ganz ohne Bilder kommt man nicht aus, gerade wenn man individuell bleiben möchte, aber man sollte sich die Unicode-Möglichkeiten mal anschauen.
Nächstes Stichwort: Minify. Damit ist die Kompression von Css- aber auch Javascript-Dateien gemeint. Gerade bei großen Dateien fallen natürlich auch viele Leerzeichen, Leerzeilen und Zeilenumbrüche an, die dem Programmierer den Überblick ermöglichen, vom Browser aber nicht benötigt werden. Entfernt man diese, erhält man einen kaum verwendbaren Brei an Quellcode, der aber wieder ein paar Kilobytes eingespart hat. Ändert man dann doch regelmäßig etwas am Design, und damit auch an der Css-Datei, kann das schon mühselig werden, immer erst dekomprimieren und wieder komprimieren, das gilt es wieder abzuwägen, ob sich der bescheidene Gewinn bei der Ladezeit rechnet gegenüber dem Aufwand in der Pflege.
Viele Aspekte, die für Javascript gelten, sind bereits unter dem Thema Css besprochen worden, weil beide ähnlich funktionieren: Javascript wird wie Css als eigene Datei eingebunden, am besten nur eine statt viele, und auch eine Javascript-Datei lässt sich komprimieren, mit den benannten Vor- und Nachteilen. Ein paar Unterschiede gibt es aber dennoch, z.B. den, dass man ohne Css definitv nicht auskommt, über den kompletten Verzicht von Javascript für ein Web-Projekt kann man aber auf jeden Fall nachdenken. Denn seit Css3 kann man auch darüber einiges bewegen und animieren, speziell für Mouse-over (hover)-Effekte. Hat man sich dieses ehrgeizig-spartanische Ziel gesetzt, „no javascript“, hat man sich auch gleich das gesamte Thema Ladezeit-Javascript gespart. Und das kann (muss aber nicht) ein noch kniffligeres werden als Css. Denn bei Css gibt es hauptsächlich Angaben, wie etwas aussehen soll, bei Javascript gibt es die Möglichkeit, dass etwas passieren kann (bzw. genau dafür gibt es das), bei Maus-Klick z.B. oder wenn die Seite geladen wird, und dann kann noch was weiteres passieren, und das Ganze ab einem bestimmten Zeitpunkt und / oder über einen bestimmten Zeitraum. Da gibt es viel voraus zu sehen für einen Browser, immer in jetzt-was-machen-müssen-Haltung, sobald Javascript auftaucht, und das kostet Ladezeit. Nicht unwichtig ist auch, an welcher Stelle der Code eingebaut wird, standardmäßig im Header, weil die Javascript-Funktion aber evtl. nicht gleich zu Beginn gebraucht wird, auch schon mal erst am Ende der Seite, im Footer, damit der Inhaltsbereich der Seite schneller geladen wird. Oder an der Stelle im Inhaltsbereich, wo sie konkret gebraucht wird, z.B. an der Stelle, wo ein kleines Bild (Thumbnail) in Großansicht „frei über Seite schwebend“ (Lightbox) angezeigt werden soll.
Ein guter Zeitpunkt, um jquery als Stichwort ins Spiel zu bringen. Denn wenn wir über Javascript reden, dann steckt in der Praxis meist Jquery als Framework dahinter. Vom Prinzip her wieder ähnlich wie Css /bootstrap: es gibt eine Haupt-Datei, die eingebunden wird (jquery.xxx.js), damit alleine lassen sich schon einige Effekte wie toogles erzielen, für spezielle Features wie Lightboxen oder Slideshows gibt es dann wieder Plugins. Von denen hat man dann entweder schon welche ausprobiert und Erfahrungswerte gesammelt, auch bezüglich Ladezeit, oder sucht neue nach bestimmten Kriterien, und stößt dann auf Seiten wie „die 10 coolsten / neuesten / schnellsten Jquery-Content-Slider“. Dort hat schon jemand Test-Vorarbeit geleistet, auch in Form von Kurzbeschreibungen, was das jeweilige Plugin zu bieten hat. An dieser Stelle schon bei der Suche kann man jedenfalls den eigenen Fokus setzen, in unserem Fall auf Ladezeit, und sich dasjenige genauer anschauen, dessen Hauptmerkmal „leicht“ (lightweight) und nicht „kann sehr viel“ ist. Wenn man hier eher nach „der Einblendeffekt ist aber sehr elegant“ oder „die vor-zurück-Buttons sind schön“ geht, steht man evtl. später, nachdem man alles eingebaut und angepasst hat, da und stellt fest, dass das ganz schön lange lädt, und man von den 159 tollen Effekten nur einen nutzt, und zwar den schlichtesten. Ein weiterer Tipp: die neueste Jquery-Version verwenden, und bei der Renovierung älterer Web-Projekte auch eine neuere Version einbinden (und natürlich nachher Funktionalität checken), denn die Macher haben das Thema Ladezeit durchaus auf dem Schirm, heißt, neuere Versionen laden schneller als ältere.
Zudem lohnt es sich, die Menge der Jquery-Effekte im von vornherein, bei der Konzeption, im Blick zu behalten: ein Content-Slider im Header, ein Kundenstimmen-Slider in der rechten Sidebar, eine Mini-Bilder-Galerie mit Lightbox im Footer, dann noch ein Kontakt-Formular in der linken Sidebar (mit jquery-Abfrage bei der Eingabe), da hat man schon einiges an jquery zusammen. In Hinblick auf die Aufmerksamkeitslenkung des Webseiten-Besuches mag das sinnvoll sein (Conversion), das Thema Ladezeiten hat man damit auf der Prioritätenliste aber nicht auf Platz eins gesetzt.
Also: schon in der Konzeptionsphase auf der Prioritätenliste das Thema Ladezeit und Javascript / Jquery nicht vernachlässigen.
Bislang haben wir von Dateien gesprochen, die eingebunden werden (Css, Jquery, Bilder), und dabei unausgesprochen gelassen, von wo aus diese Dateien eingebunden werden. Klassischerweise liegen diese auf dem gleichen Webserver wie die Webseite bzw. die Html- oder PHP-Dateien auch, entweder im Root-Verzeichnis selbst oder in entsprechenden Unterverzeichnissen (/css/style.css, /js/jquery.js), jedenfalls „im gleichen Haus“. Der Browser muss nicht noch auf einem anderen Server unter einer anderen Domain suchen, was Zeit kostet, Stichwort: DNS-Optimierung. DNS steht für Domain Name Service, was für die Übersetzung von Web-Adressen (z.B. smart-interactive.de) in IP-Adressen durch einen Nameserver steht. Je mehr externe Webserver-Adressen übersetzt werden müssen, umso mehr Ladezeit. Das ist zwar kein kriegsentscheidender Faktor, weil auch bis zu 10 DNS-Anfragen in wenigen 100 Millisekunden verarbeitet werden können, aber solche Anfragen können sich häufen, v.a. wenn man nicht alles selbst programmiert sondern eher als Features einbindet. Klassisches Beispiel sind Share-Buttons von Google+, Twitter und Facebook, die auch vom Webserver dieser Anbieter aus eingebunden werden können, statt eigene Icons auf dem eigenen Webserver zu verwenden – wären schon mal drei DNS-Abfragen. Und wenn man eine Sharing-Leiste mit sämtlichen Social-Media-Betreibern haben will, summiert sich das eben. Bilder sollten ebenfalls, selbst wenn aus externen Quellen stammend, vom eigenen Webserver aus geladen werden, auch wenn es gerade für Redakteure schon mal leichter erscheint, den externen Bildpfad direkt in den Quellcode einzubauen statt das Bild herunter zu laden, per FTP oder CMS auf den eigenen Webserver zu laden und dann erst einzubinden. Auch hier wieder: als Einzelfall gerade noch o.k., bei vielen Bildern aus verschiedenen Quellen irgendwann nicht mehr.
Weitere typische externe Quellen, die gerne von externen Servern geladen werden, sind Jquery-Dateien oder google-Webfonts, erstere kann man über google einbinden (https://ajax.googleapis.com/…). Da es nur eine Datei ist, ist die externe Einbindung vertretbar. Auch die Einbindung von Web-Fonts von google ist o.k., man möchte das breite Spektrum der Schriften schließlich nutzen, wofür auch nur eine weitere DNS-Anfrage nötig ist. Hier lohnt es sich eher, bei der Zusammenstellung der Schriften auf den Pageload-Tachometer zu achten, den google netterweise recht prominent platziert hat. An dieser Stelle ist gut zu wissen, welche Schriften und in welchen Schnitten / Varianten man überhaupt einsetzen will. Hat man dies in einem Styleguide oder Design-Konzept klar benannt, ist man an dieser Stelle schnell durch, wenn man erst alle Photoshop-Dateien checken muss, was alles so benötigt wird, dauert es jetzt länger. Ziel sollte sein, im grünen Bereich des Tachometers zu bleiben, dazu sollte man am besten mit höchstens zwei Schriftarten auskommen und sich überlegt haben, ob man auch den fettesten und dünnsten Schnitt braucht, und alles auch in kursiv (italic).
Wie schon mehrfach kurz angesprochen: meist ist es ein CMS, welches hinter einer Website steckt, und je schneller man Standard-Vorlagen und Einstellungen übernommen hat, um so schneller hat die Kontrolle abgegeben und auch das Thema Ladezeit aus den Augen verloren. Nehmen wir als Beispiel-CMS WordPress, weil wir selber hauptsächlich selbst damit arbeiten und weil es (nicht von ungefähr) das inzwischen wohl meist eingesetzte OpenSource-System ist. Jedes WordPress-Web-Projekt basiert auf einer Vorlage, einem sogenannten Theme, und schon an dieser Stelle wird eine Grundsatzentscheidung getroffen: greift man auf ein vorbereitetes Theme zurück, ob nun OpenSource oder ein gekauftes, oder entwickelt man sein eigenes, v.a. wenn ein individuelles Design umgesetzt werden soll? In ersterem Fall sollte man bei der Auswahl das Kriterium Ladezeit in die Anforderungsliste mit aufnehmen, vielmehr kann und sollte man bei einem fertigen Theme auch nicht machen, so jedenfalls die Idee dabei.
Bei eigens entwickelten Themes sieht das schon anders aus, da hat man als Programmierer weitreichende Möglichkeiten, fast wie ohne WordPress. Aber eben nur fast, denn keine Theme-Eigenentwicklung kommt ohne Plugins aus, selbst wenn man sich vorgenommen hat möglichst wenige einzusetzen, an einigen kommt man kaum vorbei, z.B. dem SEO-Plugin von Yoast oder Sicherheits-Plugins (z.B. iThems Security) oder einem Kontakt-Formular-Plugin (z.B. Contact Form 7). Leider haben die meisten Plugins das Thema Ladezeit oder effektiven Code-Aufbau nicht im Fokus, was man schnell an der Masse von Javascript- und Css-Dateien und Code erkennt, teils mitten im Inhaltsbereich, der sich nach der Installation der ersten zwei bis drei Plugins im Quellcode finden lässt. Da kommt schon mal schnell was durcheinander, weil sich die Plugins ja meist auch gegenseitig nicht kennen, ein Problem-Klassiker. Wenn man dann hier was zusammen fasst, und dann was nicht funktioniert, weil die Reihenfolge von Css- und Javascript-Dateien z.B. für ein Slideshow-Plugin nicht mehr passt, kann die Ursachenforschung schon mal langwierig werden.
Was kann man machen? Bei der Recherche nach Plugins, z.B. für ein Kontakt-Formular, neben den anderen Kriterien wie Design, Abfrage-Feedback bei Ausfüllen oder weitereichende Verarbeitungsmöglichkeiten der Daten nach dem Abschicken, auch Ladezeit mit aufnehmen. Das macht aber schnell keinen Spaß, weil wie gesagt kaum ein Plugin das auf dem Schirm hat und man erstmal installieren und ausprobieren muss, und das kostet Zeit. Am Ende kommt irgendein Kompromiss dabei heraus, weil man meist diejenigen Plugins mit den tollen Features hat streichen müssen, weil nur das mit den spartanischen Features bezüglich Ladezeit o.k. ist. Es gibt aber auch noch Möglichkeiten, an den Lieblings-Plugins etwas zu optimieren, z.B. indem man dafür sorgt, dass deren Jquery-Daten nur dann geladen werden, wenn sie gebraucht werden. Wenn das Kontakt-Formular z.B. nur auf der Kontakt-Seite auftaucht, muss der Jquery-Code dazu nicht auch auf allen anderen 159 Seiten auftauchen. Man kann in der functions.php Scripte nicht nur registrieren sondern auch deregistrieren (wp_deregister_style, wp_deregister_script) bzw. abfragen, unter welchen Bedingungen diese geladen werden sollen, nur bei Beiträgen, einer bestimmten Seite usw. Damit kann man nicht alles optimieren, aber zumindest einige Auswüchse.
Da auch in WordPress-Entwickler-Kreisen das Thema Ladezeit natürlich nicht unentdeckt geblieben ist, gibt es auch von dieser Seite Lösungswege, in Form von entsprechenden Plugins, z.B. WP Super Cache, Hyper Cache oder Quick Cache. Wie die Namen schon andeuten, liegt diesen Tools die Idee zugrunde, einmal geladene Seiten und Inhalte in einen internen Cache zu laden, um sie beim nächsten Aufruf durch einen anderen Besucher schneller laden zu können. Das funktioniert meist spürbar, allerdings muss man auch mit der einen oder anderen unangenehmen Überraschung rechnen: nach dem Anlegen eines neuen Beitrages z.B. kann es passieren, dass dieser nicht direkt in der Übersicht auftaucht, weil die (alte) Übersichtsseite noch im Cache steckt. Oder, man hat irgendwo per PHP oder Javascript Browser abgefragt, und eigene Css-Regeln für den Chrome hinterlegt, und stellt fest, dass diese auch beim Firefox auftauchen, oder man hat ein Mobile-Plugin im Einsatz (z.B. WpTouchPro), und es taucht in der Desktop-Variante die Mobile-Version auf. Deshalb gilt es genau zu checken, für welche Web-Projekte, z.B. mit regelmäßigen Aktualisierungen an Inhalt und/oder Design, es Baustellen geben könnte, um die man sich dann auch noch kümmern muss. Oder man probiert WP Rocket aus, dessen Eigenwerbung lautet „Dank unserem Plugin ist WordPress so schnell wie nie zuvor.“, dafür muss man allerdings was bezahlen, kann aber effektiven Support hoffen, wenn es zu Problemen kommt.
Und auch für WordPress-Webseiten gilt: ein günstiges Standard-Web-Paket für 4,99 EUR mit PHP/MySql reicht zwar, um die Seite grundsätzlich zum Laufen zu bekommen, allerdings sind auch die Ansprüche von WordPress an den Webserver inzwischen gestiegen, einige Plugins fressen eben viel Speicherplatz, was sich bei der Ladezeit dann bemerkbar macht, ein noch deutlicherer Hinweis auf diesen Engpass sind immer öfter auftauchende Fehlermeldungen wie „Memory-Limit exhausted“, also zu wenig Arbeitsspeicher. Auch ein mit Anspruchslosigkeit werbendes CMS wie WordPress ist dann doch nicht so anspruchslos.
Seitenladegeschwindigkeit ist ein weites Feld, und lässt sich, wenn man es konsequent angehen will, nicht von der Programmier-Abteilung allein erschlagen, es fängt schon bei Konzeption und Design an und zieht sich durch bis zum Redakteur, der alle effektiven Maßnahmen der Web-Dienstleister zunichte machen kann, indem er massenweise Bilder frisch und unbearbeitet aus der Kamera hoch lädt. Man sollte sich davon aber nicht abschrecken lassen und sich auf die wesentlichen Punkte konzentrieren, die zum einen effektiv was bringen, z.B. Bildgrößen optimieren, und auf das, was man im Rahmen des eigenen Workflows auch leisten kann, sich nicht mit Webserver-Performance-Tools beschäftigen, wenn man weder im eigenen Team noch auf Seiten des Providers einen Ansprechpartner hat, der sich damit beschäftigen kann. Denn Zeitaufwand bedeuten diese Maßnahmen alle, manche mehr, mache weniger, je größer das Projekt und damit auch das Budget um so größer auch die Chance, dass man die Bedeutung dieses Thema auch dem Endkunden vermitteln kann.
Sonja Radke befasst sich seit 1996 mit Konzeption, Design und Umsetzung von Corporate-Websites. Sie betreibt seit 2002 smart interactive - Agentur für benutzerfreundliche Medien als interdisziplinäres Netzwerk selbständiger Medienfachleute.
Zudem führt sie Beratungen und Seminare zu Website-Konzeption und benutzerfreundlichem Design durch, schreibt über den Nutzen von SEO und authentischem Marketing und ist Mitglied des German UPA (Berufsverband der Usability und User Experience Professionals) und der Interaction Design Association.
Sie erreichen sie über:
0173. 312 99 38
s.radke@smart-interactive.de
