Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

Webseiten restaurieren und optimieren: Jede Woche neu

HTTP-Requests verbessern und Ladezeit verkürzen

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Webseiten sind heute einfach zu erstellen und auch schnell live gestellt - doch bereits zum Start sollten Sie als Betreiber für die Zukunft gewappnet sein: Wie können Sie Ihre Inhalte über einen längeren Zeitraum "frisch" halten? Wie lassen sich Zugriffszeiten optimieren? Wie reagiere ich auf aktuelle Designtrends und bessere Bandbreiten? Wie schütze ich mich vor Datenverlust und Hacker-Angriffen? Antworten und Hilfe zu diesen und vielen ähnlichen Fragen finden sie zuhauf in dieser praktischen Tipp-Serie.
05:43
  Lesezeichen setzen

Transkript

Jede Anfrage eines Klienten an einen Webserver wird mit Hilfe des Hypertext-Transfer-Protokolls seitens des Webservers gewissenhaft verarbeitet. Solche Anfragen heißen auch Requests und Sie können sich schon denken, dass die Anzahl solcher Requests, die auf einer großen Webseite an einen Server gestellt werden, Auswirkungen auf die Ladezeit hat, also Auswirkungen auf die Zeit, die ein Besucher der Seite warten muss, bevor er ein Ergebnis sieht. Und Sie können sich vorstellen, dass Besucher heutzutage nicht mehr besonders viel Lust zeigen, lange auf den Aufbau einer Seite zu warten. Was kann ich also tun, um solche Requests zu reduzieren? Sehen wir uns also mal an, wie so ein HTTP-Request überhaupt aussieht, um zu verstehen, warum das eventuell auch noch Zeit in Anspruch nehmen kann. Ich möchte eine Seite aufrufen und diese Seite hat generell diese Angabe, das heißt, das ist der Host und das ist der Pfad hin zu dieser HTML-Datei. Und ich möchte diese Seite aufrufen, vorausgesetzt wird, dass ich dafür jetzt einen eigenen Socket zum Host einhost.com öffne und den an den Port 80 binde. Port 80 deswegen, weil ich am Ende meiner URL nicht auch noch eine Portangabe mache, das heißt, Port 80 wird vorausgesetzt und wird dann auch gleich automatisch mitgeschickt. Und dann schicke ich etwas Vergleichbares wie dieses hier, durch das Socket hin zu dem Server, und zwar einen GET-Befehl zusammen mit dem Protokoll, das dafür verwendet wird. Das ist jetzt ein altes Protokoll, Sie werden dann auch gleich sehen warum. Wir sind in der Zwischenzeit auch bei dem Hypertext-Transfer-Protokoll schon einen Schritt weiter, wenn nicht sogar teilweise einen zweiten Schritt weiter. Aber es ist ein GET-Befehl. Dann muss ich angeben, wer ich bin, also von wo diese Aufforderung kommt, mit welchem User-Agent, User-Agent ist der Browser und womit dieser arbeitet. Und wenn ich diese Information an den Server geschickt habe, dann öffnet der Server seinerseits ein Socket und bindet dieses an den Port 80 und sollte in etwa mit Folgendem antworten. Zuerst mal gibt er sein OK, also er kann mit diesem Protokoll umgehen, 200 steht eben dafür, dass es angenommen wird, dann kommt ein Zeitstempel. Am Zeitstempel können Sie schon sehen, warum das ein spannendes Datum ist, es ist genau dieser Milleniumswechsel und hier haben wir auch jetzt noch den Typ des Inhalts, das ist ein einfaches Textdokument, und auch die Länge des Textdokuments wird mitgeschickt. Und dann kommt das tatsächliche Dokument, das dann auch durch den Browser wieder ausgegeben wird. Nachdem der Server diese Information geschickt hat, schließt er den Socket wieder. Mit der nächsten Version vom Hypertext-Transfer-Protokoll hat sich etwas verbessert, und zwar wenn schon mal ein Aufruf stattgefunden hat, kann es auch zu weiteren Anfragen kommen. Nichtsdestotrotz muss aber weiter angefragt werden und Sie fangen jetzt vielleicht an zu verstehen, dass es durchaus von Bedeutung ist, wie viele Anfragen seitens meiner Seite an den Server gestellt werden, weil dieses hin und her, dieses wirklich mit Text beschriebene hin und her, braucht einfach seine Zeit. Ich habe hier zum Beispiel einen Head-Bereich, in dem gleich mehrere Anfragen hinterlegt sind. Für jedes Stylesheet muss ich eine eigene Anfrage an den Server schicken, was jetzt natürlich bei großen Seiten jetzt nicht mehr so wahnsinnig ideal ist; Ähnliches gilt für alle JavaScript-Seiten. Und das heißt aber auch, dass alle Anfragen, die hier im Head-Bereich stattfinden, zuerst erledigt und beantwortet werden müssen, bevor dann diese Seite dargestellt und aufgebaut werden kann. Und das kann zu bösartigen Verzögerungen führen, wenn man nicht darauf achtet, dass man sich hier möglichst kurz hält. Natürlich ist eine Darstellung wie bei dieser Testseite das Ideal, da habe ich keine großen Aufforderungen, weil ich auch keine weiteren Dateien hier mit verbinde, was heißt, dass dieses als Aufruf auf jeden Fall schneller ginge als die gerade von mir vorgestellte Index-Seite. Es ist auch noch zusätzlich so, dass innerhalb jeder CSS-Datei, zum Beispiel, jede Anfrage nach einem Bild ebenfalls so einen Aufruf darstellt. In der Zwischenzeit ist es so, dass es parallele Anfragen geben kann, das beschleunigt das Vorgehen noch weiter, aber das Problem ist, dass Sie sich nicht wirklich darauf verlassen können, dass diese parallelen Anfragen stattfinden können, denn die sind abhängig von den verwendeten Browsern. Und da gibt es nach wie vor gewaltige Unterschiede und schnell wechselnde Voraussetzungen, welcher Browser wie viele parallele Anfragen überhaupt zulässt. Das müssten Sie dann gegebenenfalls einfach zeitnah recherchieren. Also gehen Sie aber davon aus, dass Sie immer das kleinste gemeinsame Vielfache brauchen, und gehen Sie davon aus, es Ihrem Browser möglichst leicht zu machen, indem Sie möglichst wenig Anfragen versuchen Richtung Server zu schicken.