Neue Analyse: HTTP Requests (Seite 2)

... das freut mich doch auch sehr!

Ich finde im übrigen das die Requests als Bestandteil der Analyse sehr sinnvoll sind und die Analyse vervollständigen.

Ich freue mich über jede sinnvolle Erweiterung, auch wenn meine Seiten dabei schlecht wegkommen. - Ich möchte ja verbessern und optimieren und mir nicht auf die Schulter klopfen lassen.

Viele Grüße,

Gabriel

Sicherlich ist die Request Analyse für ein Analyse-Tool wie Seitenreport praktisch und bringt einen Mehrwert mit, aber ich bin mir nicht sicher, wie Aussagekräftig dieser Aspekt ist.

Natürlich muss man das ganze nicht unnötig in die Höhe treiben, aber wer etwas mehr Wert auf optische Gestaltung in seiner Webseite legt und höchstwahrscheinlich ein CMS benutzt, wird sehr schnell auf einige Request kommen. (Hier dürfen sich viele Webmaster auf die Analyse freuen, sobald die Css Dateien ausgewertet werden ... da ist sicherlich bei einigen Holland in Not! )

Ebenso glaube ich, dass im Punkt Datentransfer damit nun auf viele der hier gelisteten und bewerteten Seiten Arbeit zukommt, wenn die bislang erreichte Bewertung gehalten werden soll.

Ich selber schließe mich mal an, dass "x Requests = Wert y" nicht allgemeingültig ist und damit diese Bewertung mir mehr dazu dient einen Webmaster diesbezüglich auf eine Optimierungsmöglichkeit hinzuweisen. (Anzahl eizubindender Dateien minimieren)

Interessant wäre es (nicht nur in diesem Analysepunkt) wenn es möglich wäre sich gleich detailiertere Informationen anzeigen lassen zu können, um zu sehen, wodurch die Requests erzeugt werden. Sprich, eine Auflistung der eingebundenen Dateien.

Ist es angedacht, dass mit Einbezug der Css Dateien auch die Bewertungsgrenzen verändert werden?

Gibts es genauere Informationen, in wiefern Goolge die Request Analyse einbezieht und welche Werte als erstrebenswert (UND realistisch) erachtet werden?

Beste Grüße

ps: Ich selber finde wichtig, dass jedem Webmaster folgendes klar sein sollte:
Der Wert einer Webseite steigert sich nicht zwangsweise, indem das hier Angegebene Optimum an Request erreicht wird, aber dadurch logische Strukturen usw. verloren gehen.

Guten Morgen Christoph,

kermit767 schrieb:
Sicherlich ist die Request Analyse für ein Analyse-Tool wie Seitenreport praktisch und bringt einen Mehrwert mit, aber ich bin mir nicht sicher, wie Aussagekräftig dieser Aspekt ist.

Meiner Meinung nach, soll die reine Anzahl der Requests dem Seitenbetreiber erste einmal zeigen, wie ökonomisch er mit den gegebenen Ressourcen umgeht.
Jeder Request muss einzeln auf dem Server verarbeitet werden; und das kostet Zeit. Falls sich der Webserver nicht gerade im Leerlauf befindet, geht der Request in eine Queue und muss auf seine Verarbeitung warten. Bei der Verarbeitung selbst sind auch eineige Schritte nötig. Eine Grafik beispielsweise, muss auch erst von der Platte in den Speicher geladen werden bevor sie zum Client gestreamed werden kann. So verhält es sich mit jedem Objekt, welches zur Verwendung in der jeweiligen Seite aufgeführt ist.
Das Szeanrio gilt eigentlich nur für den ersten Request, oder wenn kein Server-Caching verwendet wird. Aber du kannst dir im großen und ganzen vorstellen, worauf ich hinaus will.

kermit767 schrieb:
Interessant wäre es (nicht nur in diesem Analysepunkt) wenn es möglich wäre sich gleich detailiertere Informationen anzeigen lassen zu können, um zu sehen, wodurch die Requests erzeugt werden. Sprich, eine Auflistung der eingebundenen Dateien.

Das kannst du selbst, in dem du jedes Objekt in deinem Quellcode unter die Lupe nimmst, welches über die Eigenschaft src= verfügt und somit als eigenes Objekt in einem eigenem Request verarbeitet wird.

kermit767 schrieb:
Gibts es genauere Informationen, in wiefern Goolge die Request Analyse einbezieht und welche Werte als erstrebenswert (UND realistisch) erachtet werden?

Google dürfte nicht die anzahl der Requests verarbeiten, sondern die daraus resultierende Ladezeit einer Seite. Da jeder Request etwas zusätzliche Zeit benötigt, kann sich das schnell aufsummieren.

kermit767 schrieb:
ps: Ich selber finde wichtig, dass jedem Webmaster folgendes klar sein sollte:
Der Wert einer Webseite steigert sich nicht zwangsweise, indem das hier Angegebene Optimum an Request erreicht wird, aber dadurch logische Strukturen usw. verloren gehen.

Mein reden
All die Analyseseiten geben dir nur ein Werkzeug an die Hand. Wie du es nutzt ist deine Sache.

Servus,
Klaus

klaus_b@.NET über alles was an .NET und C# Spass macht.

RobbyMe schrieb:

Du hast soweit ich sehe noch viele Möglichkeiten mit Sprites und zusammenfassen der Css und Java Dateien Deine Seite zu optimieren.

Hallo Robert,
JS werden mit den Extension dyn. eingebunden!? CSS sind schon zusammengefasst bis auf die wieder, die dyn. per Ext. eingebunden werden.
\'n paar Sprites habe ich schon eingebaut.

RobbyMe schrieb:

Besonders Deine Bookmarkbutton könntest Du auf jeden Fall zusammenfassen.

das habe ich versucht aber ich müsste die Extension dazu umschreiben. Es wird ja mit dieser Ext. dynamisch die aktuelle Seite an den Dienst (Wong & Co.) übergeben. Beim Aufbau der Links nimmt die Ext ja immer das zum Dienst gehörende Icon.

Ãœbrigens, danke für Eure Beiträge!

So, ich habe die o.a. Extension geändert, Sie bringt jetzt keine Icons mehr, sondern nur a-tags mit einer Klasse.
Bin also von anfangs 28 Requests auf jetzt 12 runter gekommen = 80%.
Wenn ich mir die Seite aber mal mit yslow betrachte und dort auf "Smal-sites or Blog" analysiere, dann komme ich auf 99 von 100 trotz der dort festgestellten 18 Requests!
Es besteht also eine Differenz von 6 Requests!?
Lt. YSLOW gibt es:
1 x HTML
2 x JS
2 x CSS
6 x css-images
6 x images
1 x favicon
Was wird denn in seitenreport NICHT mitgezählt?

KurtKK schrieb:

Es besteht also eine Differenz von 6 Requests!?
Lt. YSLOW gibt es:
1 x HTML
2 x JS
2 x CSS
6 x css-images
6 x images
1 x favicon
Was wird denn in seitenreport NICHT mitgezählt?

Die 6 CSS-Images. Aber das kommt logischerweise demnächst auch mit rein.

Der ganze Bereich des Datentransfers wird bald so oder so umgestaltet, zusammengefasst und erweitert.

An Alle, die sich fragen, warum dieser Analysepunkt neu in die Bewertung aufgenommen wurde, empfehle ich diesen Artikel zu lesen:

Google bevorzugt künftig schnelle Webseiten

Knapp zusammengefasst:
Bei Google.com hat jetzt schon bei etwa 1% der Suchanfragen die Seitengeschwindigkeit Einfluss auf das Ranking.
Subjektiv werte ich das als Testlauf.

hansen

seitenreport schrieb:

Das ist wahr - und bei diesen muss man eine Menge optimieren, um unter 6 Requests zu kommen. Aber nimm als Beispiel einmal die Seitenreport Startseite - trotz TYPO3 Enterprise CMS und vielem grafischen Schnickschnack sehr wenige Requests (momentan glaube ich 8 ) - die sogar noch weiter verringert werden könnten. Die Startseite von Google hat 6.

a) lt. yslow hat seitenreport.de 14 requests mit einem (1) css-image, das ja hier noch nicht gezählt wird.
b) Auf der Startseite von Google ist ja auch nichts drauf.

Ich will das Thema nochmal aufgreiffen, wiel ich die Zahl 4 bei den Requests (noch) nicht verstehe.

Selbst eine sehr einfache Seite hat bereits 4 Requests:

1. Die Seite selbst
2. Ein Logo
3. Die CSS
4. Das FavIcon

Wenn ich nun noch ein Bild für jede Seite einrechne sind es 5.

Und das sind schon zuviele ?

Ok - man könnte das Logo auch nur mit Text machen, aber das würde schon etwas "Altbacken" aussehen.

Auch könnte mann, wenn es nicht zu umfangreich ist, die CSS-Definitionen wieder mit in die Seite nehmen, und diese per gzip ausliefern. Macht aber auch keinen Sinn.

Daher meine Frage: Warum asind usgerechnet 4 Requests noch sehr gut ?

Gruß Matthias

Hi,
meiner Meinung nach fliest die Bewertung der Requests zu stark in die Bewertung ein. Letzlich soll doch die Ladezeit der Seite bewertet werden, oder?
Da spielt doch sicherlich auch die Hardware auf dem die Site läuft eine Rolle. Kann mir vorstellen, dass eine Seite mit 20 Requests von einem schnellen dedizierten Server schneller lädt, als eine mit 5 von einem Massenhoster.
Mein Server erreicht je nach Last zwischen 80 und 150 KB/s. Ein Server eines meiner Kunden nur 20 KB/s. Von welcher Maschine wird die Seite wohl schneller ankommen?
Wenn ich das bei Google richtig beobachtet habe, ist bei PageSpeed lediglich das Endergebnis, also die effektive Ladezeit DAS Kriteriumm, nicht wie es erreicht wird.
Es ist also durchaus auch mit "Hubraum, statt Spoiler" möglich ein gutes Ergebnis zu erziehlen.
Vielleicht sollte man deshalb lediglich die effektive Ladezeit der Seite bewerten und nicht wie es erreicht wurde. Als wertfreier Hinweis auf mögliche noch vorhandene Optimierungsmöglichkeiten sind diese "fein granulierten" Analysen der einzelnen Requests sicherlich troztdem zu gebrauchen.

Solange die Webmaster-Tools behaupten meine Seite sei zu 96% schneller als vergleichbare andere Seiten, ist es mir jedenfalls relativ egal, ob ich alleinig durch die Bewertung meiner 18 Requests auf der Seite, 10% in der Seitenreport-Bewertung verloren habe.

Der Wert in den Webmaster-Tools scheint sich auch (mit aktivierter Google-Toolbar?) beeinflussen zu lassen. Jeden falls habe ich ein paar Tage an einer winzigen php-Datei gewerkelt. Diese Datei brachte durch meine ständigen Aufrufe mein Ergebnis auf "99% schneller als..." ! Da die Datei nirgends auf der Site verwendet wird, stammen alle Aufrufe der Selben von mir und sie wurde in den Webmastertools unter den Beispielseiten aufgelistet.
Nach dem ich eine Woche an einer anderen größeren Datei gearbeitet habe ging der Wert auf die oben genannte 96% zurück. Auch diese Datei wurde dann in den Beispielseiten gelistet. Kann das jemand bestätigen? Ich werd das bei Gelegenheit noch mal mit einem automatischen Script testen. Ständige Aufrufe einer kleinen, schnellen (leeren) Seite sollten das bestätigen können, wenn es wirklich so sein sollte. Peitscht mich nicht aus, wenn es nicht so sein sollte und das bei mir Zufall war.

LG
Andreas