Im letzten deutschen Google Webmaster Hangout hat John Mueller eine tolle Präsentation über Page Speed gehalten. Wir haben natürlich fleißig mitgeschrieben, die wichtigsten Aussagen findet ihr also hier.
URL und Seite sind zwei unterschiedliche Elemente, die aber trotzdem zusammen gehören. Denn wenn man die ganze Seite darstellen will, muss man die Einzelteile auch herunterladen.
Dies sind die einzelnen Elemente, die für den Speed eine Rolle spielen. Diese werden alle nacheinander durchgeführt und ergeben zusammengenommen die Gesamtzeit.
In den Netzwerkeinstellungen in Chrome kann man sich sehr genau ansehen, welcher Vorgang wie lange dauert. Das alles passiert pro URL, also pro Element auf einer Seite.
Bei Google hat das Einfluss auf die Crawlgeschwindigkeit - also die Anzahl an Seiten, die pro Tag gecrawlt werden können. Das meint nicht nur die HTML Seiten, sondern auch alle Inhalte.
Wir versuchen, die Crawl Rate pro Server zu bestimmen - dies zeigt dann an, wie viel wir maximal auf einen Server verwenden können. Für uns ist das wichtig, da wir den Server nicht überlasten wollen. Trotzdem möchten wir die Inhalte natürlich so schnell wie möglich holen und indexieren.
Wir schauen uns beim Bestimmen der Crawl Rate nicht nur die Zeit pro URL an, sondern auch Dinge wie Server Fehler und die Zeit, wie schnell der Server auf Anfragen reagiert. Diese Daten nutzen wir dann, um unsere Crawl Rate anzupassen. Wenn der Server es zulässt, crawlen wir mehr - und wenn es Probleme gibt, dann weniger.
In Search Console kann man sich die entsprechenden Statistiken gut ansehen. Man sieht, wie viele Seiten pro Tag gecrawlt wurden und man sieht, wenn große Veränderungen stattfinden. Dann kann man sich überlegen, woran das liegt und den Problemen näher kommen.
Man sieht auch die Menge an Daten, die pro Tag heruntergeladen worden ist und die durchschnittliche Crawlzeit, die eine einzelne Seite gebraucht hat. Diese Dinge sind für uns natürlich eher im Hintergrund relevant. Denn wir möchten jede Seite erst einmal crawlen, da wir sie ohne Crawling nicht sauber indexieren und darstellen können.
Manchmal crawlen wir aber auch zu viel und verursachen dadurch Probleme. Das kann grad bei großen Hostern, wo dann ein weiterer Server zugeschaltet wird, teuer werden. Wichtig ist dabei, systematisch vorzugehen und nachzuforschen, warum so viel gecrawlt wird.
In einem ersten Schritt sollte man die IP-Adressen kontrollieren uns schauen, ob die alle zu uns gehören. Oft crawlen Leute mit unserem User Agent, obwohl sie gar nicht zu Google gehören. Solche Dinge sollte man dann blockieren.
In Search Console würde ich auch überlegen, welche URLs gecrawlt werden sind. Vielleicht sind es sehr ähnliche URLs, die auf Duplicate Content hinauslaufen. Vielleicht kann man also systematische Dinge an der eigenen Website verbessern, damit Google nicht mehr so viel crawlen muss.
So sehen die Crawl Rate Einstellungen in Search Console aus. Hier gibt es auch Links für mehr Informationen und zum Senden eines Fehlerreports. Die Crawl Rate wird hier als die maximale Crawl Rate dargestellt.
Es ist also nicht so, dass man den Hebel hochstellen kann und Google crawlt dann mehr. Der Gedanke dahinter ist, dass man den Hebel runterstellen kann, wenn man erreichen möchte, dass Google weniger crawlt.
Wir versuchen dann immer, so viel zu crawlen wie wir können. Das hängt aber auch davon ab, ob wir sehen, dass die entsprechende Seite eher statisch ist oder alternativ ob sie viele neue Inhalte hat.
Bei der ganzen Seite kommen noch einige zusätzliche Schritte hinzu. Auch hier gilt, dass jedes dieser Elemente abrufbar sein und ausgeführt werden muss. Es kann also mehrere Schritte geben, bis wirklich alles dargestellt ist - grade bei JavaScript und CSS.
Für mehr Infos empfehle ich euch diese beiden Präsentationen. Es gibt auch viele andere Dokumente, die man beachten sollte. Denn ich beziehe mich hier vor allem auf die Sachen, die für Google wichtig sind.
Auf der einen Seite müssen wir die Inhalte im Googlebot Browser darstellen, damit wir sie danach vernünftig indexieren können. Dafür ist also nicht nur die HTML Seite wichtig, sondern auch alles, was darin eingebunden ist.
Das Ganze ist für uns auch ein kleiner Ranking Faktor. Wir differenzieren dabei vor allem zwischen Seiten, die normal laden - und solchen, die extrem langsam sind. Ein paar Millisekunden werden also keinen Ranking Boost verschaffen.
Indirekt sehen wir natürlich auch, dass Nutzer, die auf einer schnellen Seite landen, dort vielleicht mehr machen oder sogar mehr einkaufen. Diese Nutzersignale (wie zum Beispiel Empfehlungen) können extrem helfen und sind meiner Meinung nach wichtiger als irgendein Ranking Faktor.
Je mehr Elemente eine Site hat, desto mehr müssen wir herunterladen. Und oft sehen wir, dass Elemente mit einer ID mit einem Timestamp versehen sind, eine Session ID haben, oder das JavaScript mit einem Parameter versehen ist.
Und je mehr das wird, umso langsamer wird das Indexieren. Man sollte also Caching nutzen und überall, wo es geht, optimieren. So können wir zum Beispiel die JavaScript Datei einmal herunterladen und dann mehrfach wiederverwenden.
Wie es um den Page Speed bestellt ist kann man zum Beispiel mit PageSpeed Insights testen. Diese Zahl ist aber sehr grob und ich würde sie quasi als ersten Hinweis nehmen - einfach um zu sehen, ob es ein Problem gibt oder nicht. Wenn man Dinge wirklich gezielt angehen will, dann würde ich mit genaueren Tools arbeiten.
Es gibt zum Beispiel die Möglichkeit, sich das direkt im Browser anzuschauen. Da kann man unter anderem den Netzwerkverkehr darstellen. Dort sieht man dann sehr schön, wie die einzelnen Dateien heruntergeladen werden - und wie sie hintereinander geladen werden.
Das Gleiche geht auch mit einigen Online Tools. Auch hier gibt es Diagramme, die über den Prozess Aufschluss geben.
Dann habe ich noch zwei kurze Tipps. Grade mit dem Rendering sollte man dafür sorgen, dass es pro URL keine Engpässe gibt. Hier kann das Caching helfen.
Und die Darstellung im Browser würde ich für den Benutzer optimieren. Dazu gibt es viele Tipps, zum Beispiel in den oben genannten Präsentationen. Und wenn es dann für den Nutzer gut funktioniert, läuft es auch für Google.
URL und Seite sind zwei unterschiedliche Elemente, die aber trotzdem zusammen gehören. Denn wenn man die ganze Seite darstellen will, muss man die Einzelteile auch herunterladen.
Dies sind die einzelnen Elemente, die für den Speed eine Rolle spielen. Diese werden alle nacheinander durchgeführt und ergeben zusammengenommen die Gesamtzeit.
In den Netzwerkeinstellungen in Chrome kann man sich sehr genau ansehen, welcher Vorgang wie lange dauert. Das alles passiert pro URL, also pro Element auf einer Seite.
Bei Google hat das Einfluss auf die Crawlgeschwindigkeit - also die Anzahl an Seiten, die pro Tag gecrawlt werden können. Das meint nicht nur die HTML Seiten, sondern auch alle Inhalte.
Wir versuchen, die Crawl Rate pro Server zu bestimmen - dies zeigt dann an, wie viel wir maximal auf einen Server verwenden können. Für uns ist das wichtig, da wir den Server nicht überlasten wollen. Trotzdem möchten wir die Inhalte natürlich so schnell wie möglich holen und indexieren.
Wir schauen uns beim Bestimmen der Crawl Rate nicht nur die Zeit pro URL an, sondern auch Dinge wie Server Fehler und die Zeit, wie schnell der Server auf Anfragen reagiert. Diese Daten nutzen wir dann, um unsere Crawl Rate anzupassen. Wenn der Server es zulässt, crawlen wir mehr - und wenn es Probleme gibt, dann weniger.
In Search Console kann man sich die entsprechenden Statistiken gut ansehen. Man sieht, wie viele Seiten pro Tag gecrawlt wurden und man sieht, wenn große Veränderungen stattfinden. Dann kann man sich überlegen, woran das liegt und den Problemen näher kommen.
Man sieht auch die Menge an Daten, die pro Tag heruntergeladen worden ist und die durchschnittliche Crawlzeit, die eine einzelne Seite gebraucht hat. Diese Dinge sind für uns natürlich eher im Hintergrund relevant. Denn wir möchten jede Seite erst einmal crawlen, da wir sie ohne Crawling nicht sauber indexieren und darstellen können.
Manchmal crawlen wir aber auch zu viel und verursachen dadurch Probleme. Das kann grad bei großen Hostern, wo dann ein weiterer Server zugeschaltet wird, teuer werden. Wichtig ist dabei, systematisch vorzugehen und nachzuforschen, warum so viel gecrawlt wird.
In einem ersten Schritt sollte man die IP-Adressen kontrollieren uns schauen, ob die alle zu uns gehören. Oft crawlen Leute mit unserem User Agent, obwohl sie gar nicht zu Google gehören. Solche Dinge sollte man dann blockieren.
In Search Console würde ich auch überlegen, welche URLs gecrawlt werden sind. Vielleicht sind es sehr ähnliche URLs, die auf Duplicate Content hinauslaufen. Vielleicht kann man also systematische Dinge an der eigenen Website verbessern, damit Google nicht mehr so viel crawlen muss.
So sehen die Crawl Rate Einstellungen in Search Console aus. Hier gibt es auch Links für mehr Informationen und zum Senden eines Fehlerreports. Die Crawl Rate wird hier als die maximale Crawl Rate dargestellt.
Es ist also nicht so, dass man den Hebel hochstellen kann und Google crawlt dann mehr. Der Gedanke dahinter ist, dass man den Hebel runterstellen kann, wenn man erreichen möchte, dass Google weniger crawlt.
Wir versuchen dann immer, so viel zu crawlen wie wir können. Das hängt aber auch davon ab, ob wir sehen, dass die entsprechende Seite eher statisch ist oder alternativ ob sie viele neue Inhalte hat.
Bei der ganzen Seite kommen noch einige zusätzliche Schritte hinzu. Auch hier gilt, dass jedes dieser Elemente abrufbar sein und ausgeführt werden muss. Es kann also mehrere Schritte geben, bis wirklich alles dargestellt ist - grade bei JavaScript und CSS.
Für mehr Infos empfehle ich euch diese beiden Präsentationen. Es gibt auch viele andere Dokumente, die man beachten sollte. Denn ich beziehe mich hier vor allem auf die Sachen, die für Google wichtig sind.
Auf der einen Seite müssen wir die Inhalte im Googlebot Browser darstellen, damit wir sie danach vernünftig indexieren können. Dafür ist also nicht nur die HTML Seite wichtig, sondern auch alles, was darin eingebunden ist.
Das Ganze ist für uns auch ein kleiner Ranking Faktor. Wir differenzieren dabei vor allem zwischen Seiten, die normal laden - und solchen, die extrem langsam sind. Ein paar Millisekunden werden also keinen Ranking Boost verschaffen.
Indirekt sehen wir natürlich auch, dass Nutzer, die auf einer schnellen Seite landen, dort vielleicht mehr machen oder sogar mehr einkaufen. Diese Nutzersignale (wie zum Beispiel Empfehlungen) können extrem helfen und sind meiner Meinung nach wichtiger als irgendein Ranking Faktor.
Je mehr Elemente eine Site hat, desto mehr müssen wir herunterladen. Und oft sehen wir, dass Elemente mit einer ID mit einem Timestamp versehen sind, eine Session ID haben, oder das JavaScript mit einem Parameter versehen ist.
Und je mehr das wird, umso langsamer wird das Indexieren. Man sollte also Caching nutzen und überall, wo es geht, optimieren. So können wir zum Beispiel die JavaScript Datei einmal herunterladen und dann mehrfach wiederverwenden.
Wie es um den Page Speed bestellt ist kann man zum Beispiel mit PageSpeed Insights testen. Diese Zahl ist aber sehr grob und ich würde sie quasi als ersten Hinweis nehmen - einfach um zu sehen, ob es ein Problem gibt oder nicht. Wenn man Dinge wirklich gezielt angehen will, dann würde ich mit genaueren Tools arbeiten.
Es gibt zum Beispiel die Möglichkeit, sich das direkt im Browser anzuschauen. Da kann man unter anderem den Netzwerkverkehr darstellen. Dort sieht man dann sehr schön, wie die einzelnen Dateien heruntergeladen werden - und wie sie hintereinander geladen werden.
Das Gleiche geht auch mit einigen Online Tools. Auch hier gibt es Diagramme, die über den Prozess Aufschluss geben.
Dann habe ich noch zwei kurze Tipps. Grade mit dem Rendering sollte man dafür sorgen, dass es pro URL keine Engpässe gibt. Hier kann das Caching helfen.
Und die Darstellung im Browser würde ich für den Benutzer optimieren. Dazu gibt es viele Tipps, zum Beispiel in den oben genannten Präsentationen. Und wenn es dann für den Nutzer gut funktioniert, läuft es auch für Google.