Antwortzeitmessung in ms - wie auf CB

[FIL11]

Hallo Forumsgemeinde,
ich möchte die Antworzeit meiner Webseite messen. Ich hab den Eindruck, dass auf meiner Seite eine erhöhte Antwortzeit vorliegt ( auf seitenreport.de wird diese mit 800 - 900 ms angegeben ), Vergleichsseiten, die ich ebenfalls beim gleichen Hoster habe, antworten schneller. Der Support meinte, das könne man mit externen Tools nicht messen, bzw. hätten sie keine erhöhte Antwortzeit festgestellt.

Jetzt frage ich mich, ob ich zu Testzwecken, wie unten bei CB die Antwortzeit in ms ausgeben kann oder gibt es eine andere Möglichkeit, diese Ladezeit nachzuweisen, da mir 800 ms sehr lange vorkommen. So langsam reagiert die Seite jedoch auch nicht ... aber

manche User haben mir rückgemeldet, dass die Seite (zumindest beim alten WP-Theme) eine Weile stehen bleibt und dann erst lädt.

Habt ihr Vorschläge?
Danke schonmal.

 

[DaDare]

Hier stand mist.

 

[Xidus]

Start -> cmd (Console) -> ping www.deineWebseite.de

Wenn du Chrome hast kannst du mit Strg + Umschalt + I auch die Entwicklerkonsole öffnen da kannst du Ladezeiten Fehler und so sehen

z.B. unter dem Reiter Netzwerk kannst du wenn du die Seite lädst sehen wie lange die einzelnen Elemente und die Ganze Seite zum laden braucht

 

[McMOK]

Hallo, du kannst deine Website mit dem Firefoxflugin genannt "Firebug" gezielt nachschauen.

 

[Deathcore]

Start -> cmd (Console) -> ping www.deineWebseite.de

Ist dann aber nicht die Antwortzeit vom Apache Sondern nur vom Server .....

 

[redeye86]

Du schreibst ja, dass du Wordpress einsetzt. Dann kannst du ganz einfach folgendes machen um die Berechnungszeit der Seite herauszubekommen:

Datum Millisekundengenau sowohl am Anfang als auch beim Ende der Seite messen, ersten von zweitem Wert subtrahieren und ausgeben. Willst du dem Übeltäter dann noch weiter auf die Spur kommen, kannst du den Messbereich dann natürlich auf einzelne Bereiche beschränken.

Anfgang:

<?php
$starttime=microtime(1);
...

Ende:

...
echo '<!-- Page Generation Time: '.(microtime(1)-$starttime).'s-->';
?>

Sollten diese Werte nicht auffällig lang sein, solltest du nachsehen, ob bestimmte Bilder etc besonders lange brauchen oder beim Caching irgendwas nicht richtig eingestellt ist.

 

[Daaron]

Einen Blick solltest du auch auf die Time To First Byte werfen. Gibt verschiedene Online-Tools, um selbige zu messen. Bei der TtFB wird nur gemessen, wie lange der Webserver benötigt, um (vom Moment der Client-Anfrage an) alle Ressourcen zusammenzustellen und eben das erste Byte der Antwort zu senden. In dieser Zeitspanne ist nur die reine Rechenzeit des Servers (abzgl. per AJAX geladener Content) drin, keine Ladezeit für riesige Grafiken, langsame JavaScripts,...

 

[FIL11]

Ich schätze, Time To First Byte trifft es am ehesten - da mich nicht die Ladezeit der kompletten Webseite interessiert, sondern lediglich Serverabhängige Missstände. Ich suche mal nach passenden Tools.

EDIT: bytecheck.com liefert mit Werte zwischen 1,2 und 1,3 Sekunden. Liegt das am Server, oder kann ich da selber etwas tun? Die Seite von meinem Vater beim gleichen Anbieter hat 0,5 Sekunden.

 

[Daaron]

Schreib mal die oben genannte Mess-Methode via microtime() in dein WP-Theme. Von da aus musst du es dann jeweils eingrenzen.

 

[FIL11]

Wo genau soll ich das einfügen?

 

[Daaron]

im zweifel, schreib die index.php einfach um.

 

[FIL11]

Ich vermute den Fehler woanders.
Wenn ich auf bytecheck.com meine Adresse ohne WWW eingebe, erhalte ich eine TTFB, die Faktor 3 - 4 kleiner ist. Also um die 300 ms. Gibt das Aufschluss über einen Konfigurationsfehler? Stichwort: Duplicate Content?

Sind nur Vermutungen meinerseits, da die Ladezeit der Webseite (ab dem ersten erhaltenen Byte) durchaus vertretbar ist - vorallem jetzt, wo ich Browser Caching aktiviert habe.

EDIT: Auch im Seitenreport.de Bericht wird mir jetzt eine Antwortzeit von 34 ms ausgegeben, nur weil ich es ohne WWW eingegeben habe??

 

[ice-breaker]

Leitet eventuell die www-Seite auf die non-www-Seite weiter? Dann hast du nämlich noch einen weiteren Request drinne, aber 3-4 kleiner ist dafür auch zu hoch.
Lege doch einfach mal offen, um welche Seite es sich handelt.

Falls es sich um den Foto-Blog handelt:
Wenn da mal die Ladezeit nicht stimmt, würde mich das nicht wundern. Da werden 20 (!!) JavaScript-Dateien vom gleichen Server eingebunden. Da brauch der Server nur mal einen Cache Miss haben und die Datei von der Platte laden müssen, oder die lokale Internetverbindung braucht mal länger und die Seite lädt länger.

Du solltest mal im Chrome in den Entwicklertools den Audit laufen lassen, Google hat da wirklich in einem nützlichen Tools schon viele Optimierungsvorschläge zusammengetragen.

 

[FIL11]

Siehe Signatur - erster Link.
Ja, ich schätze durch meine .htaccess kommt ein weiterer request zustande. Aber so einen großen Unterschied kann das doch nicht machen.

EDIT: Meine .htaccess

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule> 

<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access 2 days"
ExpiresByType image/gif "access 1 month"
ExpiresByType image/jpeg "access 2 weeks" 
ExpiresByType image/jpg "access 2 weeks"
ExpiresByType image/png "access 2 weeks"
ExpiresByType text/css "access 1 month"
ExpiresByType text/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType text/xml "access plus 1 seconds" 
ExpiresByType image/x-icon "access 1 year"
</IfModule>

# END WordPress

EDIT 2:

Falls es sich um den Foto-Blog handelt:
Wenn da mal die Ladezeit nicht stimmt, würde mich das nicht wundern. Da werden 20 (!!) JavaScript-Dateien vom gleichen Server eingebunden. Da brauch der Server nur mal einen Cache Miss haben und die Datei von der Platte laden müssen, oder die lokale Internetverbindung braucht mal länger und die Seite lädt länger.

Mit der Ladezeit habe ich keine Probleme - aber weshalb ist es ohne WWW soviel schneller? Ohne WWW werden schließlich auch alle 20 JavaScript-Dateien geladen (auf die ich keinerlei Einfluss habe, das Theme ist nicht von mir).

 

[ice-breaker]

Na ist doch klar wieso: Ohne www machst du direkt vom Apache aus einen 302 Redirect auf die www-Seite. Der ist natürlich affig schnell, er muss ja auch nichts machen. Die ganzen Tools, die du getestet hast steigen da scheinbar aus und für die ist die Anfrage fertig. Aber in echt beginnt jetzt erst die Arbeit.

Die einzelne ohne-www Anfrage ist also affig schnell (kein HTTP Response Body und kein PHP) leitet aber auf die www weiter. Aber als ganzes betrachtet ist ohne www langsamer, da es die Weiterleitung machen muss und nachher die Seite aufrufen. Wiedermal ein schönes Beispiel für besch****** Tools.

Und mit der Ladezeit hast du beachtliche Profiler, 2 Sekunden bis das Darstellen beginnt ist extremst langsam.

 

[FIL11]

Verstehe - im Grunde also ein Berechnungsfehler.
Nun kam mir auch der Gedanke, dass von meinem Hosting Anbieter eine Einstellung bereitgestellt wird, mit der ich wählen kann, ob die Seite auch ohne WWW erreicht werden kann. Dort habe ich diese Einstellung bejaht.

In der .htaccess ist aber ebenfalls eine Weiterleitung. Macht auf mich den Eindruck, als wäre eines davon überflüssig, oder sogar hinderlich.

Wenn wir jetzt von der affig-schnellen Variante absehen, habe ich im Endeffekt erst recht wieder eine lange TTFB, richtig? Liegt das am Webhosting Paket oder an meiner Webseite?

Falls ja, ich wollte auch noch gzip aktivieren, aber da werkelt mir ein Slider Plugin dazwischen, welches anschließend nicht mehr funktionieren will. Bin unterm Strich etwas ratlos, wo ich bei der Optimierung ansetzen soll.

 

[Daaron]

Verstehe - im Grunde also ein Berechnungsfehler.
Nun kam mir auch der Gedanke, dass von meinem Hosting Anbieter eine Einstellung bereitgestellt wird, mit der ich wählen kann, ob die Seite auch ohne WWW erreicht werden kann. Dort habe ich diese Einstellung bejaht.

Ist ja auch richtig so.
Tatsächlich ist deinedomain.de sogar richtiger als www.deinedomain.de, da www eine Subdomain von deinedomain.de wäre.

SEO-technisch sollte entweder none-www auf www leiten (was nicht wirklich korrekt ist) oder www leitet auf none-www. Und natürlich sollten sonstige Alias-Domains auch auf die Stamm-Domain leiten.

In der .htaccess ist aber ebenfalls eine Weiterleitung. Macht auf mich den Eindruck, als wäre eines davon überflüssig, oder sogar hinderlich.

Ich seh da nix überflüssiges. Das sind nur die Rewrite-Regeln für "hübsche" und SEO-freundliche URLs. Niemand will eine index.php?pageid=34 aufrufen, wenn er statt dessen die news.html aufrufen kann.

Wenn wir jetzt von der affig-schnellen Variante absehen, habe ich im Endeffekt erst recht wieder eine lange TTFB, richtig? Liegt das am Webhosting Paket oder an meiner Webseite?

Replizier deine Seite inkl. Datenbank auf deinen lokalen PC, setz dir einen XAMPP-Server auf. Ruf deine lokale Version von einem anderen PC im LAN auf. Wenn es jetzt wieder überraschend lange dauert, dann ist dein Script scheiße.

Falls ja, ich wollte auch noch gzip aktivieren, aber da werkelt mir ein Slider Plugin dazwischen, welches anschließend nicht mehr funktionieren will. Bin unterm Strich etwas ratlos, wo ich bei der Optimierung ansetzen soll.

Ich versteh nicht, wie ein Slider bei gzip ein Problem machen könnte. Im Zweifel: Schmeiß ihn weg. Es gibt 100000 Slider-Tools, die sogar mit Markup-Optimierungstools noch funktionieren.

Der erste Ansatz wäre trotzdem der Test mit der Microtime. Immer weiter einengen bis du weißt, welche Funktion hier so lange braucht.
Ach ja, und natürlich etwas Database-Profiling. Besorg dir ein Datenbank-Log und such nach Slow Queries.

 

[ice-breaker]

Neija erstmal musst du die Bedeutung von TTFB verstehen. Das ist die Zeit, bis nach dem Senden der Anfrage das allererste Byte vom Server empfangen wurde. Wenn Wordpress (ich weiß nicht wie es arbeitet) die gesamte Antwort erst buffered und sendet wenn alles fertig ist (Output Buffering) dann wird TTFB der Zeit der TCP-Pakete + der Generierung der Seite dauern.
An dem Punkt muss ich daaron eben widersprechen, ich halte TTFB in diesem Fall für einen der unwichtigsten Werte, da man keinerlei nützliche Informationen herausgewinnen kann. der TTFB wird bei der PHP-Zeit + Apache Zeit (minimal) + Zeit für TCP (liegen).
Der TTFB ist also nur sinnvoll um Fehlkonfiguration/Misstände der letzten beiden zu erkennen, und dazu müsste PHP z.B. sofort ein Byte senden und nicht erst die ganze Antwort generieren.

Aber: Dein Webspace braucht auch 800ms um diese Antwort zu erzeugen, also ist da auf jedenfall Optimierungsbedarf vorhanden. Für Wordpress wird es sicherlich z.B. ein Caching-Plugin geben, das könnte schonmal einiges bringen.
Dann wäre das Senden eines Expires-HEader sinnvoll, dass nicht für jeden Request wieder die 70 Dateien beim Server auf Veränderungen angefragt werden müssen, das wird die visuelle Ladezeit nochmal deutlich verschnellern.
Das sind die beiden "Low Hanging Fruits" die deine Seite sofort visuell deutlich schneller machen sollten.

Gzip ist auch eine gute Idee, aber mit dem Slider Plugin hat das nichts zu tun. Wenn da nachher irgendetwas nicht mehr stimmt, hat das andere Gründe - liegt aber nicht am Gzip.


@Daaron: Ich habe so die Vermutung, dass er mit Profiling des PHP-Codes und der Datenbank etwas überfordert sein wird. Nach dem was ich lese, klingt er nicht wie ein Backend-Entwickler

 

[FIL11]

Brauche ich denn ein Caching Plugin, ich habe schließlich in der .htaccess Leverage Browser Caching aktiviert mit ExpiresHeaders(?).
Was gzip betrifft, ich kann mir nicht erklären, warum der Slider nicht mehr geht bzw. der große Slider funktioniert, nur klappt es nicht mehr in Blog Artikel - dort kann man den Slider nämlich per shortcode integrieren. Also so eine Mini-Variante.

EDIT: Habe jetzt gzip aktiviert, jetzt haben meine Artikel weder die Social Plugins auf der linken Seite, noch funktioniert der Slider. :-(

EDIT 2: Außerdem funktionieren dann nicht meine tabs, wie unten auf meiner Startseite (Anzahl: 4), in den Artikeln. Komisch.

 

[Daaron]

Man sollte immer auf verschiedene Cache-Funktionen zurück greifen, umabhängig davon was die .htaccess sagt.

Um mal zu klarieren, was was macht:
1.) .htaccess cache time sagt dem Browser: Wenn du innerhalb von X Tagen schon einmal hier warst, dann brauchst du das und das nicht neu laden. Pro BESUCHER müssen trotzdem alle PHP-Funktionen durchgeführt werden.
2.) PHP - Cache wie z.B. APC (bei Shared Hostern kaum nutzbar): PHP-Code wird für die Ausführung kompiliert. Der Cache lagert jetzt die vorkompilierten Scripte. Ist verdammt schnell, geht aber nur mit mod_php und evtl. FCGI, nicht mit suPHP (und Shared Hosting läuft aus Sicherheitsgründen meist über suPHP)
3.) Script-internes Caching: Sinngemäß wird regelmäßig (entweder per Cronjob oder sobald jemand die Seite aufruft) die Seite aufgebaut und als als reiner HTML-Code irgendwo in einem Cache-Ordner gelagert. Kommt jetzt ein neuer Besucher, dann erhält er der gecachten HTML-Code, anstatt das alles neu berechnet wird.
4.) Datenbank Query Cache: Eine gut konfigurierte Datenbank (da hast du als Anwender keinen Einfluss) führt einen Cache über die Ergebnisse von Anfragen. Kommt eine Anfrage zum ersten Mal, dauert sie eben so lange wie nötig. Kommt sie danach ncoh einmal (unverändert), wird blitzschnell die Antwort aus dem Cache geliefert.