August 2010
Performance als Schlüssel zum Erfolg
Fortsetzung, Teil 4
Dynamischer Inhalt
Obwohl der Grossteil des Inhalts auf Nachrichtenseiten für eine geraume Zeit statisch ist (neue Nachrichtenmeldungen kommen nicht im Sekundentakt), gibt es genug dynamischen Inhalt, der für jeden Benutzer neu generiert werden muss. Als Beispiel seien hier alle Arten von Ticker-Informationen, Wetter bzw. personalisierte Werbung genannt.
dynaTrace identifiziert dynamische Inhalte aufgrund einiger Regeln die im Best Practice on Server-Side Performance-Dokument beschrieben sind. Diese Requests werden im Server-Side-Tab aufgelistet und nach Server-Zeit sortiert. Die Server-Zeit ist jene Zeit, die oft als Time-To-First-Byte bezeichnet wird. Es ist also jene Zeit vom letzten Byte des HTTP-Requests bis zum ersten Byte des HTTP-Response. Es beinhaltet auch die Netzwerklatenz zwischen Browser und Server – kommt jedoch so nahe wie möglich an die tatsächliche Server-Zeit heran. Folgender Screenshot zeigt die dynamischen Inhalte für Bild.de:
Die langsamsten Requests sind die Börseinformation, die Initialseite selbst sowie das Wetterservice. Weiters finden wir einige Requests auf ein externes Werbeservice sowie Requests auf einen Web-Tracking-Service (nicht sichtbar im obigen Screenshot). Server-seitige Performance stellt also vor allem bei dynamischen Inhalten ein Problem dar – und zwar genau dann, wenn viele Benutzer gleichzeitig auf die Seite zugreifen. Dann ist es natürlich um so schlimmer, wenn genau diese Inhalte langsam sind und Benutzer davon abhalten, mehr Zeit auf der Seite zu verbringen bzw. tatsächlich auf diese Werbebanner zu klicken.
Unter
Top 10 Performance Problems taken from Zappos, Monster, Thomson and Co
finden Sie Informationen über die typischen Server-seitigen Performanceprobleme und wie man Sie am besten vermeidet.Fazit: Wer liefert die schnellsten News?
Im direkten Vergleich schneiden beide Webseiten beinahe gleich schlecht ab. Beide haben sehr viele Inhalte auf den Seiten ohne Gebrauch von allgemeinen Best Practices in den Bereichen Browser-Caching oder Netzwerk-Roundtrips zu befolgen. Die Gesamtladezeiten beider Seiten sind mit 14 Sekunden (hängt natürlich vom Internetzugang ab) relativ hoch. Beide Seiten liefern dem Benutzer ein erstes visuelles Feedback in einer akzeptablen Zeit (< 2 Sekunden). Sowohl dynaTrace als auch PageSpeed und YSlow erlauben es, die gesammelten Resultate nach ShowSlow zu exportieren. ShowSlow ist eine Open-Source-Plattform und dient als Performance-Repository für Web-Metriken. ShowSlow.com hostet eine öffentliche Instanz dieser Software und ermöglich Ihnen, Ihre eigenen Resultate hochzuladen und zu vergleichen:
Der Unterschied in der Gewichtung der drei Tools kommt daher Zustande, da z.b. dynaTrace mehr Wert auf die tatsächliche Ladezeit (14 Sekunden) legt, wohingegen YSlow und PageSpeed mehr Wert auf allgemeine Best Practices legen. Ein guter Mix aus allen Tools ist daher ratsam – vor allem weil nicht jedes Tool alle Browser unterstützt.
Wer ist nun der Gewinner der Analyse? Die Gewinner sind hoffentlich die Leser dieser Online-Nachrichtenangebote. Mit Hilfe derartiger Analysen, mit Hilfe von Tools, die Probleme aufdecken, und mit Hilfe von Personen wie Steve Souders wird Performance verstärkt ins Lampenlicht gerückt:
Performance == Mehr Benutzer == Mehr Umsatz
Andreas Grabner hat mehr als 10 Jahre Erfahrung als Architect, Software Entwickler und Performance Engineer. Er arbeitet derzeit also Technology Strategist bei dynaTrace. In dieser Rolle beeinflusst er die Productstrategie von dynaTrace und arbeit eng mit Kunden um Performance Management in deren Prozessen über den gesamten Entwicklungszyklus zu Integrieren.
Vor dynaTrace war Andreas 7 Jahre bei Segue Software (später Borland) als Entwickler, Performance Engineer und Product Manager tätig.
KMB 03.08.2010 um 16:46 Uhr
Die Screenshots zeichnen sich durch eine gewisse "Nicht-Größe" aus. Ist das beabsichtigt?
#zitieren
Andreas Grabner 03.08.2010 um 18:00 Uhr
Sorry das die Screenshots hier nicht in voller Grösse zur Verfügung stehen. Der Artikel ist auch auf Englisch unter http://blog.dynatrace.com/2010/08/03/performance-as-key-to-success-how-online-news-portals-could-do-better/ verfügbar. Auf diesem Blog kann man auf die Bilder klicken um eine grössere Version davon zu sehen
#zitieren
Trepper 04.08.2010 um 13:10 Uhr
Probleme wie die beschriebenen bekommt man, wenn sich Entwickler zu weit vom zugrunde liegenden Protokoll (HTTP) entfernen. Man kann nur hoffen, dass REST von immer mehr Entwicklung beachtet wird.
#zitieren
Daniel 26.08.2010 um 11:01 Uhr
Neben mergen kann man die css- / js - Dateien noch komprimieren und ggf. gzipped ausliefern. Die modernen Browser unterstützen das meist ohne Probleme.
Zusätzlich kann man Bilder auch einfach als data-Element in css setzen. Dadurch dass sich Text leichter komprimieren lässt als Bilder hat man auch hier einen Vorteil. Problem ist nur dass (wie so oft) der IE nicht mitspielt. Es gibt noch zig andere Ansätze. Der Bericht ist aber super aufgegliedert und sollte helfen das Thema bei vielen etwas zu sensibiliseren. #zitieren
Anni 08.10.2010 um 00:23 Uhr
Mir will nicht einleuchten, warum ich js dateien mergen soll. 4 js dateien á 5kb das stück machen zusammen eine á 20kb. warum sollte es einen unterschied machen, 20kb aufgeteilt und nur bei bedarf auszuliefern oder direkt gleich alles in einem runterladen zu müssen? ich binde die css- und js dateien nur auf den seiten ein, auf denen sie benötigt werden. ist das nicht eher sinnvoll?
#zitieren
Andreas Grabner 08.10.2010 um 07:27 Uhr
Das mergen von js-dateien bringt vorteile - muss aber genau geprüft werden. Mergen reduziert zum ersten mal die anzahl der HTTP Roundtrips. Weiters kann die JS-Engine auf einen schlag das JS verarbeiten anstatt das in mehreren schritten zu tun. Bei jedem JS File das geladen und ausgeführt wird muss der Browser sicherstellen das keine anderen aktivitäten die ausführung des JS beinflussen, z.b.: muss sichergestellt werden das das DOM in der zwischenzeit nicht geändert wird. Diese "Context Switches" sind zwar nur bedingt aufwendig - trotzdem sind sie nicht zu vernachlässigen.
In punkto deployment haben sie aber recht. mehrere files haben den vorteil gezielt codeteile auszutauschen. daher muss man hier gezielt entscheiden ob merging sinn macht. In meiner arbeit mit web 2.0 unternehmen hab ich seiten angetroffen die bis zu 50 js files auf einer seite hatten. hier hat sie das merging definitiv eine performanceverbesserung gebracht #zitieren
Tino B. 11.10.2010 um 12:39 Uhr
Hallo,
ich bin Webentwickler speziell für Joomla!-basierte Websites. Ich kann bestätigen, dass zumindest die Komprimierung von CSS- und JS-Dateien einen spürbaren Unterschied in der Ladezeit der Seite ausmacht. Allerdings handle ich es auch so, dass nur die im jeweiligen View benötigten CSS- und JS-Dateien vom diesem View eingebunden und deployed werden. Im globalen CSS stehen nur Regeln, die sich über die gesamte Seite erstrecken. So meine ich, zu verhindern, dass jedes Mal ein gigantisch großes CSS verarbeitet werden müsste, was vermutlich längern dauern würde - analog für JS.Interessant war beim Test von z.B. YSlow, dass empfohlen wurde, die insgesamt 20 CSS und 30 JS zu mergen. Diese liegen jedoch nur auf dem Server, sind aber niemals gleichzeitig eingebunden. YSlow überprüft also scheinbar die Verzeichnisinhalte und nicht die im Dokumentenkopf registrierten CSS und JS und erteilt seine Empfehlungen folglich auf dieser Grundlage statt auf Basis einer Messung. Das halte ich für fragwürdig.
Was mir nicht verständlich erscheint ist, wie gzip komprimierte Dateien, welche doch auch mit dieser Endung gespeichert werden, vom Dokument wieder entpackt werden sollen, um damit arbeiten zu können!? #zitieren
Bester Kommentar
Letzte Kommentare
- Coole Nerd T-Shirts gewinnen! von Jörn
- Verkorkste Premiere? Social-TV-Sendung Rundshow steckt Prügel ein von Nicole Haase
- Neun iOS-Touch-Display-Gesten und ihre Namen von ToM
- Fehler auf iPad-Plakat: Wir haben das Foto nachgestellt [Update] von Bernhard
- Peinliche Panne in aktueller iPad-Werbung von Apple [Bilder] von Mikael
Artikel
Kolumnen
Buchtipps
Snippets
Whitepaper
Buchtipps / Archiv
Spontaneous Sculptures
COD gibt 10 Punkte!
