Google Pagespeed

[onemorenerd]

Schwer lesbar finde ich eher das reduzierte CSS und das nicht nur wegen der fehlenden Whitespaces.

Das Beispiel zeigt zwar schön, was gemeint ist und wie sich der Datenumfang reduziert. Aber was der Laie nicht sieht und was man deshalb mal erwähnen sollte: Die Semantik des reduzierten CSS unterscheidet sich signifikant! Das ursprüngliche CSS läßt sich nur auf DOM-Elemente in einer vorgegebenen Struktur anwenden.

Als Beispiel nehme ich mal den Selektor "ul.menu li ul li a". Der kann nur auf A-Tags angewendet werden, die Kind eines LI sind, das wiederum Kind einer UL ist, die Kind eines LI ist, die Kind einer UL mit der Klasse menu ist.
Im Vergleich dazu passt der Selektor ".menu-li-ul-li a" zu allen As, die Kind eines beliebigen Elements mit der Klasse menu-li-ul-li sind.

Mit derart reduziertem CSS ist es also möglich, Auszeichnungen für Elemente zu verwenden, für die sie nicht gedacht sind. Nicht nur möglich, sondern sogar naheliegend, würde doch das hinzufügen einer weiteren Deklaration mit der selben Wirkung das CSS unnötig aufblähen.
Der Programmierer wird sozusagen dazu verleitet, Deklarationen in Stellen zu verwenden, für die sie nicht gedacht waren. Weils halt grad passt.
Dumm nur, wenn später das Design von Links in verschachtelten Listen geändert werden soll. Man kann nicht dafür garantieren, dass sich dadurch nicht auch Links an anderer Stelle ändern.
Derlei reduziertes CSS zwingt also alle Entwickler, sich an die Konvention zu halten, CSS-Auszeichnungen nur auf Elemente anzuwenden, die man am Selektor ablesen kann. Bei nicht-reduziertem CSS wird das durch den Selektor selbst sichergestellt.

Kurzum: Diese Reduzierung beschneidet CSS um eines seiner Features, ist deswegen semantisch schwächer und zwingt zu bestimmten Konventionen.
Jeder muss selbst entscheiden, ob der Performancegewinn die Sache wert ist.


Übrigens hätte ich als Beispiel leiber den Selektor ".menu-li-ul-li" genommen, doch der hat gar keine Entsprechung im Original-CSS.

[onemorenerd]

Was für Patente sollen das sein? Imho ist das keine schützbare Idee, denn die CSS-Spezifikation gibt es eben her. Dass es weniger zu übertragende Daten bedeutet, ist nur ein Effekt der Idee und dass es in gängigen Browsern schneller gerendert wird, kann sich wenn überhaupt nur ein Browserhersteller patentieren lassen (genauer gesagt die Art, wie er das schafft). Hast du Links zu den Patenten?

Übrigens rendern Browser solch "flaches" CSS schneller, weil sie einerseits den CSS-Selektorenbaum schneller aufbauen können (klar, der ist eben flacher), weil es sich in einem flachen Baum schneller suchen lässt und der Suchvorgang ohne tiefe Prüfungen im DOM-Baum auskommt.

Wenn man diesen Gedanken weiter denkt, sollte man CSS-Deklarationen, die nur einmal verwendet werden, direkt inline am Element notieren. Außerdem sollte man den DOM-Baum ebenfalls so flach wie möglich halten.
Wendet man dieses Sparsamkeitsprinzip auch auf JS an, stellt sich schnell die Frage, ob man überhaupt Frameworks verwenden sollte bzw. ab wann das sinnvoller ist als rein handgeklöppelter Code.

Alles in allem sind die Optimierungsansätze, die sich direkt auf die Struktur des Codes und/oder die Arbeitsweise und Flexibilität beim Programmieren auswirken immer mit Vorsicht zu genießen. Ich würde bei Applikationen und Teams ab einer gewissen Größe und Komplexität lieber auf solche Optimierungen verzichten und den Leistungsschub durch Hardware und Setup holen (CDN, Load Balancer, Caches, ...). Wenn eine Applikation bis zum Gehtnichtmehr auf Speed getrimmt ist, kann man an ihr meist kaum mehr vernünftig arbeiten.

Als Beispiel sei hier noch einmal die CSS-Optimierung angeführt. Ich kenne keine Tools, die CSS und das zugehörige HTML derart umstricken können. Gäbe es so ein Tool, könnte man es in den Build-Prozess integrieren. Die Entwickler könnten "sauber" arbeiten und die Seite wäre trotzdem flott.
Ohne solch ein Tool wird entweder die Arbeit zur Qual oder man geht vorm Deployment per Hand drüber. Beides kostet Zeit und damit Geld, das man ab einer gewissen Projektgröße auch gleich für Hardware ausgeben kann.

Alles hat ein Pro und Kontra. Wer einfach nur macht was ein Tool rät, denkt zu kurz. Es gilt nicht nur Transfer- und Renderzeiten zu verkürzen, sondern das kosteneffizient zu machen.


Nachtrag: Imo wird mit diesem Pagespeed-Hype gerade mal wieder eine Sau durchs Dorf getrieben. Google mit seinen weltweit verteilten Datacenters und viel eigener Infrastruktur ist schneller als alle anderen. Von diesem hohen Ross herab möchten sie nun "das Web schneller machen". For what? Why now?
Sind die eigentlich an User Experience interessiert oder wollen sie nur den Googlebot entlasten?
</polemik>

[unset]

Ich würde bei Applikationen und Teams ab einer gewissen Größe und Komplexität lieber auf solche Optimierungen verzichten und den Leistungsschub durch Hardware und Setup holen (CDN, Load Balancer, Caches, ...).

Genau so ist es. Ich hab es schon mehrfach gesagt und ich kann es nur immer Wiederholen: RAM kostet weniger als ein Entwickler. Das passt hier jetzt nicht wie Arsch auf Eimer, aber die Grundaussage bleibt die gleiche. Code muss wartbar sein, dann kommt erst mal lange nix.

[onemorenerd]

Dass man mit Serverhardware die Zeit fürs Rendering nicht beeinflussen kann, ist wohl jedem hier klar. Sehr wohl aber kann man die Zeit vom Abschicken des Requests bis zur fertig gerenderten Seite verringern, indem man mit Hardware und Setup die Zeitspanne minimiert, die serverseitig verbraten wird oder die Anzahl der Requests, die tatsächlich bis zum Server durchschlagen.

Ich hab schon verstanden, dass du gerade nur über die Zeit zum Rendern sprechen willst. Aber warum sollen wir uns darauf beschränken? Deine Tools messen doch auch nicht nur die Zeit vom letzten empfangenen Byte bis zum DocumentReady. Deren Uhr beginnt zu ticken, wenn der Request raus geht.

Meinetwegen kannst du weiter über Einzelheiten sprechen. Hat aber nicht viel Sinn, solange keiner mitredet.