Google Pagespeed

[piratos]

Das Fehlverhalten betraf bereits vorkomprimierte Dateien und nicht die Fähigkeit von Chrome und Safari normale vom Server vorgenommene GZIP verarbeiten zu können - das konnten die schon immer sauber - das ist korrekt.

Headers wurden immer korrekt gesendet - alle anderen seinerzeit aktuellen Browser haben das prima verarbeitet.

Die damalige Versionen konnten die vorkomprimierte GZIP Datei nicht vollständig und sauber entpacken, sie hängten sich schlicht auf und nichts passierte mehr.

Die aktuelle Chromeversion jedoch kann es ohne jegliche Änderungen am Web selbst.

Damals war Safari Windows und Mac ebenfalls davon betroffen , die gleiches Verhalten zeigten (was auch diverse User berichteten). Man müsste mal checken ob die aktuelle Safari-Version sich dahingehend geändert haben.

[TobiaZ]

Wo sollte für den Klient der Unterschied zwischen einer "vorkomprimierten" und einer "vom Server komprimierten" Datei liegen?

[piratos]

Wo sollte für den Klient der Unterschied zwischen einer "vorkomprimierten" und einer "vom Server komprimierten" Datei liegen?

Für den Klient ? Da sollte es keinen Unterschied geben.

Auch wenn die Altversionen von Chrome und Safari(neuere müsste ich noch checken) damit nicht arbeiten können , gibt es keine Probleme beim IE (auch ältere Versionen), beim FF , Konquerer und noch ein paar, selbst integrierte Browser von Programmierungebungen verarbeiten das einwandfrei.

Warum Alt Chrome damit nicht funktionierte - das ist nicht meine Aufgabe Bugs in Fremdsoftware zu ermitteln. Es ist immer ein einwandfreier Bug wenn alle anderen Browser damit sauber arbeiten können und eben der eine oder andere nicht.

Bei vorkomprimierten erspart sich der Server lediglich die Arbeit eine Komprimierung vornehmen zu müssen und damit wird die Sache fixer und belastet den Server nicht weiter - das macht sich bei reichlich Besuchern ziemlich bemerkbar.

[TobiaZ]

Für den Klient ? Da sollte es keinen Unterschied geben.

Dann kann ich auch nicht nachvollziehen, warum die einen auf den alten Klients funktionieren sollen und die anderen nicht.

[fireweasel]

Das Fehlverhalten betraf bereits vorkomprimierte Dateien und nicht die Fähigkeit von Chrome und Safari normale vom Server vorgenommene GZIP verarbeiten zu können - das konnten die schon immer sauber - das ist korrekt.

Headers wurden immer korrekt gesendet - alle anderen seinerzeit aktuellen Browser haben das prima verarbeitet.

Wenn ich mich recht erinnere, ist das so, dass einige falsch konfigurierte Server oder serverseitige Scripts eben nicht sauber funktionierten und entweder die Request-Header des Clients nicht korrekt auswerteten oder die Response-Body-Daten in einem anderen Kompressionsformat schickten, als sie im Transfer-Encoding-Header angaben.

Wenn das vom Server benutzte Kompressions-Format "GZIP" ist, muss das der Client auch in seinem "Accept-Encoding"-Headern erlaubt haben. Üblich (weil im HTTP-Standard irgendwo definiert) ist das ZLIB-Deflate-Verfahren und nicht "GZIP". Die meisten Webbrowser sind aber so tolerant, einen falschen Response-Header zu ignorieren und "detektieren" das tatsächlich verwendete Kompressionsverfahren direkt aus den ersten "Magic-Bytes" im Body.

Lange Rede, kurzer Sinn: Ein Client (oder Browser), der "falsch" komprimierte Daten nicht entpackt verhält sich korrekt (a.k.a. strikt "standardkonform"). Ein Browser, der versucht, das tatsächlich verwendete Kompressionsformat zu erkennen, verhält sich dagegen tolerant (benutzerfreundlich), aber nicht korrekt.

Die damalige Versionen konnten die vorkomprimierte GZIP Datei nicht vollständig und sauber entpacken, sie hängten sich schlicht auf und nichts passierte mehr.

Aufhängen ist auch keine Lösung ...
... und natürlich auch kein korrektes Verhalten.

[piratos]

Ich habe eben mal den Safari 4.0.4 Windows getestet - der verarbeitet nun den damaligen Test ebenfalls einwandfrei.

Warte noch auf Rückmeldungen von Mac - Usern.

Für Pagespeed & Co. ist das allerdings absolut unwichtig.

Man muss eigentlich auch nicht weiter darüber diskutieren, denn Tatsache ist, das alle anderen Browser sofort damit klar gekommen sind, d.h. alles war korrekt in den Einstellungen, ansonsten hätten die wohl auch die Arbeit verweigert.

Wichtig ist das ein Webmaster umdenkt und sich überhaupt einmal mit den Möglichkeiten beschäftigt. Die Auswirkungen sind ja nicht nur messbar sondern auch klar zu sehen.

[onemorenerd]

Warte noch auf Rückmeldungen von Mac - Usern.

Ich bin Mac-User und ich schrieb ja bereits, dass es funktioniert.

Man muss eigentlich auch nicht weiter darüber diskutieren, denn Tatsache ist, das alle anderen Browser sofort damit klar gekommen sind, d.h. alles war korrekt in den Einstellungen, ansonsten hätten die wohl auch die Arbeit verweigert.

1. Korrektheit ist doch kein Mehrheitsentscheid! Es gibt Definitionen - in diesem Fall RFCs, die festlegen was korrekt ist und was nicht.
2. Der Schluß "funktioniert in x Browsern, also muss alles korrekt sein" ist falsch. Richtig wäre: "funktioniert in x Browsern NICHT, also KANN da was nicht korrekt sein".

[piratos]

Das sehe ich anders , man kann es auch so sehen wie du würde dann aber nie zu Potte kommen:

Chrome no longer applies gzip filters to file names with gz/tgz/svgz extensions. (Issue: 8170)

und damit wären wir beim Bug.

[wahsaga]

Wir reden doch hier über HTTP - also was soll das mit „file names” ...?

[piratos]

Jede URL ist für einen Browser ein filename (was sonst) den er verarbeiten muss.
Chrome und Safari haben auf solche die gepackt sind einen Filter angewendet der dann die Sache zum crashen gebracht hat.

Was mich interessiert ist die Frage was diese Teildiskussion denn nun bezüglich Pagespeed und Yslow gebracht hat.
Ich meine nichts, da man das wegen der extrem kleinen Marktanteile von Chrome und Safari auch in den Papierkorb hätte schmeissen können.

Echte Pagespeed oder Yslow Fragen habe ich hier noch nicht gesehen, scheint ja allen klar zu sein was zu machen ist, damit wäre ich dann zufrieden.

[wahsaga]

Jede URL ist für einen Browser ein filename (was sonst) den er verarbeiten muss.

/EOD

[onemorenerd]

Es geht nicht um Safari und Chrome sondern Webkit, vielleicht sogar KHTML und damit um so ziemlich alles außer Opera, Firefox und IE. Macht einen Marktanteil von circa 10 Prozent.

Über Pagespeed/Yslow gibt es nicht viel zu zu sagen. Man hat doch schon immer versucht, Webseiten möglichst schnell auszuliefern. Jetzt gibt es Tools, die einem zeigen wo man noch optimieren kann. Das ist keine große Sache.

Es lohnt sich viel mehr, über die konkreten Optimierungsmöglichkeiten zu sprechen. Kompression ist eine davon.

Kompression kann man in gängigen Webservern einfach zuschalten. Der Server komprimiert die Daten dann on-thy-fly beim Ausliefern. Damit er das nicht jedes mal erneut machen muss, kann man statische Dateien einmalig komprimieren. Aber dann muss man den Server auch so einstellen, dass er solche Dateien nicht erneut komprimiert und vor allem die richtigen HTTP-Header sendet.
Außerdem muss man zusätzlich die unkomprimierten Dateien vorhalten, falls ein Browser keine Komprimierung unterstützt.
Wenn man im Zuge der Performanceoptimierung auch einen Caching Proxy installiert, kann man den Webserver on-thy-fly komprimieren lassen und der Caching Proxy sorgt dafür, dass das nicht immer wieder geschehen muss.

[piratos]

Man sollte sich davor hüten Browserbugs durch ständige Ausklammerung und Aktionen in seinen Scripten zu umgehen auch wenn man das könnte.
Bugs zu beseitigen ist immer eine Sache des eigentlichen Anbieters.
Es ist nicht die Aufgabe eines Webprogrammierers seine Ressourcen für diese Anbieter zu verschwenden um deren Bugs zu umgehen.

Es ist allein das Interesse des Browseranbieters mit seinem Produkt Marktanteile zu gewinnen und dann müssen die auch ran - so einfach ist es.

Man kann den am besten zu einer Korrektur zwingen wenn man das eben nicht macht und somit einen Anteil der User dieses Produktes dazu bringt zu meckern bzw. den Bug zu melden.
Kein User sieht Webkit der sieht Chrome oder Safari oder was auch immer und wird sich dann an seinen Anbieter halten.

Marktanteile werden zudem nicht nach der Verwendung von individuell geänderten Kits gemessen.

Die andere Seite der Medaille ist ständig Uraltbrowser unterstützen zu wollen nur weil die Netznutzer zu faul sind ein Update zu installieren (was auch aus Sicherheitsgründen äußerst bedenklich ist).

Auch da ist meine Meinung die - lasst diese Surfer in das Messer laufen.
Solange man darauf eingeht wird diese spezielle Gruppe nichts ändern, das machen sie erst dann wenn nichts mehr so richtig läuft.

über die konkreten Optimierungsmöglichkeiten zu sprechen. Kompression ist eine davon.

Das wäre der Ansatz - Kompression hilft ist aber bei vielen aber bei weitem nicht überall möglich, das ist das grundsätzliche Problem, wer kann sollte es machen.
(warum man hier allerdings Kompression nicht verwendet ??? )

Die nächste großartige Möglichkeit ist die einen Browsercache zu verwenden,wenn möglich .

Was jeder Webmaster machen kann ist und was sofort etwas bringt:

1. Backgroundimages in einem Sprite zusammenfassen.
2. die Regel "Use efficient CSSselectors" befolgen, das bringt richtig etwas
3. Keine CSS Elemente laden die man nicht benötigt
4. CSS vor JS laden
5. JS nach Möglichkeit in eine Datei fassen
6. JS nach Möglichkeit vor </body> laden und nicht im Meta - Teil
7. Alle Möglichkeiten prüfen um die Anzahl von HTTP Request's zu reduzieren
8. Abhängigkeiten von externen Inhaltseinbindungen auflösen, da man voll von denen abhängig wird.

Ich empfehle den FF mit Yslow und Pagespeed zu verwenden, Yslow ist die Sache für's grobe, Pagespeed für's feine.
Optimal dazu ist der DEV Teil vom Browser Chrome bei dem man an Hand der Timeline richtig gut sehen kann, wo das Rad gebremst wird.

Aber - man muss sich im klaren sein - alle Maßnahmen selbst wenn sie zu 100% Pagespeed und Yslow 100 sind liefern keine Garantie dafür das die Website Leistung laut Google Webmastertools besser als der Schnitt ist.

Sie helfen garantiert die Leistung zu verbessern, können aber die Generierungsprozesse langsamer Titel nicht ändern und sie können natürlich auch nicht lahmen Servern Flügel zu verleihen.
In der Praxis wird man allerdings eher auf lahme Generierungsprozesse stoßen als auf lahme Server.
In der Praxis werden die meisten Domains auf shared Webservern liegen, da besteht noch das Problem das man keine Ahnung hat wie der durch das Angebot und die Besucher der Nachbarn belastet werden - das kann enorm schwanken.

[onemorenerd]

Man sollte sich davor hüten Browserbugs durch ständige Ausklammerung und Aktionen in seinen Scripten zu umgehen auch wenn man das könnte.
Bugs zu beseitigen ist immer eine Sache des eigentlichen Anbieters.
Es ist nicht die Aufgabe eines Webprogrammierers seine Ressourcen für diese Anbieter zu verschwenden um deren Bugs zu umgehen.
...
Die andere Seite der Medaille ist ständig Uraltbrowser unterstützen zu wollen nur weil die Netznutzer zu faul sind ein Update zu installieren (was auch aus Sicherheitsgründen äußerst bedenklich ist).

Selbstverständlich. Jeder vernünftige Mensch teilt diese Ansicht.
Aber in der Praxis steht im Anforderungskatalog, in welchen Browsern es laufen muss. Wenn ein Entwickler auf einen Browserbug stößt, muss er einen Workaround suchen. Er kann nicht einfach die Anforderung ignorieren, um so Druck auf den Browserhersteller auszuüben.

Wenn man sein eigenes Süppchen kocht, kann man so idealistisch sein.
Aber wenn man jemandem rechenschaftspflichtig ist, hat man nach seinen Anforderungen zu arbeiten. Die kann man bestenfalls mitbestimmen, aber am Ende zählt immer Wirtschaftlichkeit vor Idealismus.

[unset]

OffTopic:

---

The Guide is definitive. Reality is frequently inaccurate.

---