Google Pagespeed

[TobiaZ]

Also ich habe das Thema (ansich und diesen Thread) noch nicht verfolgt. Aber deine Liste zeigt ausnahmslos nur Steigerungen der Werte. (Warum hast du die anderen Seiten nicht mehr mit gelistet?)

Liegt es da nicht nahe zu vermuten, dass gar nicht so massiv optimiert wurde, sondern vielmehr eine Veränderung der Bewertung stattgefunden hat. Jedenfalls würde ich das noch lange nicht als einen Beweis sehen, dass fast alle etwas unternommen haben.

[onemorenerd]

Man nehme gzip und packe eine Datei und verwende diese Datei in einem Web , aus fertig ganz einfach.

Warum Safari und Chrome das nicht können, das andere aber doch interessiert mich nicht die Bohne, ist nicht mein Job deren Bugs zu beheben.

Aber Sie können es definitiv nicht , das muss man nur wissen und umgehen.

Falsch! Beide Browser, Safari und Chrome senden "Accept-Encoding: gzip,deflate" in der Anfrage und zwar nicht zum Spass. Sie können wirklich damit umgehen.

Du sendest ihnen nur nicht die richtige Antwort. Eine .css.gz musst du mit "Content-Type: text/css" und "Content-Encoding: gzip" ausliefern. Du überläßt es aber wahrscheinlich dem Server, die Header zu setzen. Der schaut sich nur die Dateiendung .gz an und sendet "Content-Type: application/x-gzip". Webkrit reagiert darauf völlig korrekt. Kein Bug.

[TobiaZ]

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

[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.

[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".

[wahsaga]

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

[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.

[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.

---

[unset]

Solche verschachtelten Selektoren findet man eigentlich überall

Weswegen es ja auch cascading style sheet heißt. Und das was du da beschreibst ist alles andere als Effizient: Du beschränkst die Klassen nicht auf bestimmte Elemente, der Rederer muss jede prüfen –*und lesbarer ist das nun wirklich nicht. Ich behaupte, oberes CSS ist wesentlich schneller, besser zu lesen –*und einfach richtig!

[wahsaga]

Und wenn man z.B. mal ein Menü umgesetzt hat sieht man es auch deutlich und sofort.

Die Frage ist - wo sieht man das?

Als Besucher der Seite? Bei einer durchschnittlichen Seite bezweifle ich das eher.

Oder in irgendeinem der Tools, die Effizienz „messen”? Das ist fein, aber eigentlich total egal, wenn's der Besucher nicht wirklich mitbekommt.

[unset]

Ich merke davon –*ohne zu messen –*nichts. Und wenn ich mit bloßem Auge nichts erkennen kann, dann ist es auch irrelevant. Halte ich darüber hinaus für Micro-Optimierung, und die hat sich –*was Webentwicklung angeht –*noch nie ausgezahlt.

Edit: wahsaga war schneller.

Edit2: Statt "altbacken" und "Problemchen" solltest du lieber mal "Anforderungen" in Anführungszeichen setzen. Denn wer fordert das ganze eigentlich? Google? Yahoo? Der liebe Gott? Du? Und ja, ich habe keinen Bock mich für so einen Hokuspokus durch den ganzen Thread zu ackern!

[TobiaZ]

Sehe ich auch so. Ist einfach ein Unterschied zwischen dem was möglich ist und dem was für die Praxis relevant ist.

Wer zeit zum Spielen hat, naja soll er halt tun, das Wetter ist ja heut sowieos nicht so toll.