Bei Amazon bedeutete eine nur um 100 Millisekunden langsamere Ladezeit einem Umsatzrückgang von einem Prozent.."

Ja das sind Dinge die nicht nur von Amazon gemessen und gesehen werden, da gibt es auch jede Menge Anwender in DE die äußersten Wert darauf legen. Nicht umsonst habe ich da noch eine Enterprise Version nebst eigener Templateengine in petto, die im Schnitt  4 x schneller ist als die Standardversion und auch da bin ich gerade für jemand  fertig geworden, die überaus schnelle und flexible Tree Darstellung auf Basis nested Set auf stored Procedures umzustellen, die pro Aktion 300% schneller ist, aber dennoch pro Aktion nur 2 Millisekunden Vorteil bringt.

Gerechnet wird dann aber durchschnittliche Anzahl von Aktionen pro Besucher mal Anzahl von Besuchern/Stunde = Gesamtzeit und dann werden aus Millisekunden pro Aktion wahre Elefanten.

Das aber ist dann auf der Programmseite gemacht - richtige Elefantenherden kann man mit Pagespeedtechniken vertreiben und das kann grundsätzlich jeder, wenn er denn kann und nicht jede Maßnahme die im Netz schon längst x mal widergekaut wurde erneut bewiesen haben muss.

Ein einfaches "ich hab keine Testcases" hätte vollkommen gereicht.

ich hab euren Thread jetzt nicht komplett verfolgt... aber in der aktuellen CT ist ein Bericht über WPO, da gibt das zwar keine Testcases, aber paar Studien zu dem Thema wie sich langsame Ladezeiten auf den Umsatz auswirken 

http://www.stevesouders.com/blog/2010/0 … imization/

aus der CT "Bei Amazon bedeutete eine nur um 100 Millisekunden langsamere Ladezeit einem Umsatzrückgang von einem Prozent.."
"... Google betont immer wieder die Relevanz der Performance einer Website für das Ranking in den Suchergebnissen: Wer Lahmt wird zurückgestuft."

In einem anderen Zusammenhang hab ich gelesen, vereinfacht ausgedrückt, das es bei modernen Desktop Rechnern mit Mehrkernprozessoren es für den Aufbau einer Website günstiger ist, den Rechner rechnen zu lassen, als Daten zu übertragen. Das ging z.B um die Verwendung von CSSSprites, hauptsächlich.  Wie das jetzt mit Smartphones Pads und andern Rechnern aussieht wurde nicht behandelt..

Gruß aus HH

Mein Denkfehler, ich nahm an, dass zu einer Diskussion immer mindestens 2 gehören.

Das ist richtig und kein Denkfehler - aber jemand wie du der im Detail nichts davon versteht , der ist dann fehl am Platze.

Bei diesen Thema gibt es kein Einzelunterricht  und Nachhilfe.

Also wer nichts davon versteht (und das offenbar bei den gegebenen Beispielen auch nicht )

Welche Beispiele? Ich seh hier immer nur Deine These (als Fakt verkauft), und Links zu irgendwelchen Pagespeed-services, die (jeweils) genau 1 Beispiel mit sich selbst beweisen sollen.

Ein "X" ist besser "Y" lässt sich durch ein Pagespeedergebnis für "X" nicht belegen. Welchen Teil davon hast du nicht verstanden?

Mein Denkfehler, ich nahm an, dass zu einer Diskussion immer mindestens 2 gehören.

Ein einfaches "ich hab keine Testcases" hätte vollkommen gereicht.

Quatsch  - wer zu faul ist sich bei Google mit dem kleinen Wort Pagespeed zu suchen und sich zu bemühen, der wird nie das Thema verstehen. Man hat da allein bei Google.de fast 7 Mio Treffer und gleich an erster Stelle die maßgebenden Fundstellen bei Google selbst.

Ich werde garantiert nicht jahrelange Erfahrung bis ins Detail breit treten  in einem Thema das Kenntnisse voraus setzt.

Auch weil diese Erfahrungen zig tausende andere Leute  bereits ebenfalls gesammelt haben und darüber berichten.
Das ist ein derart verbreitetes Thema, das es für einen Webdesigner bereits eine Lücke darstellt, wenn man davon so wenig weiß.

Wenn also unzählige Leute darüber berichten wirst du es ja wohl auch mal schaffen, "deinen Hintern" aus Eigenleistung bewegen zu können, statt alles nur vorgekaut verarbeiten zu wollen.

Also wer nichts davon versteht (und das offenbar bei den gegebenen Beispielen auch nicht )  und noch nicht mal das Thema selbst  sollte sich bei Themen beteiligen von denen er etwas versteht oder sich da mal etwas aneignen - so einfach ist ist.

Oh doch, der verbreitet diese sogar per Download in seinen Projekten.

Pack doch mal paar auf'n Tisch.

Beschäftige dich mit Pagespeed, lerne was dahinter steckt, schau dir Webseiten an, check die mit Pagespeed, schau dir die Ressourcen der Site an  und auch Seiten von denen du weisst mit welchen Werkzeugen sie gemacht sind - zum Thema gibt es Quellen ohne Ende.
Am einfachsten fängt man damit an sich die Regeln durchzulesen und zu fragen warum die so wirken, statt jeden Kleinkram "nachgewiesen" zu bekommen.
Die Entwickler von Pagespeed und Yslow wissen nicht nur wovon sie reden, sie versuchen genau mit den Regeln die aktuellen Browser- und Internettechniken optimal zu nutzen.

Die hier angesprochenen Dinge sind alle nachvollziehbar, aber es ist mehr ein Thema unter Leuten die wissen um was es geht und kein Lehrstück.

Und das Thema lautet hier in der Zusammenfassung Codeperformance geil, erlebte Performance Mist und genau da spielen natürlich u.A. Auswirkungen a la Pagespeed eine dicke Rolle.

Also wer sich mit Pagespeed auskennt und sich diverse Seiten im Netz mal unter die Lupe nimmt und sich dazu die Network Dinge anschaut der hat Testcases ohne Ende.

Pack doch mal paar auf'n Tisch. Ich hör von Dir immer nur; "das und das is der Weisheit letzter Schluss", nachprüfen kann niemand wie Du das herausgefunden haben möchtest.

Viel schöne Theorie, aber keine Testcases. Ach so, ist ja Stammtisch.

Also wer sich mit Pagespeed auskennt und sich diverse Seiten im Netz mal unter die Lupe nimmt und sich dazu die Network Dinge anschaut der hat Testcases ohne Ende.

Kennt jemand dazu noch das Werkzeug mit dem eine Site erstellt wurde dann werden bei ihm bei einigen Punkten ganz schnell die Alarmglocken bimmeln.

Ein Werkzeug. Keine Lösung.

Jedes System ist ein Werkzeug und keine Lösung, aber ein Werkzeug, welches nicht das Zeug zum werkeln anbietet, bietet auch keinen Lösungsansatz.

Das Thema ist ja viel allgemeiner auch wenn man in dem Zusammenhang ein paar Beispiele nennt die man nachvollziehen kann, weil man das Werkzeug kennt.
Greifen wir doch nochmals die Suche auf.

Was den Code der Suche bei CMSMS betrifft, der ist absolut performant und erledigt das was es aus der Sicht des Coders machen soll ratz fatz.
Wenn es hier z.B. heute auch mehrere Sekunden dauert, dann schiebe ich das mal auf die Umstellungsarbeiten neuer Server.

Die erlebte Performance ist jedoch eine ganz andere, da man keinerlei Kontext in den Ergebnissen sehen kann. Man bekommt lediglich den Link angezeigt, in welchem näheren Zusammenhang meine  Suchanfrage zur Trefferstelle steht ist nicht erkennbar.

Hat man nun eine große Trefferliste ohne Kontext, dann wird man sich verschiedene Seiten ansehen, bis man meint das wäre die Antwort die man sucht.

Tritt das ein ist die erlebte Performance Null.

Nun soll es ja so sein, das möglichst viele Besucher eine Site anlaufen sollen und ein Teil wird dann sicherlich auch suchen.
Hat man nun den Fall das Besucher ihre Suche wiederholen müssen, weil sie die Trefferliste mangels Kontext nacheinander aufmachen, dann hat man irgendwann einen realen allgemeinen  Performanceeinbruch und zwar auch für die Besucher die überhaupt nichts suchen.

Hätte man nun eine Instantsuche a la Google (oder auch eine normale mit Kontextausgabe) , dann sind in der Praxis Suchanfragen bereits nach wenigen Tastenanschlägen erledigt, der Suchende erkennt da schon aus dem Kontext heraus ob und was interessant sein könnte.

Die erlebte Performance ist eine ganz andere. Und so nebenbei entlastet es die Server von Google enorm, auch wenn Ahnungslose das genaue Gegenteil davon sehen.
Genau den Vorteil den Google da hat - und der ist gewaltig  - kann ich in meinen Projekten ebenfalls bestätigen.

Also die Suche bei CMSMS ist nur ein Beispiel dafür das ein Coder sagt und zwar zu Recht - geile Performance, wobei die erlebte eine ganz andere ist.

Man muss auch nicht wie es manche wohl nicht anders können über jede Hintergrundgrafik reden, die nackte Zeitperformance lässt sich bei jeder Webseite sofort messen.
Die erlebte Performance enthält ja  nur Zeit , es gibt aber auch das Thema Erwartungserfüllung des Besuchers.

Also es gibt immer jede Menge Dinge die man so sehen kann und kommen wir mal auf die Sternchen Sache zurück - da war es ganz klar eine performante Lösung aus der Sicht des Coders die kurz und knapp genau das gemacht hätte was gefragt wurde, nur der Besucher einer solchen Seite hätte das völlig anders empfunden und man hätte das im Gesamtresultat dick sehen können.

Wenn ich da diesen Hotellink angebe, dann nicht weil ich die Site gemacht habe,denn die hat der Betreiber selbst erstellt, sondern weil da so schön viele Elemente in den Seiten (das sind insgesamt ca. 6000 Seiten)  enthalten sind, die was Gesamtperformance betrifft in der Masse kritisch wirken, also ein schönes Beispielobjekt für diese Dinge ist.

Nun wenn ein Coder ein komplette Module beilegt und vorschreibt wie man es einsetzen soll, hat ein Webdesigner nur wenig Möglichkeiten da etwas dran zu drehen, wenn die Datenstruktur es nicht her gibt, die ein Module erzeugt.

Da stimme ich zu. Wenn diverse Schnittstellen zum Gestalten performanter Webseiten fehlen, kann sich der Webdesigner 'nen Wolf designen.

Aber gerade bei Systemen wie CMSms (oder von mir aus auch PCMS) liegt doch die Stärke darin, das System mit wenig Aufwand um beliebig viele Funktionen erweitern zu können. Ein Plugin wie z.B. Supersizer von Jeremy Bass oder ein Modul wie CGSmartImage bietet alles, was man als Webdesigner braucht, um Bilder performant und dennoch anspruchsvoll darstellen zu können. (Wobei ein Modul hier mit Kanonen auf Spatzen geschossen wäre, aber egal.) Selbst ich habe ein simples Plugin erstellt, mit dem man je nach Browser base64-Bilder anzeigen lassen kann - und ich sehe mich selbst nicht als Coder. Wie ich schon in einem anderen Thema sagte: Bilder an sich sind hier das geringere Problem.

Wichtiger wird es bei den anderen Punkten die Du ansprichst (obwohl ich persönlich - als web-affiner Mensch und viel im Web unterwegs - eine Instant-Suche, wie insbesondere Google sie anbietet, wie die Pest HASSE! Es gibt nichts irritierenderes als einen Bildschirm, der seinen Inhalt bei jedem verfluchten Tastendruck ändert! Und vor allem will ich nicht, dass jeder verfluchte Tastendruck sofort irgendwohin geschickt, ausgewertet und an mich zurück geschickt wird! Die Suche beginnt, wenn ICH mit meiner Anfrage FERTIG bin und verflucht nochmal der Maschine SAGE, dass die JETZT suchen soll! Diese verfluchte Dauerkommunikation geht mir echt auf den Sack und wird nach meiner Erfahrung enorm überbewertet! Ich bin Herr der Maschine und ich bestimme, wann was kommuniziert wird!

Aber das ist eine andere Geschichte.
Prinzipiell stimme ich zu, dass ein Coder an derartige Schnittstellen denken muss.
In welcher Form auch immer. Hauptsache sie sind da. Und da muss auch ich zugeben, dass bei CMSms hier und da Verbesserungsbedarf besteht. Denn nichts ist so gut, als dass man es nicht noch besser machen könnte. Aber wie sagt man so schön: Ein guter Handwerker gibt nicht seinen Werkzeugen die Schuld Wenn CMSms etwas von Haus aus nicht kann, dann muss man selbst eben dafür sorgen, dass es das kann
Und das ist zum Glück kaum eine Hürde.
Das ist CMSms zumindest für mich: Ein Werkzeug. Keine Lösung.