Bewertungssternchen - Performanceansichten

piratos · 14. September 2011 10:55

Es gab da gestern eine kleine Diskussion in einem anderen Forum wie man mittels Smarty Bewertungssternchen (1..10) ausgibt.

Der Vorschlag von zwei Personen lautete pro Sternchen in einer Smarty Schleife ein Image auszugeben.

Ich wies darauf hin das man aus Performancegründen lieber es so steuern sollte, das man 10 Images anlegen sollte die 1..10 Sternchen enthielten und dann eine Einbindung über den Wert (z.B. 8.jpg) vornehmen sollte.

Ein absoluter Smarty - Kenner meinte darauf hin es wäre ein schlechter Rat da gleiche Bilder jeweils nur einmal geladen werden würden und nicht 10 mal und bestand auf seiner repetierenden Lösung mit wiederholtem 1 Sternchen Image.

Er hat Recht mit der Aussage das bei der Einbindung von 10 gleichen Bildern es nur 1 x geladen wird - keine mir unbekannte Sache.

Aber man kann deutlich erkennen wie unterschiedlich Performance ausgelegt wird.

Gehen wir mal davon aus, man hätte 25 Bewertungspositionen auf einer Seite und jeder hat z.B. 5 Sternchen, dann muss der Browser 125 Sternchen verarbeiten. Das eigentliche Image wird nur 1x geladen, aber 125 mal verarbeitet.

Der praktische Test hat dann ergeben, das sich die Renderzeit um den Faktor 5 verlängert - da waren es auf einmal über 6 Sekunden.

Selbst wenn Request's nicht mehr ausgeführt werden, weil wie hier das Image nach dem ersten Mal vorliegt - werden Request's vom Browser noch zu verarbeiten sein.

Bei dem Diskussionsteilnehmer - wie gesagt ein Fachmann - hörte das Thema Performance mit der Bereitstellung des Codes auf, in meiner Denkweise ist Performance das was ein Besucher beim Aufruf einer Seite erlebt und das kann völlig unterschiedlich sein.

Beitrag geändert von piratos (14. September 2011 11:00)

nicmare · 14. September 2011 11:03

und worauf willst du jetzt hinaus? hast du jetzt eine frage zu einer alternative oder was beabsichtigst du?

finde die verwendung von bildern hierfür so oder so nicht sinnvoll. lieber text ausgeben und diesen dann mit css und background-image formatieren. so kann man einen div nehmen der als hintergrundbild einen stern mit repeat-x besitzt. durch die länge des divs, werden die anzahl der sterne dargestellt. "blinde" oder "bilderfreie" browser sehen dann trotzdem den semantisch korrekten text zur bewertung.

NaN · 14. September 2011 11:21

Hätte da jetzt auch eher an background-image gedacht. Allerdings weiß ich leider immer noch nicht so genau, wie sehr es den Browser (bzw. den Rechner) belastet, bei 125 Elementen die Hintergrundgrafik n-mal zu verarbeiten.

piratos · 14. September 2011 11:31

Wir sind hier am Stammtisch und nicht um konkrete Fragen zu stellen.
Hier geht es weniger um die Art wie man Sternchen erzeugt sondern um den Denkansatz zu Performance.

Der entscheidende Punkt ist das andere Fachleute mit der Abgabe eines für ihn performanten Codes das Thema Performance erledigt ist, dieser Umstand aber nicht eine reale erlebte Performance erzeugen muss, ja sogar voll am Thema vorbei geht und genau das Gegenteil erzeugt.

Das könnte vielleicht mal Leute anregen die Code erstellen der aus ihrer Sicht performant ist, nicht aber real ist, da Performance genau das ist, was beim Besucher ankommt.

Es gibt da leider viele Produkte bei denen Coder nur an für sie performanten Code denken nicht aber daran, was passiert wenn sie den Krempel an den Browser schicken.

Denkt ein Coder da nicht weiter, kann es danach nicht rosiger werden.

Einer der übelsten Produkte in dieser Hinsicht ist z.B. Prestashop, was die Kodierung betrifft sehr wirksam, was den Output betrifft grauenvolle Leistung.

Und - man kann da auch jede Menge kaputt machen, wenn man Smarty einsetzt und nicht darüber nachdenkt wie man das am besten machen kann.

NaN · 14. September 2011 11:42

Man muss ja nur mal bissel rechnen.
Wenn ich nur eine Grafik mit einem einzigen Request habe, die aber bei 50 Elementen bis zu je 5 mal vorkommen kann, dann sind das bis zu 250 Grafiken die der Browser rendern muss. (egal ob als Hintergrundgrafik oder als image, oder?)
Wenn ich aber 10 Grafiken habe, von denen bei jedem der 50 Elemente nur eine vorkommt, dann sind das maximal 50 Grafiken die der Browser rendern muss. (allerdings statt einem Request bis zu ganzen 10 Requests)
Da so eine Sternchengrafik ja nicht besonders groß ist, könnte man diese auch mit base64 einbetten. Dann spart man sowohl Requests als auch Renderei.
So zumindest habe ich das Problem gerade verstanden.

piratos · 14. September 2011 11:59

Konkret kann man das mal hier sehen , da gibt es eine ziemliche Verdichtung da sich die Ratings wiederholen.
In der Tat hatte man da vorher die 1 Sternchen Lösung gehabt mit fatalen Folgen was Performance betrifft, dann auf meinen Rat hin base64 und maximal 5 Images eingesetzt.
Der Erfolg real sehr schnelle Seite und Pagespeed 100/100 (Pagespeed 1.12).

Aber wie gesagt, es geht mir mehr um die Sichtweise von Codern die meinen sie hätten optimales abgeliefert aber dabei einfach den Rest nicht sehen.
Solche Dinge gibt es auch bei CMSMS.

NaN · 14. September 2011 12:12

Das hat aber doch weniger mit dem System zu tun, sondern eher mit dem Webdesigner, oder worauf genau willst Du hinaus?

Mal noch eine Frage zu Deinem verlinkten Beispiel (mal abesehen davon, dass die Tabelle bei mir murks ist - vor jeder Zeile steht ein <tbody> wink ) :

Wie wäre das Performancemäßig zu bewerten, wenn ich anstelle von 50 base64 images im HTML Code nur 10 base64 images im CSS als Hintergrundgrafik hätte und stattdessen bei den 50 Elemente mit Klassen arbeiten würde? (mal abgesehen davon, dass ich dann immer alle 10 Grafiken im Stylesheet haben würde - was bei 3 Artikeln vielleicht blödsinng wäre)

piratos · 14. September 2011 12:31

Wenn du mal ein paar Postings vorher liest , da steht genau drin worauf ich hinaus will.

Was das Musterdesign betrifft - das steht nicht unter meiner Verantwortung wenn der sich seine Templates aus Dussligkeit zerballert (tbody über 270 Fehler und Folgefehler).

Wenn man von der Annahme des anderen Fachmann ausgeht, das es was Performance betrifft nichts ausmacht ob man ein image 1x oder 10 mal lädt, da es sowieso nur 1x geladen wird kann man es mal hier vergleichen:

1x http://www.webpagetest.org/result/110913_HK_1K89M/

10x http://www.webpagetest.org/result/110913_QK_1K888/

Dann hat man eine Vorstellung, davon.

Bei der Musterseite kann ich mich dunkel daran erinnern das da mal eine Zeit von ca. 4,5 Sekunden heraus kam bei Einzelimages, war jedenfalls absolut unbrauchbar..

Bei solchen Dingen haben wir grundsätzlich 2 Verantwortliche - Coder die eine Menge vorgeben und letzten Endes nur eine Nutzung wie es ist ermöglichen und natürlich auch Webdesigner die da im Rahmen ihrer Möglichkeiten etwas richten und vermurksen können.

Wenn Coder ein komplettes Basissystem anbieten, dann müssen die auch daran denken, das u.U. ihr optimaler Code letzten Endes unterm Strich vielleicht absolut nicht optimal ist und mal über das Coding an die Dinge denken, die auf dem Transfer der Inhalte und in den Browsern ablaufen.

NaN · 14. September 2011 12:59

Sorry, ich checks immer noch nicht.

Wenn Coder ein komplettes Basissystem anbieten, dann müssen die auch daran denken, das u.U. ihr optimaler Code letzten Endes unterm Strich vielleicht absolut nicht optimal ist und mal über das Coding an die Dinge denken, die auf dem Transfer der Inhalte und in den Browsern ablaufen.

Wenn Coder ein komplettes Basissystem anbieten, dann bieten sie ein komplettes Basissystem an. Keine Webseite. Der Entwickler des Systems hat doch keinen Einfluss darauf, wie es am Ende eingesetzt wird. Wenn der Webdesigner Mist baut, dann ist das doch nicht Schuld des Coders.

Wenn einer alles macht - also CMS und Webseite - dann muss ich Dir zustimmen, aber wenn ich einen Entwickler habe, der nur für das CMS zuständig ist, dann hat der nichts damit zu tun, was am Ende beim Browser ankommt. Der verkauft nur das System. Was damit gemacht wird, ist nicht seine Sache. Er muss nur dafür sorgen, dass der Webdesigner alles an Daten bekommt, was er braucht. Genauswenig wie Du Dich in der Verantwortung siehst, dass bei den Tagungshotels in Hamburg jemand die Tabelle zerschossen hat. Und das ist ja wohl Dein System. Da bist Du der Coder. Und? Was kannst Du tun? Nichts. Denn der Fehler liegt nicht im System.

Dass man sich als Webdesigner darüber Gedanken machen muss, dass man eben nicht nur die Datenmenge und die Requests gering hält, damit die Daten schnell beim Browser sind, sondern seine Seite auch noch so aufbauen muss, dass der Browser sie auch noch schnell anzeigen kann, das steht für mich außer Frage.

Vermutlich verstehen wir beide unter Coder und Webdesigner wieder etwas anderes.

Hast Du vielleicht ein paar Erfahrungen bezüglich meiner anderen Frage?
Mich interessiert ganz allgemein, ob 50 base64 images direkt im HTML-Code performanter wären als 50 divs mit CSS Klassen und im Stylesheet 10 Klassen mit je einem base64 image als Hintergrund (also nur 10 base64 images insgesamt anstelle von 50). Von der Datenmenge her müsste es performanter sein, aber wie reagiert der Browser auf 10 Klassen, die er erst noch formatieren muss? (im Vergleich zu 50 base64 Bildern, die er einfach nur anzuzeigen braucht)

piratos · 14. September 2011 13:28

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.

Und viele Webdesigner verwenden das dann auch so wie vorgegeben, allein weil sie schon Angst haben irgend etwas verkehrt zu machen.

Also muss ein Coder da über den Tellerrand denken - so einfach ist das.

Schaut man sich z.B. Prestashop an, dann kann man dort sehr gut erkennen, das ein Webdesigner auf Grund der Programmierung in bestimmten Fällen keinerlei Einfluss hat.
Da kann es z.B. passieren das da 15 CSS Dateien auftauchen, weil man 15 Module/Plugins eingebunden hat - gleichzeitig hat man eine Unmenge von Smarty Minitemplates die insgesamt etwas verursachen, was man in einem Shopsystem überhaupt nicht gebrauchen kann - Langsamkeit.

Oder ein anderes Beispiel - so etwas wie eine Instantsuche ist bei cmsms nicht möglich, das gibt das komplette System nicht her, das aber ist tatsächlich äusserst performant und Server schonend und für den Besucher der in einer Website etwas sucht äusserst befriedigend (kennt man ja bei Google und Co) und für Mobile ist das der Knüller.
Die Suche bei CMSMS hat z.B. keinen Textauszug - auch da kann der Webdesigner normal nicht dran drehen.
D.h. hier hat der Coder über die Datenaufbereitung festgelegt was machbar ist und was nicht.

Da muss aber ein Coder ebenfalls über den Tellerrand schauen.

Ein Coder muss sich auch Gedanken machen, wenn er wegen Performance z.B. die Nutzung von Application Cache möglich machen will, denn da muss er dafür sorgen, das die Erneuerung beim Endverbraucher bei Inhaltsänderungen angestossen wird - das ist auch so ein Punkt wo der Coder in Verantwortung steht, egal ob ein Webdesigner so etwas einsetzt oder nicht.

Oder die Seitenabhängige Ausgabe von CSS - auch eine Sache eines Coders.

Oder die automatische vom Browser abhängige Generierung von base64 Images.

Da gibt es jede Menge anderer Beispiele wo ein Webdesigner verloren ist, weil Coder nicht darüber nachdenken.

Zur Frage:

base64 inline ist in dem Fall schneller als eine Formatierung mit CSS, das hatten wir auch probiert, es ist auch schneller als css images die dort ebenfalls als base64 ausgeführt werden.
Zusätzliche CSS die man nur auf bestimmten Seiten benötigt behindern zudem auch andere Seiten.

Beitrag geändert von piratos (14. September 2011 13:30)

faglork · 14. September 2011 14:49

piratos schrieb:

Gehen wir mal davon aus, man hätte 25 Bewertungspositionen auf einer Seite und jeder hat z.B. 5 Sternchen, dann muss der Browser 125 Sternchen verarbeiten. Das eigentliche Image wird nur 1x geladen, aber 125 mal verarbeitet.

Ein klassischer Fall für ein css sprite ...

Servus,
Alex

NaN · 14. September 2011 15:12

Es geht hier um die Renderzeit im Browser, weniger um die Anzahl der Requests oder die Datenmenge.

mike-r · 14. September 2011 21:04

Viel schöne Theorie, aber keine Testcases. Ach so, ist ja Stammtisch.
Letztendlich würden auch Testcases nicht wirklich helfen, da jeder Rechner anders ist, ich meine aber, dass es auf einer 3 Jahre alten Kiste im Rendering genau keinen Unterschied macht, ob man (bis zu)250 einzelne Sternchen hat, oder 50×5 verschiedene Grafiken oder 50 base64-grafiken oder aber den Spass mittels Klassen zurechtpfriemelt.
(Letzteres ist selbstverständlich der eleganteste Weg, selbst wenn er 20ms mehr CPU ziehen würde...)

Zum Rendering gehört übrigens noch anderer Spass wie Hintergrundbilder. Wenn wir da hier mal exemplarisch die Tagungshotels (http://www.tagungshotels.com/background_gradient1.jpg) hernehmen als Beispiel, da hätten wir oben ein 5px breites Bild welches auf 1024px theoretisch 200 mal gerendert werden muss. Eine breitere Grafik (mglw. PNG) würde hier (afaik) ordentlich CPU-Last und wahrscheinlich auch Ram sparen. Siehe auch: http://blog.vlad1.com/2009/06/22/to-spr … to-sprite/
Des Weiteren ein CSS was 42KB zieht, wo wahrscheinlich 42 Eigenschaften vollends ausreichen würden.
HTML4-inline-hokuspokus noch und nöcher, der zu allem Überfluss dann vom CSS auch noch überschrieben wird (doppelte Rechenzeit). Und dergleichen so weiter.

Insofern muss ich Dir zustimmen:

piratos schrieb:

Der entscheidende Punkt ist das andere Fachleute mit der Abgabe eines für ihn performanten Codes das Thema Performance erledigt ist, dieser Umstand aber nicht eine reale erlebte Performance erzeugen muss, ja sogar voll am Thema vorbei geht und genau das Gegenteil erzeugt.

Übrigens, wobei das wieder in Richtung Traffic geht; meine ich mal gelesen zu haben, dass Dateien unterhalb 4kb (bzw. vielfachen von 4KB) aufgrund von gängigen Clustergrössen nicht mehr zwingend weiter-optimiert werden müssten. Ich finde da leider grad keine Quelle dazu, weiss da jemand was?

dc2 · 15. September 2011 22:07

Meinst du die Segmentgröße bei TCP/IP? Die liegt bei maximal 1.500 Bytes (über Ethernet).
Anders sieht es bei der Blockgröße auf Festplatten (normal ab 4 kBytes) aus, aber das hat mit dem Traffic ja nichts zu tun, falls du das vielleicht meintest.

NaN · 15. September 2011 22:27

piratos schrieb:

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 wink Wenn CMSms etwas von Haus aus nicht kann, dann muss man selbst eben dafür sorgen, dass es das kann wink
Und das ist zum Glück kaum eine Hürde.
Das ist CMSms zumindest für mich: Ein Werkzeug. Keine Lösung.

mike-r · 15. September 2011 23:12

dc2: jo, danke, das meinte ich - dann ist die "Traffic"-Grenze bei 1452bytes unterhalb derer man für Traffic-"geschwindigkeit" nichts mehr optimieren muss.
Im Rendering (Festplattenblockgrösse) wird es da vielleicht auch einen gerade noch so messbaren Effekt geben zwischen 4kB und 4,1(=8kB) vermutlich ist der allerdings im homöopathischen Bereich.
Vielleicht hat da jemand mehr Infos dazu...

piratos · 15. September 2011 07:31

NaN schrieb:

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.

piratos · 15. September 2011 07:36

mike-r schrieb:

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.

piratos · 15. September 2011 08:45

Etwas ausserhalb des Focuses hier aber im Zusammenhang mit Instantsuche interessant.

mike-r · 15. September 2011 20:02

piratos schrieb:

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.

Beitrag geändert von mike-r (15. September 2011 20:02)

piratos · 16. September 2011 09:47

mike-r schrieb:

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.

mike-r · 16. September 2011 11:31

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

NaN · 16. September 2011 11:51

@mike-r: Ein guter Zauberkünstler verrät nie seine Tricks wink

piratos · 16. September 2011 12:34

mike-r schrieb:

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.

NaN schrieb:

Ein guter Zauberkünstler verrät nie seine Tricks

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

Beitrag geändert von piratos (16. September 2011 12:37)

mike-r · 16. September 2011 13:19

piratos schrieb:

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?

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.

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

Forum für CMS/made simple

#1 14. September 2011 10:55

Bewertungssternchen - Performanceansichten

#2 14. September 2011 11:03

Re: Bewertungssternchen - Performanceansichten

#3 14. September 2011 11:21

Re: Bewertungssternchen - Performanceansichten

#4 14. September 2011 11:31

Re: Bewertungssternchen - Performanceansichten

#5 14. September 2011 11:42

Re: Bewertungssternchen - Performanceansichten

#6 14. September 2011 11:59

Re: Bewertungssternchen - Performanceansichten

#7 14. September 2011 12:12

Re: Bewertungssternchen - Performanceansichten

#8 14. September 2011 12:31

Re: Bewertungssternchen - Performanceansichten

#9 14. September 2011 12:59

Re: Bewertungssternchen - Performanceansichten

#10 14. September 2011 13:28

Re: Bewertungssternchen - Performanceansichten

#11 14. September 2011 14:49

Re: Bewertungssternchen - Performanceansichten

#12 14. September 2011 15:12

Re: Bewertungssternchen - Performanceansichten

#13 14. September 2011 21:04

Re: Bewertungssternchen - Performanceansichten

#14 15. September 2011 22:07

Re: Bewertungssternchen - Performanceansichten

#15 15. September 2011 22:27

Re: Bewertungssternchen - Performanceansichten

#16 15. September 2011 23:12

Re: Bewertungssternchen - Performanceansichten

#17 15. September 2011 07:31

Re: Bewertungssternchen - Performanceansichten

#18 15. September 2011 07:36

Re: Bewertungssternchen - Performanceansichten

#19 15. September 2011 08:45

Re: Bewertungssternchen - Performanceansichten

#20 15. September 2011 20:02

Re: Bewertungssternchen - Performanceansichten

#21 16. September 2011 09:47

Re: Bewertungssternchen - Performanceansichten

#22 16. September 2011 11:31

Re: Bewertungssternchen - Performanceansichten

#23 16. September 2011 11:51

Re: Bewertungssternchen - Performanceansichten

#24 16. September 2011 12:34

Re: Bewertungssternchen - Performanceansichten

#25 16. September 2011 13:19

Re: Bewertungssternchen - Performanceansichten

Fußzeile des Forums