Neue Analyse: HTTP Requests (Seite 3)

Auch ich finde die Bewertung alleine aufgrund der Requests für nicht sehr sinnvoll.

extremeforce schrieb:

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 trotzdem zu gebrauchen.

Es alleine anhand der Ladezeit zu Werten ist jedoch ebenfalls keine gute Lösung da diese je nach Netzlast doch zu sehr Schwankt.
Wäre es nicht sinnvoll diese Kriterien zu Kombinieren bzw. noch zu erweitern z. B. Wertung anhand einer Kombination aus Requests / Ladezeit / Traffic

Gruß Joachim

Ich frage mich immer noch, warum ausgerechnet die 4 Requests noch sehr gut sind.
Betriebsgeheimnis kann ich als Antwort nicht akzeptieren

Gruß Matthias

Hallo Andreas,

doc4pc schrieb:
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.

Ich höre aktuell an der Uni eine Vorlesung zum Thema Laufzeitanalyse von Algorithmen.
Dabei versucht man die Leistungsfähigkeit eines Algorithmus unabhängig von der Programmiersprache und des Systems zu analysieren.
Betrachtet man sich die beiden folgenden Zeilen:
a = 10;
b = (((a * 5) / 2 + 10) * 2 - 25)^10;
Man sieht auf den ersten Blick, dass die zweite Zeile wesentlich mehr Laufzeit benötigen wird, als die erste. Dennoch weißt man beiden Zeilen lediglich den gleichen konstanten Wert c zu, um eine allgemeingültige Aussage zu erhalten.

Genauso schaut es bei Webseiten aus. Zur Beurteilung der Seitenoptimierung ist die Anzahl der Requests ein viel genauerer Wert als die Ladedauer. Und darum geht es ja schließlich bei Seitenreport.
Davon abgesehen ist die Ermittlung der Ladedauer auch nicht so einfach. Man würde ja schließlich große Mengen an Testwerten benötigen, um den durchschnittlichen Wert zu erhalten.

doc4pc schrieb:
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?

Hängt von der Webseite ab.

Steve Souders schrieb:
Die Realität zeigt, dass die meisten Websites weniger als 10-20% der Endanwender-Response-Zeit damit verbringen, das HTML-Dokument vom Webserver in den Browser zu laden. Wenn Sie die Response-Zeiten Ihrer Webseiten drastisch reduzieren wollen, müssen Sie sich auf die anderen 80-90% der Zeit des Endanwenders konzentrieren.

UFOMelkor schrieb:

Davon abgesehen ist die Ermittlung der Ladedauer auch nicht so einfach. Man würde ja schließlich große Mengen an Testwerten benötigen, um den durchschnittlichen Wert zu erhalten.

Und je nachdem wie das Internetzwerk gerade unter Last steht, würden diese Werte auch nochmal (enorm?) schwanken.

Gruß Matthias

UFOMelkor schrieb:

Davon abgesehen ist die Ermittlung der Ladedauer auch nicht so einfach. Man würde ja schließlich große Mengen an Testwerten benötigen, um den durchschnittlichen Wert zu erhalten.

aber gerade das würde für mich als statistik fan sinn machen ..... ich will doch nicht wissen wieviele request ich habe sondern was beim endkunden (besucher) ankommt, dass es hier up & downs gibt is doch klar und auch da will ich wissen was das max bzw. min ist
...ich sehe die request ehrlich gesagt nur als mittel zum zweck. wenn ich hohen ladedauern habe und meine seite überladen ist, dann suche ich nach möglichkeiten den datenfluss zu erhöhen und da gibt es auch andere möglichkeiten als nur die http-request zu senken.
Faszit: jemehr analysen gemacht werden um so genauer der standartwert der ladezeit , finde ich immer noch ne gute idee (ähnlich wie bei ibp)

Es geht hier aber nicht um Statistik, sondern um Seitenoptimierung. Eine Seite mit 5 Requests ist (mit hoher Wahrscheinlichkeit) optimierter als eine Seite mit 50 Requests. Für Statistiken ist Seitenreport nicht zuständig bzw. es sollte dafür nicht zuständig sein.

Davon abgesehen weißt du nicht, wie schnell ein Client die Seite zusamensetzt. Du hast also immer nur eine theoretische, nichts aussagende Geschwindigkeitsmessung.

Um es nochmal deutlich zu machen: Meiner Meinung geht es bei Seitenreport nicht um die Bewertung einer Webseite, sondern um die Bewertung des Optimierungsgrades einer Webseite.

Hallo

Die Analyse wird meiner Ansicht nach immer trickreicher.

Sie entwickelt sich immer weiter in dem Sinne wenn man an einer Stelle Punkte gut macht kann es sein das es sich an anderer Stelle negativ auswirkt.

Das beste Beispiel ist dafür das CSS auszulagern. Sicher gibt das einen Request mehr aber die Vorteile auf der anderen Seite überwiegen.

Sobald die Analyse Punkte wie Gestaltung der Webseite aufweist und die Anzahl der Bilder halt eben noch berücksichtigt werden, wird es geschehen das sich halt eben die Anzahl der Request die man jetzt mehr hat wieder in anderer Hinsicht positv auswirken.

Dann ist halt eben auch noch die Frage wann Punkte wie Cache Handling in die Analyse einfliessen werden.

Wenn Seitenreport sich so weiterentwickelt wird es noch trickreicher und komplexer werden.

Man muss halt eben dann abwägen ob man mehrere Request mehr lieber hat zugunsten anderer Vorzüge.

Man muss sich halt eben entscheiden ob man einen Teufel in einer Hinsicht mit dem Belzebub in einem anderem Punkt austreiben will.

Bedeutet dann übersetzt werde ich die Optimierung in diesem Fall vornehmen um unter Umständen wieder an anderer Stelle einen niedrigeren Optimierungsgrad zu bekommen.

Komplex , Trickreich, Genial kann man die Umsetzung nur noch bezeichnen.

Was ich momentan vermisse werde ist der Bezug zwischen den einzelnen Analysepunkten.

Für Anfänger in dieser Hinsicht werden sich die Zusammenhänge nicht so leicht ergeben.

Mein Vorschlag wäre jetzt dazu eine Liste zu entwickeln in der Art .

Mehr requests negativ dafür sind aber externes Css , Faviicon, usw. wieder positiv zu bewerten.

Also Quasi eine Pro Kontra Liste.

Okay jetzt warte ich einfach mal auf den Zeitpunkt wenn sowas wie die Anzahl der name Server in die Analyse einfliesst und auf den Aufschrei da in der Regel es nur 2 gibt wenn man das auch noch negativ bewertet.

Gruß
Jörg

UFOMelkor schrieb:

Um es nochmal deutlich zu machen: Meiner Meinung geht es bei Seitenreport nicht um die Bewertung einer Webseite, sondern um die Bewertung des Optimierungsgrades einer Webseite.

Das trifft den Nagel auf den Kopf.

@All: Mit 4 Request\'s ist es möglich eine Webseite zu erstellen.
HTML + CSS + Favicon + Joker(Bild, Logo, Java oder Flash)
Daher ist 4 als Standard = sehr gut anzusehen.

Nicht jeder wird es schaffen hier die 100% zu bekommen, aber haben wir das auch bei den Zugriffszahlen? Eher nicht.

So wie Jörg es schreibt, ist es auch. Es ist so, dass es ein ausgwogenes Verhältnis zwischen den einzelnen Punkten gibt. Es ist schon möglich ein Favicon zu opfern, um ein 2tes Bild einzubauen.

Muss aber nicht sein? Es ist auch möglich mit einem SourceCode ein Bild darzustellen, was bedeutet, dass es nicht extern geladen werden muss oder 1 Bild für die gesamte Webseite zu verwenden (demnach kein Request). Früher wurden Bilder getrennt, weil es mit 14K-Modems Stunden gedauert hätte, bis eine Seite geladen wurde. Heute gibt es schnelle Verbindungen. Gegen 1 Gesamtbild spricht evtl. aber wieder die "Größe der Bilder" auf einer Webseite.

Seitenreport ist es wichtig, die Balance der einzelnen Kriterien zu verstehen und diese ggf. umzusetzen.

In diesem Zusammenhang: hat jemand von euch Erfahrungen mit CSS-Sprites?
Das ist laut einiger Artikel das Mittel der Wahl, um Requests zu reduzieren.
Ich selbst wende es nur indirekt per Extension (bookmarks) an. Da funktioniert es prima.
@Heiko: oder meintest du das mit Joker?

Hallo Lutz,

ich habe mal Sprites genutzt. - Zunächst hatte ich die aber Einbildung ich könnte alle Template-Bilder damit auf eines reduzieren... - dann sahen die repeats etwas seltsam aus... kann auch an mir liegen...

Vielleicht sollte man es nicht übertreiben.

Viele Grüße,

Gabriel