registrieren registriertes Mitglied


Anzeige

Anzeige

HowTo: Der ultimative Speedguide für Wordpress & Co. Part I

Fragen zu Servern, Hosting und Webmaster Hardware könnt Ihr hier stellen.
Neues Thema Antworten
supervisior
PostRank 10
PostRank 10
Beiträge: 3389
Registriert: 26.06.2006, 09:11

Beitrag supervisior » 10.11.2020, 16:51 HowTo: Der ultimative Speedguide für Wordpress & Co. Part I

Auch wenn der Titel dieses Themas es vorgeben mag, aber nachdem das Thema Ladezeit schier unendlich wirken mag, konzentriert sich dieses Thema auf Möglichkeiten zur Ladezeitverbesserung, die man eben nicht überall zu lesen bekommt. Das liegt aber maßgeblich daran, dass die bislang bekannten Möglichkeiten schon nahezu durchgekaut sind. Zum x-ten Male über das Gleiche zu schreiben, bringt also nichts.

Dieses Thema beschäftigt sich mit neuen Standards, die formell durch das IETF (Internet Engineering Task Force) zwar noch nicht gänzlich abgesegnet sind, aber wie das mit dem IETF und neuen Standards schon in der Vergangenheit war, werden neue Techniken schon Jahre vor der eigentlichen Standardisierung eingesetzt. Von daher kann man die endgültige Ratifizierung und Spezifikation durch das IETF quasi nur als Formsache bezeichnen, zumindest wirkt es so.

Nichtsdestotrotz und auch wenn die gängigen Themen zur Optimierung schon lange durchgekaut sind, gilt es trotzdem dazu noch was zu erwähnen. Wann immer die Rede von Optimierung ist und das maßgeblich durch Google Pagespeed angetrieben, beschränken sich die Möglichkeiten einer Optimierung nur auf das, was das Wort optimieren beinhaltet, also optimieren. Wenn man die Pagespeed Vorgaben zur Optimierung umsetzt, dann erreicht man damit in erster Linie eine Verbesserung des Anzeigeverhaltens im Browser, was sich zwar anfühlt als würde die Seite schneller laden, aber mit ein paar Einschränkung ändert sich dadurch zumeist nichts an der Menge der Daten. Natürlich kann man mit optimierten Bildern die Menge an zu ladenden Daten reduzieren, aber nachdem 9,9 von 10 ein CMS verwenden, sind darüberhinaus gehende Maßnahmen nur mit tiefergehenden Änderungen verbunden und scheidet deswegen für die meisten aus. Natürlich gibt es bekannte Plugins zum Optimieren und die machen ihren Job zumeist auch recht gut, aber es sind immer nur Optimierungen. Aber um nicht missverstanden zu werden, die besagten Optimierungen sind und bleiben auch für die Zukunft unabdingbar, was maßgeblich daran liegt, dass die CMS Anbieter zu wenig darauf achten. Mir ist in den letzten 20 Jahren zumindest noch keine Web Applikation untergekommen, das dahingehend nicht nachbesserungswürdig gewesen wäre.

Um nun einen größeren Schritt, um nicht zu sagen den nächsten Schritt über das bekannte hinaus machen zu können, braucht ein Stück weit mehr. Das bedeutet aber nicht unmittelbar, dass dafür horrende Summen investiert werden müssen. Eigentlich muss man dafür keinen Cent mehr investieren, was aber voraussetzt, dass der oben genannte Hinweis auf neue Standards flächendeckend eingesetzt wird. Aber daran scheitert es noch und wird es auch noch länger, zumindest in Deutschland. Dazu aber später mehr.

Worum geht es also bei diesen neuen Standards?

badge.png
badge.png (33.91 KiB) 6003 mal betrachtet

Wer sich schon mal ein bisschen mehr mit dem Internet auseinandergesetzt hat, der hat sicherlich schon mal was von HTTP/2 gehört und welche Vorteile HTTP/2 gegenüber der Vorgängerversion besitzt. HTTP/2 ist aber inzwischen schon seit Jahren im Einsatz. Wichtig in diesem Zusammenhang ist aber nur, dass das HTTP/2 Protokoll auf das TCP Protokoll verwendet. Auch wenn HTTP/2 deutliche Verbesserungen gegenüber HTTP/1.x besitzt, leidet HTTP/2 unter den gleichen Problemen wie HTTP/1.x, wenn es um HTTPS Verbindungen, insbesondere beim Erstkontakt zwischen Client und Server geht. Bei dem Erstkontakt, bzw. dem sog. Handshake handeln Client und Server in mehren sog. Round Trips die Verbindungskonditonen aus. Die Betonung liegt dabei auf mehrere. Ein Umstand, den das TCP Protokoll mit sich bringt. Solange diese Handshake Prozedur nicht abgeschlossen ist, werden auch keine Daten übertragen, sodass sich dieser Prozess unweigerlich auf die Ladezeit auswirkt und das nicht unerheblich. Wer nur ein 5,- Hosting betreibt bei dem die verfügbaren Server Ressourcen nicht nur geteilt, sondern auch deutlich beschränkt sind, ist davon unweigerlich mehr betroffen als wie mit einem VPS oder einem dedizierten Server. Wichtig ist dabei nur, dass die besten Optimierungen nahezu unter den Tisch fallen, wenn dieser besagte Handshake zu lange dauert.

Durch die schon seit Jahren nahezu flächendeckende Verwendung von HTTPS, wurde die oben beschriebene Problematik mehr als offensichtlich, weshalb sich, wie soll es anderes sein, Google dazu berufen sah dieses Problem zu lösen. Allerdings seit 2016 und noch weitere Jahre nur für den Eigennutzen. Google hat sich also was Neues ausgedacht, was auf den Namen QUIC (Quick UDP Internet Connections) hört. Wann immer man über QUIC recherchiert, wird man in 99 von 100 Fällen lesen, dass es sich dabei um ein experimentelles Protokoll handeln würde, sodass man augenscheinlich davon ausgehen muss, dass QUIC wohl Zukunftsmusik wäre. Dem ist aber nicht so, weshalb nahezu alle Quellen zum Thema QUIC falsch und veraltet sind. Die Spezifikation von QUIC ist nahezu abgeschlossen. Google selbst verwendet QUIC seit 2016, zwar nur in den eigenen Diensten von Google, aber es gibt bereits (1) Webserver, der QUIC vollumfassend unterstützt. Dazu gehören aber nicht Apache und auch nicht nginx. Bei letzterem ist man noch in einer rudimentären Erprobungsphase und bei Apache wird es sicherlich noch deutlich länger dauern. Für Apache und nginx Nutzer unter Euch sieht es deswegen auf absehbare Zeit schlecht für Euch aus. Sorry, is aber so und da müsst Ihr Euch bei Euren Provider beschweren, weil diese nämlich auch eine deutliche Mitschuld daran haben.

Google hat nun aber eingesehen, dass es mehr bringt, wenn alle QUIC nutzen können, weshalb QUIC als maßgeblicher Bestandteil in das neue HTTP/3 Protokoll einfließen wird, bzw. schon ist. QUIC wird bereits von Chrome (Chrome basierten Browsern), Opera und neuerdings auch von Safari unterstützt. Firefox lässt noch auf sich warten.

Ohne jetzt zu sehr ins technische Detail einzugehen, was QUIC genau ist, nur so viel dazu. QUIC nutzt anstelle von TCP das UDP Protokoll, das jedoch für QUIC weiterführende Funktionen bekommen hat. Was QUIC im Detail macht, sollte auch dem Laien durch die nachfolgende Grafik offensichtlich werden. Diese Grafik zeigt schematisch den erwähnten Handshake auf. Und man muss die Fachbegriffe in der Grafik gar nicht mal verstehen müssen, da es genügt die Menge der hin- und hergehende Pfeile für die Round Trips zu zählen. Weniger Pfeile bedeutet weniger Gequatsche zwischen Server und Browser und folglich schnellere Übertragung des Response Body.

quic.jpg
quic.jpg (112.88 KiB) 6059 mal betrachtet

Das mit QUIC löst nicht alle Probleme und macht aus einem lahmen Server durch QUIC alleine keine Speed Maschine. Auch wenn eine Seite gut optimiert ist und bereits QUIC unterstützt, ist das Hosting immer noch das Maß aller Dinge. Wer für das Hosting aber nicht mehr als 10,- Euronen im Monat investieren kann oder will, muss unweigerlich mit Einschränkungen leben müssen. Gutes Hosting heißt aber nicht gleich einen dedizierten Server. Es geht auch deutlich preiswerter und ohne dedizierten Server, aber eben nicht mit einem LowBudget Hosting. QUIC kann aber einen Teil der Probleme selbst unter erschwerten Bedingungen mit einem LowBudget Hosting lösen. Problem daran ist nur, dass sich allen voran deutsche und besonders die großen und bekannten Provider gegenwärtig noch dagegen sperren QUIC mit alternativen Webserver, die zu Apache kompatibel sind, verfügbar zu machen, zumal sich dadurch keine Mehrkosten für Kunden ergeben.

Wer jetzt auf den Geschmack gekommen ist und gerne mehr über QUIC erfahren will und was man tun muss, um in den Genuss von QUIC zu kommen, der kann mich gern per PM kontaktieren.

Um das Thema abzurunden, wer mal prüfen möchte, ob sein Server schon QUIC kann, der kann das hier mal testen:

https://http3check.net/

Ergänzende Informationen

Was für den Laien womöglich wenig prickelnd weil zu technisch wirken mag, entspricht QUIC doch einer gewissen Revolution. QUIC definiert sich nicht allein dadurch, dass der erwähnte Handshake schneller von statten geht. Mit QUIC gehen weitere innovative Lösungen einher, die so ziemlich alles bekannte auf den Kopf stellen. Man muss aber nicht befürchten, dass durch QUIC plötzlich (ver)alte(te) Technologien nicht mehr funktionieren würden. Mein Server mit QUIC kann auch HTTP/1.x. Der Punkt dabei ist nur, dass die bisherige Methodik von nahezu jedem Provider v.a. in Deutschland schon in Kürze nicht mehr funktionieren wird. Der am meisten genutzte Webserver Apache kann nun mal kein QUIC und es ist auch nicht bekannt, dass sich Apache um die QUIC Implentierung bemühen würde. Mir ist deswegen auch kein hiesiger Provider bekannt, der QUIC, bzw. HTTP/3 aktiv bewerben würde. Deswegen ist es mir schleierhaft, wie man sich auf Seiten der Provider darauf einstellen will und wird, zumal dann, wenn in Ermangelung von QUIC in Apache man quasi nur noch veraltetetes Zeugs anbieten kann?!

Anzeige von: