In meinem Artikel über die sprunghaft angestiegenen Besucherzahlen auf Selbständig im Netz habe ich vermutet, dass es etwas mit der Optimierung meiner Response Time zu tun hat.
Diese konnte ich verbessern und der Zusammenhang mit den Besucherzahlen war recht offensichtlich. Doch was ist eine gute Response Time überhaupt?
Deshalb hatte ich eine Umfrage unter meinen Lesern bzgl. der Response Time gestartet, die ich in diesem Artikel auswerten möchte.
Zudem gibt es eine kleine Vorschau auf eine kommende Aktion hier im Blog.
Meine Erfahrungen
Ende 2012 habe ich das Caching-Plugin für meinen WordPress-Blog gewechselt. Von W3 Total Cache bin ich auf WP Super Cache umgestiegen. Das Resultat war eine umgehende Verbesserung der Response Time.
Was ist diese Response Time überhaupt? Die allgemein Definition lautet wie folgt: Es ist der Zeitabstand zwischen einer Aktion und einer Reaktion.
Im Falle von Websites bedeutet dies, dass die Zeitspanne zwischen der Anfrage an den Server und dem Beginn der Auslieferung der Website damit gemeint ist. Sie wird auf deutsch auch Antwortzeit genannt. Je kürzer diese ist, umso besser, da die Nutzer eher die Inhalte zu sehen bekommen.
Ich habe meine Blogs schon länger vom Service Pingdom überwachen lassen. Dieser prüft, ob die Websites online sind und er misst unter anderem die Response Time.
Nach meiner Optimierung war eine deutliche Verbesserung sichtbar. Allerdings war diese in der Realität noch deutlich besser als gedacht. Ich habe in dem damaligen Artikel angegeben, dass die Response Time von durchschnittlich 1.400-1.500 Millisekunden auf rund 750 gesunken ist.
Das waren allerdings die Werte für die weltweite Messung. Wie ich erst später gesehen haben, kann man nach Europa und USA filtern oder sogar einzelne Ländern auswählen.
Die rechts stehende Grafik zeigt die Veränderung in der Response Time bei Testzugriffen aus Europa, was bei meiner Zielgruppe natürlich viel relevanter ist, als der weltweite Zugriff.
Wie man sehen kann, sind die Antwortzeiten von rund 850 Millisekunden auf rund 200 gesunken. Diese haben sich also nicht nur halbiert, sondern sind auf ein Viertel gesunken.
200 Millisekunden sind ein recht guter Wert, wie ich finde.
Umfrage-Auswertung
Doch natürlich sind solche Werte für sich genommen nicht wirklich aussagekräftig. Erst im Vergleich mit anderen Websites kann man diesen Wert einordnen.
An meiner Umfrage haben insgesamt 90 Leser teilgenommen und ihre Werte an mich gesendet. Darunter waren natürlich vor allem WordPress-Nutzer, aber es wurden auch einige andere CMS angegeben und einige nutzten gar statische HTML-Seiten.
Auch bei den Analyse-Tools gab es Unterschiede. Am häufigsten wurden die Daten von Google Analytics angegeben, welches ja mittlerweile auch eine Response Time anzeigt. Danach folgte mit Pingdom das Tool, welches ich am liebsten nutze.
Darüber hinaus wurden noch ein paar andere Tool genutzt, die ich teilweise aber nicht mal kannte.
Um bei der ersten Auswertung dieser Umfrage halbwegs vergleichbare Werte zu haben, musste ich etwas filtern. Deshalb finden sich in der folgenden Grafik nur WordPress-Blogs wieder, deren Werte von Google Analytics oder Pingom stammen. Damit dürften diese Werte am ehesten zu vergleichen sein. Das waren dann insgesamt noch 61 Teilnehmer.
Das Ergebnis ist erstaunlich, wenn auch sicher nicht unbedingt zu 100% repräsentativ. Die WordPress-Blogs auf den Shared Hosting Accouts haben im Schnitt die etwas kürzere Response Time. Dagegen sind die Virtual Server und die Server etwas langsamer. Die Skala ist in Sekunden.
Wenn mir die Grafik eines sagt, dass ist es das Folgende: Es reicht nicht einen schnelleren Tarif zu wählen und z.B. vom Shared Hosting zum Server zu wechseln. Man kann am Blog selbst so viel optimieren, was leider von vielen nicht ausgenutzt wird.
Eine Erklärung wäre die Folgende: Viele Shared Hosting Blogs werden eher von Laien betrieben und nutzen keine Plugins oder andere Dinge, die den Blog langsam machen.
Ebenso denkbar ist, dass sich Shared Hosting Nutzer intensiver mit der Ladezeit-Optimierung beschäftigen, weil die Ressourcen begrenzt sind, während Server-Nutzer vielleicht der Meinung sind, dass dies nicht notwendig ist.
Was auch immer der Grund sein mag, diese Zusammenfassung zeigt, dass viele Blogs mit Sicherheit Potential zur Ladezeit-Optimierung haben, unter anderem bei der Response Time.
Schaue ich mir die einzelnen Werte genauer an, so gibt es da große Schwankungen. Manche Blogs scheinen sehr gut optimiert zu sein, während andere trotz gutem Server nicht besonders schnell sind.
Fazit
Ich gebe zu, dass die Umfrage nicht optimal war und man etwas genauer hätte nachfragen müssen. Wenn ich mir die eingereichten Werte so anschaue befürchte ich zudem, dass der eine oder andere statt der Response Time die komplette Ladezeit angegeben hat. Anders sind manche Werte fast nicht zu erklären.
Unter dem Strich wird die Performance-Optimierung meiner Meinung nach aber von vielen Website- und Blog-Betreibern unterschätzt. Man steckt z.B. viel Energie ist SEO-Maßnahmen, verschenkt dann aber wiederum viel Potential mit einer zu langsamen Site.
Ankündigung
Aus diesem Grund und wegen meiner eigenen einschneidenden Erfahrungen habe ich eine neue Aktion für Selbständig im Netz in Planung.
Ich werde eine neue Artikelserie starten, die sehr praktisch ausgelegt ist. Es geht um die Performance-Optimierung. Neben allgemeinen Tipps und Best Practices geht es im Speziellen um WordPress, da ich mich damit einfach am besten auskenne.
Um den Praxisbezug zu vergrößern, werde ich zudem meinen Blog Blogprojekt.de im Rahmen dieser Artikelserie parallel optimieren und meine eigenen Tipps dort umsetzen.
Im Gegensatz zu Selbständig im Netz haben ich Blogprojekt diesbezüglich in der Vergangenheit vernachlässigt. Das möchte ich nun nachholen und für die Leser wird das sicher interessant sein zu sehen. Ich werde natürlich ins Detail gehen und zeigen, was genau ich da geändert habe und wie sich das auf die Performance ausgewirkt hat.
Zudem plane ich auch die Leser stärker mit einzubeziehen, aber da bin ich mir noch nicht ganz so sicher, wie genau ich das machen werde.
In Kürze gibt es hier im Blog weitere Informationen zu dieser Aktion und dann erfahrt ihr auch, wann es genau losgeht.
Wer wir sind und wie wir arbeiten. In unserem Büro im Zentrum von Köln arbeiten gegenwärtig sieben ausgebildete Redakteur/innen an der Ausarbeitung erstklassiger Inhalte, auf die du dich verlassen kannst. Sämtliche Artikel werden nach dem Vier-Augen-Prinzip publiziert: Nach Fertigstellung der Rohfassung werden die Texte von (mindestens) einem/r anderen Redakteur/in auf orthografische und inhaltliche Richtigkeit hin überprüft.
Diese Seite ist ein Angebot der 4pub GmbH mit Sitz in Köln. Wir haben uns auf den Betrieb hochwertiger redaktioneller Online-Portale spezialisiert und berichten stets redaktionell unabhängig.
- Danke für 16 tolle Jahre - 13. Juli 2023
- So erstellst du deine erste Newsletter-Mail in 10 Schritten mit CleverReach - 13. Juli 2023
- Die 5 besten Features des Amazon Affiliate WordPress Plugin – AAWP - 12. Juli 2023
Ui, da scheint mein Shared-Hoster (all-inkl) aber viel zu langsam zu sein. Mit Pingdom kommt ich auf 924ms im Overall Average (letzte 30 Tage). Auch bei Pagespeed.de ist mir schon häufiger aufgefallen, dass der “Speed” sehr häufig nur bei um die 50kb/s liegt – viel zu langsam. Vielleicht sollte ich da mal Kontakt aufnehmen. Danke für deine Auswertung!
Großartig – Performance-Optimierung ist zur Zeit genau mein Thema!
Danke schon mal im voraus 😉
Ein guter und wichtiger Artikel , PageSpeed wird von vielen Website Besitzern leider immer noch unterschätzt.
Das Shared Hoster in deinen Daten besser abgeschnitten haben ist eher verwunderlich! Ich habe mehrere Shared Hoster ausprobiert und meine Websites dort getestet – keine war schneller als der billigste vServer (7,99€ / Monat) von Strato!
Ich vermute, dass viele Website Betreiber die Ihre Server nutzen keine Minimalinstallation nutzen und somit viel unnötigen Ballast auf dem Server laufen haben! Auch nutzen viele dieser Betreiber wohl keine Apache Mods wie „mod_pagespeed“ oder den „mod_deflate“ (liefert die Daten komprimiert aus)!
Die größten Geschwindigkeitszuwächse bringen meiner Erfahrung nach (1) ein gut eingestelltes „Browser-Caching“ via .htaccess Datei, die Nutzung von (2) CSS-Sprites, (3) CSS Dateien direkt im Header einzubinden statt diese über extra Dateien zu laden. (4) Ähnliches gilt für JavaScript Dateien die man auch am Ende des HTML Quelltextes direkt als Quelltext einbinden kann.
CSS-Sprites lohnen sich vor allem bei vielen kleinen Grafiken hier sind die „Verbindungs-“ und Wartezeit meist deutlich länger als die eigentliche Übertragungszeit der Daten teilweise im Verhältnis 9:1. (kann man gut sehen wenn man sich bei Pingdom den „Waterfall“ ansieht 😉 )
Bei CSS Dateien wende ich einen zusätzlichen kleinen Trick an. Ich nutze eigentlich normale externe Dateien wie /css/style.css (ist übersichtlicher und damit einfacher zu bearbeiten). Diese CSS Dateien lese ich dann mit PHP via „file_get_contents();“ ein und entferne zusätzlich alle Zeilenumbrüche mit „preg_replace(“/\r|\n/s”, “”, $css_file);“ – dies für dazu das der Gesamte CSS Code deutlich kleiner wird. Das Ganze wird dann im Head Bereich meiner HTML Datei ausgegeben und somit in einem Rutsch an den Browser des Besuchers übergeben!
Es gibt natürlich noch weitere Trick und Kniffe aber das wird zu lang …
Hallo Peer,
danke für die Artikel zur Response-Time. Was mich bisher immer von der Nutzung diverser Cache-Plugins abgehalten hat, ist die Problemanfälligkeit mit Shop-Systemen etc. sowie die Sicherheitslücken, die es bei manchem Plugin gibt.
Vielleicht könntest Du auf diese Aspekte ebenfalls eingehen, wäre super.
Vielleicht wäre sogar eine Liste mit funktionierenden Cache-Shop-Plugins denkbar. Wenn Du Hilfe brauchst, ich würde gerne beisteuern wo es geht.
Gruß,
Axel
@Ben
Durch das direkte Einbinden von Dateien im Quellcode machst du allerdings das Browser-Caching kaputt. Das lohnt sich imho nur bei One-Pagern, die nur selten wiederbesucht werden.
Ich setze lieber auf unterschiedliche Hosts für statische Ressourcen (Bilder, CSS, Scripte) um mehrere parallele Downloads zu ermöglichen und lege eine sehr lange Cache-Lifetime fest. Änderungen an CSS Dateien und JavaScripts lasse ich via Fingerprinting live gehen.
PS: Nur für den Fall das es jemand noch nicht kennt – https://developers.google.com/speed/docs/best-practices/rules_intro (PageSpeed best pratices von Google)
Viele Grüße
Pascal
@Pascal: Ich mache das Browser Caching NICHT kaputt ich binde lediglich CSS- und JavaScript-Code direkt ein! Wichtige (große) Dateien wie Bilder und CSS Sprites werden weiterhin “gechached”. Bilder bekommen bei mir meist Dateinamen wie “haupt-logo-v1-1.png” (steht für Version 1.1), damit die Dateien trotz Browsercaching auch immer aktuell sind – das meinst du wahrscheinlich mit Fingerprinting!? Bei CSS Dateien ist dies aber extrem nervig – bei jeder kleinen Änderung muss zum testen wieder ein neuer Name angelegt werden (dieser muss dann auch jedesmal wieder in der Haupt HTML Datei geändert werden) selbst wenn man nur Kleinigkeiten wie ein Simikolon vergessen hat. Da wird man wuschig! 😉
Anderes Beispiel: Wenn ich mitten in der Entwicklung einer Website bin lese ich bis zu 20 CSS Dateien im Head ein mit Klassen für Verläufe, Abrunden, Text & Box Schatten etc. pp (viele Daten benötige ich später nicht mehr, diese machen aber während der Entwicklungsphase das Spielen & Testen einfacher)! Diese Dateien bestehen zur Zeit zusammen aus 53.200 Zeichen inkl. Leerzeichen (50.400 ohne Leerzeichen). Diese Zeichenmenge ist aber nur 53 KB groß! Und ich bin mittlerweile drauf und dran alle Grafiken bei denen es machbar ist durch CSS Daten zu ersetzen was ein Vielfaches der oben erwähnten 53 KB einspart – und das trotz des vielen extra CSS Code für “Ausbesserungen & Fixes” für diese stümperhafte Software namens InternetExplorer!
Wenn die Projekte dann fertig sind kann man folgendes machen: Alle CSS Hauptdaten wie die wichtigsten Rahmen und Abstände und Pfade der wichtigsten Bilder (!!) (z.B. Logo, Navigation, bzw. Grafiken die der Besucher als erstes sieht) direkt per PHP file_get_contents() einbinden, damit diese zuerst geladen werden und den REST dann ggf. per CSS Link als externe Datei einbinden (je nach KB Größe muss man abwegen ob das was nützt – bei 100.000 Seitenaufrufen und 15 KB extra sind das ca. 1,4 GB extra Traffic**). Das direkte einbinden von CSS Daten in den HTML Head Bereich hat den Vorteil das alle Bereiche, Tabellen, DIV’s SOFORT die richtige Größe haben und an der richtigen Stelle stehen was beim BESUCHER allein schon zu einem Gefühl von mehr Schnelligkeit und damit auch zu einem Eindruck von mehr Professionalität führt! Auch die wichtigsten Bilder werden schneller – da als erstes – geladen! Man sollte auch im Hinterkopf behalten das jede einzelne Connection (-Time) von Mobilen Geräten inbesondere bei UMTS deutlich länger ist, als beim PC der am DSL Router hängt! Wenn der erste Verbindungsaufbau/Seitenaufruf mit einem mobilen Endgerät ewig lange dauert nur weil man 80 – 100 Dateien (und damit 80 – 100 Connection + Wartezeit) hat ist es meiner Meinung nach sehr wahrscheinlich das der Besucher seinen Besuch entnervt aufgibt!
(**) Man kann sich diese 1,4 GB Traffic zu ca. 90% sparen, wenn man beim => ersten <= Seitenaufruf eines Besuchers die CSS Daten via file_get_contents() direkt im HTML Head ausgibt UND GLEICHZEITIG die externe CSS Datei via LINK einbindet! Beim zweiten Aufruf lässt man die file_get_contens() Einbindung dann einfach weg – sofern BrowserCacheing für CSS Dateien aktiviert ist!
Bei Dateien wie jQuery (53KB) – die nichts mit dem ersten optischen Eindruck zu tun haben sondern Funktionen liefern, gebe ich dir allerdings recht, diese sollte man besser Cachen! Ich binde jQuery zudem erst am Ende des Quelltextes per Link ein damit es den Ladevorgang der wichtigen Elemente nicht stört!
Eines der obersten Ziele sollte es sein die Anzahl der Request & damit der Connections auf ein Minimum zu reduzieren! (Diese Seite von SiN hat 79 Request's!) Jede Datei die einzelnd geladen werden muss ist wiederrum ein Request an den (Apache-)Server und dieser arbeitet dieses Request nacheinander ab! Das heißt es gibt quasi eine Warteschleife… und in Spitzenzeiten wird die Response Time dann immer länger! Hier ein ziemlich gutes Video von GoogleDevelopers (http://youtu.be/BaWokURhU_k), wenn man erst einmal weiß wie die Technik arbeitet kann man seine Entwicklung besser umsetzen!
Ich nutze viele dieser Tricks, wobei ich gut mit PHP umgehen kann (jemand der sich mit PHP nicht auskennt kann diese 4-5 Zeilen Quelltext schnell einbinden)!
Hört sich gut an, bin auf die neue Artikelserie gespannt.
@Ben:
Der entscheidende Satz ist doch, dass du die CSS-Dateien nur beim ersten Aufruf direkt in den HTML-Code einbettest. Würdest du das nicht tun, wäre das Caching in der Tat umgangen.
CSS-Fingerprinting bedeutet das hier: style.css?v=1
Dadurch musst du den Dateinamen nicht ändern, sondern nur die Referenz im HTML-Dokument anpassen. Der Browser denkt dann, dass es eine neue Datei ist und lädt sie herunter und verwirft die alte. Damit kannst du vorzeitig eine Style-Datei “ablaufen” lassen, wenn du die Cache-Zeit entsprechend hoch gesetzt hast.
> “Das direkte einbinden von CSS Daten in den HTML Head Bereich hat den Vorteil das alle Bereiche, Tabellen, DIV’s SOFORT die richtige Größe haben und an der richtigen Stelle stehen was beim BESUCHER allein schon zu einem Gefühl von mehr Schnelligkeit und damit auch zu einem Eindruck von mehr Professionalität führt”
Wenn du deine Style-Sheet-Datei im HEAD-Bereich einbindest, wird diese normalerweise zuerst geladen, bevor der Browser mit dem Rendern der Seite anfängt. Alles, was im HEAD steht, wird erst heruntergeladen. Das ist übrigens ein Grund, warum man Google Analytics oder große JS-Files nicht in den HEAD packt.
Das subjektive Gefühl von Schnelligkeit spielt bei Tabellen keine Rolle, sondern bei Bildern, wenn der Browser noch nicht weiß, wie groß diese sind, bevor sie heruntergeladen wurden. Abhilfe schafft, die Bildgröße entweder mit width/height in HTML anzugeben oder analog in CSS. Dann wird beim Rendern bereits ein ausreichend großer Platzhalter bereitgestellt, während die Bilder gezogen werden, so dass es keine “Sprünge” beim Rendern des Layouts gibt.
> “Eines der obersten Ziele sollte es sein die Anzahl der Request & damit der Connections auf ein Minimum zu reduzieren!”
Das ist richtig. Die Frage ist nur, ob man mit deinem einbetten in HTML wirklich etwas gewonnen hat. Im Idealfall hast du genau 1 CSS-Datei. Du sparst dir also einen Verbindungsaufbau. Dafür ist jedoch deine HTML-Seite um etliche KB größer, was sich wiederum, je nach Datenverbindung, negativ auf die Ladezeit auswirkt.
Ach halt, du sparst dir ja nicht einmal einen Verbindungsaufbau, weil du zwecks Caching die CSS-Datei ja ohnehin parallel herunterlädst.
Falls das wirklich alles was bringen sollte, schreib doch mal einen Blog-Post dazu, wo du konkrete Beispiele + Benchmarks vorstellst. Das würde mich mal interessieren. Rein von der Theorie her glaube ich aber nicht, dass deine Optimierung etwas bringt.
@Chris: Wenn überhaupt umgehe ich nur (teilweise) das BrowserCaching für CSS Dateien, NCHT ABER für Bilder, JavaScript, XML, etc PP. Es wird also nicht das geamte Browser Caching umgangen und vor allem nicht für die wichtigen (weil großen) Dateien wie Bilder, SVG- oder XML-Dateien! Ich denke es ist wichtig das noch einmal klarzustellen damit Neulinge auf diesem Gebiet nicht verwirrt werden 😉
Okay ich verstehe es ist kompliziert! Aber ich versuchs noch mal 😉
Erst einmal die technische Seite des Website Ladevorganges: Man gibt im Browser eine URL ein und drück auf Enter, dann passiert folgendes:
Senario A (CSS Daten im Head direkt ausgeben): (1) Browser sendet die Anfrage und (2) bekommt als Anwort den HTML Code inkl. CSS Code vom Server => das Rendering beginnt sofort! / Parallel erfolgt das Laden der Bilder die in dem CSS Code genutzt werden
Senario B (CSS Daten via LINK eingebunden): (1) Browser sendet die Anfrage und (2) bekommt als Anwort den HTML Code mit dem Link zu den CSS Daten vom Server (3) der Browser muss wieder eine Anfrage senden um die CSS Datei zu bekommen (4) Server Anwortet und sendet die CSS Datei! => erst jetzt beginnt das Rendering! / Und das Laden der Bilder aus der CSS Datei… (in der Apache Rangliste (aufgrund von (2)) der abzuarbeiten Dateien sind allerdings jetzt die Daten z.B. aus dem Body weiter oben – das können dann auch tertiäre JavaScript Dateien für Funktionen – welche nichts mit dem Layout zu tun habens – sein…)
Zu Senario A (Zitat: “so dass es keine “Sprünge” beim Rendern des Layout gibt”) ja da hast du vollkommen recht es ist wichtig die Höhen und Breiten anzugeben damit auch der von mir bereits erwähnte “gefühlte” Ladevorgang schneller ist! Bei mir sind höhe und Breite in der CSS Datei angegeben! Da weniger Anfragen hin und her gehen ist Senario A aber ohnehin schneller 😉
Zur Technik: {nicht so wichtig aber dennoch …}: I.d.R. stellt ein Browser nur 10 Anfragen auf einmal (war zumindest früher mal so…). Das heißt hier kann es vorkommen das in Senario B zuerst Bilder und JavaScript Dateien aus dem geladen werden bevor die Daten (Bilder) aus der CSS Datei dran sind – oder nicht?
Anmerkung: Vergessen sollte man auch nicht das viele aus “Datenschutz” oder anderen Gründen in den Browser Ihre “Privatsphäre-Einstellungen” erhöht haben, was eben oft dazu führt das wenn der Browser geschlosssen wird alle Dateien die gecached wurden gelöscht werden!
Zitat: “Das subjektive Gefühl von Schnelligkeit spielt bei Tabellen keine Rolle, sondern bei Bildern”! Das sehe ich komplett anders! Viele der Div’s “floaten” häufig (und in manchen Fällen werden leider immer noch Tabellen zum Layouten genutzt) diese Elemente “spannen” sozusagen die einzelnen Flächen auf und geben diesen auch das Aussehen (Hintergrundfarbe, Verläufe, Box-Shadows, abgerundete Rahmen etc. PP){und das wird alles via CSS Code gesteuert…}. Ein großer Teil des Website-Designs welches früher aus Grafiken bestand kann heutzutage vollständig mit CSS dargestellt werden! Also warum beim ersten Ladevorgang eines Besuchers eine weitere unnötige “Browser” to “Server” Komunikation einbauen!?
Zitat: “Im Idealfall hast du genau 1 CSS-Datei” – Dies ist in der Praxis leider häufig nicht der Fall, inbesondere bei komplexen CSS Strukturen (z.B. Apple.com hat 5 CSS Dateien als Link im HEAD eingebunden)!
Nimm einfach mal die URL dieser Seite (selbstaendig-im-netz…) und kopiere diese in tools.pingdom.com. Guck dir den “Waterfall” und “Page Analysis” an. Bei meinem letzten Test hat die Summe der Wartezeit 68% ausgemacht und 25% gingen für die Summe der Connection Time drauf! NUR 4% für die eigentliche Datenübertragung! Selbst wenn wir die bessere “gefühlte” Ladezeit beiseite lassen, und uns nur die tehnische Seite ansehen… Was ist schneller? Sich einen Request zu sparen oder 10-50KB (in einem Rutsch) mehr zu laden? Und vergiss nicht der Apache(-Server) arbeitet eine Liste an Anfragen ab! Je mehr Anfragen (insbesondere in Zeiten in denen es zu Besuchs Sptizen kommt) um so länger wird die “Connection & Wartezeit”! Und wenn du bei pingdom genau hinsieht wirst du erkennen, dass bei Dateien unter 50KB die “Connection + Wartezeit” in 95% der Fälle DEUTLICH mehr als 70% der Ladezeit ausmacht! Folgende Frage muss jeder Website-Betreiber für sich selbst beantworten: Möchte ich möglichst viel Bandbreite einsparen oder dem Besucher die schnellstmögliche Websitedarstellung ermöglichen?
Zitat: “Ach halt, du sparst dir ja nicht einmal einen Verbindungsaufbau, weil du zwecks Caching die CSS-Datei ja ohnehin parallel herunterlädst.” Das stimmt nicht ganz die CSS Datei wird einen “Schritt/Connection+Wartezeit” später heruntergeladen NICHT parallel – das ist ein Unterschied!
Es ist vielleicht nur eine Kleinigkeit aber der ERSTE EINDRUCK des Besuchers, wird damit positiv beeinflusst. Wir reden hier ja NUR von dem aller ersten Seitenaufruf eines Besucher, ich kann mir gut vorstellen, dass dies für viele Webmaster zuviel Aufwand ist, aber für Personen die Ahnung von PHP haben ist es ein minimaler Aufwand und zudem ein kleiner Wettbewerbsvorteil!
P.S.: Google Analytics sollte man übrigends immer in den Head packen, das hat aber eher technische Gründe, die nichts mit PageSpeed zu tun haben…
Danke Ben, dass du dir die Zeit genommen hast, das nochmal genauer zu erklären. Ich werde einmal ein paar Tests anstellen und gucken, in welcher Reihenfolge nun was geladen wird und welchen Einfluss das direkte Einbinden auf meine Seite hat.
Bzgl. GA: Ist halt ein Tradeoff, ob man im HEAD auf eine Verbindung zu einem externen Server wartet und dafür auch abgebrochene Seitenaufrufe erfassen kann oder ob man die abgebrochenen Aufrufe außen vor lässt und dafür etwas mehr Speed bekommt. Ich verwende eh kein GA 😉
Interessant, bin gespannt auf die weiteren Tests und Informationen!
Hmm meine Antwortzeit vom Server beträgt 2,7 Sekunden !!!!
Bin bei Hosteurope und hab den WebServer Basic L.
Okay die lange Antwortzeit lag nicht am Server selbst sondern an WordPress und den langen Ladezeiten. WP Super Cache installiert und alle Vorschläge von Google Page Insights befolgt, siehe da Seite läd in 200ms 🙂
Ich denk wie Ben dass mod_pagespeed richtig konfiguriert ebenso noch einen zusätzlichen kleinen Boost an Geschwindigkeit bringen kann. Zwar nicht unbedingt in Bezug auf die Response Time, aber in Bezug auf die Ladezeit der Seite.
Ich hatte 902ms bei Webhost-United und bin mit meinem Umzug zu All-Incl Privat Plus auf 1.112ms gestiegen. Trotz (nicht-konfiguriertem) WP Super Cache.
Daraufhin hab ich mir das Plugin mal näher angeschaut und einige Einstellungen vorgenommen. Jetzt lieg ich auch bei einem Overall Average (Europe) von 185 Millisekunden.