Aufbauend auf dem vorausgegangenen HowTo zum Thema QUIC,
viewtopic/t-144811.html
widmet sich dieser Thread der vermutlich besten Methode, wie man die Ladezeit seiner Webseite um bis zu mehreren 1000% verbessern kann. Diese exorbitante Leistungssteigerung bezieht sich dabei auf das Laden des Hauptdokumentes, also quasi der elementarste Anteil beim Laden einer Webseite. Jedoch nicht zu verwechseln mit den sichtbaren Bereichen im Browser. Was aber unscheinbar wirken mag, ist jedoch die zwingende Voraussetzung dafür, dass man im Browser überhaupt was zu sehen bekommt, da alles sichtbare zumeist durch statische Sourcen wie Bilder, CSS und Javascript erst dann geladen wird, wenn vorher das besagte Hauptdokument geladen wurde.
Man kann seine Webseite also noch so gut optimieren, was alles 0 Komma nichts bringt, wenn das Laden des Hauptdokumentes zu langsam erfolgt. Die Gründe für ein langsames Laden des Haupdokumentes können vielfältig sein und erstreckt sich beginnend von einer zu großen Latenz, also der Zeit bis der Server überhaupt mal auf eine Anfrage reagiert, über zu große Datenmengen, eine schlechte Internet Verbindung, ein zu schwacher Server (zumeist Shared Hosting), schlechte Programmierung bis hin zu der meistverbreiteten Ursache. Webserver, PHP und MySQL sind, wenn man so will, der größte Bottleneck ("Engpass, Flaschenhals") und das in Kombination mit einem nicht ausreichend dimensionierten Server, wobei dieser Bottleneck eigentlich immer besteht. Der Flaschenhals hängt jedoch primär mit der Leistungsfähigkeit eines Servers zusammen. Ein billiges Hosting Angebot steht deswegen unmittelbar für langsam(er) oder schnell(er) und was man seinem Server abverlangt. Eine statische Seite ohne PHP und MySQL kann aber durchaus mit einem 3,50 € Hosting schnell sein, aber das ist die Ausnahme, weil 99 von 100 ein CMS verwenden. Und ein CMS braucht nun mal PHP und MySQL.
Lässt man das mit der Leistungsfähigkeit eines Servers zunächst mal außen vor, ergibt sich bereits bei der Wahl des CMS ein grundlegendes Dilemma, dem so ziemlich jeder ausgeliefert ist, wenn er nicht sein CMS indivuell anpassen und das tiefgreifend ändern will. Es hat sich schon vor Jahren bei der Programmierung von CMS eingebürgert, dass diese nur mehr noch unter Nutzung von sog. Frameworks programmiert werden. Dazu gehört auch das Bootstrap CSS Framework, was zwar nicht unmittelbarer Bestandteil bei der Programmierung einer Applikation ist, aber sich die Problematik bei der Nutzung von Frameworks einmal mehr wiederholt.
Wenn ein Framework, vereinfacht dargestellt, nur eine Sammlung an sog. Bibliotheken ist und der Programmierer sich damit viel Zeit bei der Programmierung erspart, weil er nicht jede Funktion erst programmieren muss und sich einfach nur die benötigte Bibliothek aus der Sammlung holt und darauf aufbauend seine gewünschte Funktion programmieren kann, besticht ein Framework vorwiegend dadurch, dass es ebenso vorwiegend der Programmierung dient. Jedoch zunächst ungeachtet welche Fallstricke sich daraus ergeben. Einmal abgesehen von der Qualität des Codes ist eine Applikation ohne Framework im Endergebnis nicht besser oder schlechter als mit Framework. Gerne wird der Einsatz eines Frameworks werbewirksam eingesetzt und soll etwas besseres vorgaukeln, was es unterm Strich aber nicht ist. Vielmehr ist es so, dass der Einsatz eines Frameworks dazu den Programmierer verleiten lässt mehr Code zu verwenden als was er eigentlich bräuchte. Es ist ja so einfach einfach eine Bibliothek seiner Programmierung hinzuzufügen. Und am Ende hat man/bekommt man eine unnormal aufgeblähte Anwendung für die man mehr Speicher und CPU Power braucht. Es gibt genügend Beispiele dafür, die teilweise so extrem sind, dass die jeweilige Anwendung im übertragenen Sinne Gehhilfen braucht, um diese überhaupt installiert zu bekommen. Dieses Phänomen wirkt sich auch dadurch aus, dass Hersteller auch von bekannten Anwendungen erst am Ende einer Entwicklung feststellen, dass man über das Ziel hinausgeschossen hat und in Folge dessen krampfhaft mit Drittlösungen versucht wird die leidende Performance wieder in den Griff zu bekommen. Das ist zwar kein generelles Problem, lässt sich aber sehr oft feststellen.
Bezieht man das beschriebene Problem beispielhaft auf Wordpress, mag es zunächst irritieren, dass es auch dort so sein könnte. Wordpress ist im Auslieferungszustand ja eher schlank, jedoch bedingt dadurch, dass es im Auslieferungszustand nur die elementaren Funktionen mitbringt und deswegen auch sehr flott ist. Die vermutlich meisten WP Nutzer ergänzen aber ihre WP Installation durch entsprechende Plugins und spätestens dann gehen die Probleme los. Teils schlechter Programmierung, meistens aber ganz einfach deswegen weil mehr Code == mehr Funktionen == einen höheren Systemressourcen Bedarf haben, jedoch mit dem Haken versehen, dass das in eine Sackgasse landet, weil ein leistungsfähigerer Server und somit ein Mehr an Kosten oftmals für viele keine Option ist oder/und auch ein besseres Hosting das besagte Bottleneck nicht auflöst.
Wenn dem nun so ist, wie es offensichtlich ist und das volle Potential an Optimierungsmöglichkeiten nicht das zufriedenstellende Ergebnis gebracht hat, stellt sich die unweigerlich die Frage was tun?
Das Internet hält für dieses Problem eine Vielzahl an Möglichkeiten bereit, gute wie weniger gute, teure aber auch preisgünstige und nicht selten aber auch kostenlose. Um nun einen entscheidenden Push zu bekommen, der so ziemliches alles überragt, braucht es Caching. Keine andere Methode als Caching bringt ein besseres Ergebnis hervor. Danach kommt lange nichts, was auch nur annähernd die gleiche Performance abliefern kann. Caching hat nur einen Haken. Gemäß dem Grundprinzip von Caching müssen Daten zumindest einmal (1x) zwischengespeichert sein, um die Vorteile nutzen zu können. Dieser augenscheinlich wirkende Nachteil lässt sich aber auf einfachste Weise beheben, sodass der Nachteil vernachlässigt werden kann.
In der Vielzahl an unterschiedlichen Cache Arten sticht besonders das HTTP Caching hervor, weil es im Ergebnis andere Cache Unterarten vereinnahmt und somit überflüssig macht, das beste Ergebnis abliefert und sich mit verhältnismäßig wenig Aufwand nutzen lässt. HTTP Cache ist jedoch nicht gleich HTTP Cache und zumindest aus meiner Sicht die Bezeichnung HTTP Cache oftmals falsch und irreführend verwendet wird. Ungeachtet dessen löst HTTP Caching aber das eingangs beschriebene Bottleneck Problem. Zwar nicht bei allen erhältlichen Varianten in Perfektion, aber doch in erheblichem Maße.
Vorab gilt es jedoch zu differenzieren, was ein HTTP Cache nicht ist und das in erster Linie was den Browser Cache anbetrifft. Statische Sourcen wie Bilder, CSS und Javascript sind prädestiniert zum Cachen im Browser, ist aber kein HTTP Cache. Wenn es konkret um HTTP Cache geht, dann bescheibt das das Serverseitige Cachen, insbesondere von dynamisch generierten Inhalten, also den Daten die mittels PHP und MySQL bei jedem Aufruf erst generiert und abgefragt werden müssen und zusammen mit dem HTML Output auf dem Server zwischengespeichert werden. Das Ergebnis eines HTTP Cache entspricht vereinfacht dargestellt dem lokalen Speichern einer einzelnen Internet Seite mit der jeweiligen Browser Funktion. Wird nun eine im Cache befindliche Seite/URL aufgerufen, wird im Grunde genommen nur mehr diese auf der Festplatte des Servers gespeicherte Datei aufgerufen. Der ansonsten notwendige Aufruf des PHP Interpretors inkl. Datenbank Abfrage entfällt gänzlich. Daraus ergibt sich folgerichtig eine exorbitant schnelle Ladezeit jedoch begrenzt auf das Hauptdokument. Zu viel CSS, Javascript, schlecht optimierte oder zu große Bilder, ein zu verschachteltes DOM können das ursprüngliche schnelle Laden des Hauptdokumentes aber wieder zunichte machen. Deswegen ist die Konsequenz, dass ein HTTP Cache nur so gut sein kann, wie der Rest an statischen Sourcen optimiert ist.
Wie vorausgehend bereits erwähnt, ist ein HTTP Cache nicht gleich HTTP Cache. Wie gut ein HTTP Cache ist, hängt von mehreren Faktoren ab. Dazu gehört u.a. das Speichermedium, also die Festplatte. Kommt nur eine gewöhnliche SATA HDD zum Einsatz, drosselt diese die Leistung des HTTP Cache nicht unerheblich, weshalb zwingend eine SSD HDD zusammen mit einem HTTP Cache verwendet werden sollte (MUSS).
Am Beispiel Wordpress gibt es dafür ein gutes Dutzend an HTTP Cache Plugins oder sagen wir mal um Plugins, die gerne ein HTTP Cache sein möchten. Zwar erledigen diese Plugins die Aufgabe eines HTTP Cache in ihrer grundsätzlichen Funktion und können jeder WP Installation Flügel verschaffen, jedoch mit teilweise großen Einschränkungen, sodass diese Plugins nicht uneingeschränkt genutzt werden können.
Allen Einschränkungen voran steht, dass diese Plugins, bzw. dessen Ergebnis von der Performance des Webservers abhängt. Zumeist ist dies der Apache Webserver und mal abgesehen von dessen veralteten System Architektur, weiß Apache nicht, dass die Wordpress Installation eine HTTP Cache Funktion hat und schert sich deswegen auch nicht darum und behandelt einen Request wie jeden anderen. Kurzum, die HTTP Cache Funktion könnte zwar sehr schnell sein, wird in Ermangelung einer Abstimmung mit dem Webserver aber ausgebremst. Von daher sind dem Ergebnis von dieser Art HTTP Cache ziemlich enge Grenzen gesetzt, zumal dann, wenn man nur ein geringes Budget für das Hosting hat. So gut wie solche Plugins wirken mögen, kommt es nicht selten vor, dass diese Plugins wieder deinstalliert werden, ohne aber zu verstehen, warum man nicht den Speed bekommt den man augenscheinlich bekommen soll. Spätestens jetzt sollte man aber wenn auch nur in Grundzügen verstehen, dass so ein Plugin allein nur bedingt was bringt.
Zu den weiteren Einschränkungen zählt, wenn die jeweilige Anwendung um Funktionen erweitert wird, die eine Session benötigen oder/und sich Teilbereiche einer einzelnen Seite in Abhängigkeit zum Nutzerverhalten dynamisch verändert. Zur Erinnerung, ein HTTP Cache speichert den HTML Output einer vorher generierten Seite statisch auf dem Server ab. Statisch bedeutet, dass in Ermangelung von PHP auch keine Session mehr existiert. In der Session befinden sich aber flüchtige und nicht selten nutzerbezogene Daten, die es aber widerrum braucht, um den jeweligen Content anzeigen zu können. Ist dies der Fall, könnte man den HTTP Cache von solchen Plugins nicht verwenden. Als unmittelbares Beispiel dient die Warenkorb Funktion in einem Online Shop oder ein angemeldeter Zustand in einem Benutzerkonto. Jedoch stets nur bezogen auf solche Cache Plugins, die im Grunde nur Cache ON/OFF kennen und nicht in der Lage sind nur Teilbereiche einer einzelnen Seite zu cachen oder/und trotz Cache Funktion die Session Funktion aufrecht erhalten können.
Was vorausgehend wie ein sehr tiefer Einschnitt in den doch so hochgelobten HTTP Cache wirken mag, ist in der Tat ein Einschnitt, allerdings ausnahmslos nur dann, wenn man derartige Plugins verwendet. Es gibt noch weit bessere HTTP Cache Lösungen, jedoch kommt nach diesen Plugins erstmal nichts und die Stufe zu einem richtigen HTTP Cache und v.a. ohne Einschränkungen ist hoch, sehr hoch. Aber auch hier nur bezogen auf konventionelle Lösungen wie dem Varnish Cache für den man dann 10.000 $ pro Jahr an Lizenzkosten zahlen muss. Für diesen Betrag bekommt man dann zwar die eigentlich selbstverständliche SSL Unterstützung. Das erspart einem aber nicht die Notwendigkeit eines zusätzlichen Proxy und tiefe Eingriffe in die jeweilige Applikation, um das besonders für Online Shops notwendige partielle Cachen zu bekommen.
Das hört sich nun auch nicht viel besser an als die Plugins, zumal es ja um etwas massentaugliches geht und für nahezu jeden bezahlbar bleiben muss. Die gute Nachricht ist, so was gibt es und besser als alles, was man selbst für noch so viel Geld nicht bekommt. So einfach zu bedienen wie genannten Plugins, jedoch ohne die genannten Einschränkungen und zudem ganzheitlich gelöst. Im Fall Wordpress bedeutet das 1 Lösung, die sowohl einen perfektionierten HTTP Cache zur Verfügung stellt und zusammen damit sämtliche und bislang unbekannte Optimierungen vornimmt.
Der Haken daran ist nur, dass man das nicht an jeder virtuellen Straßenecke bekommt. Wer jetzt auf den Geschmack gekommen ist und gerne mehr erfahren möchte, darf sich gerne per PM an mich wenden.
