DTrace für Web Performance Analyse?

S

SolarCatcher

Well-Known Member
Web Performance ist seit langem ein kleines Steckenpferd von mir. Tools wie webpagetest.org zeigen sehr schön, in welcher Reihenfolge und Zeit ein echter Browser die Resourcen anfragt und erhält (z.B. hier für bsdforen.de).

Oftmals sieht man allerdings eine lange "Denkpause", in der der Browser die ganzen JavaScript- und CSS-Dateien auswertet, bevor er mit dem Rendern der Seite beginnt. Leider kenne ich kein Tool, das hier zeigt, welche Resource wieviel Zeit/Rechenleistung/Speicher benötigt.

Daher wollte ich jetzt einmal in DTrace reinschauen (zum ersten Mal überhaupt). Hinweise im Web zum Profilen von PHP und/oder JavaScript gibt es genug. Aber ich finde erstmal keine Tipps, wie man eine Art Flow-Analyse einer Webseite im Browser hinbekäme.

Hat hier jemand DTrace Erfahrung und kann mir da einen Tipp geben? Sonst frage ich mal auf der DTrace Mailing-Liste nach.
 
Danke. Das ist ja ein Hammer-Tool! Allerdings wollte es nicht in FreeBSD... musste Windows bemühen (Google konnte mir auch nicht sagen, was da "Not supported for current toolbox target" unter "Performance" heißen soll). Dann werde ich mich mal da rein arbeiten...
 
Das ist schon sehr gut und ersetzt den FireBug nicht nur, sondern bringt noch einiges mehr. Wobei da einiges auch dann firefox spezifisch ist (internal GC, DOM-render, ..) und man andere Browser natuerlich auch testen muss.

Insgesamt wird das Thema viel zu unterschaetzt. Wir tunen uns "den Wolf" an Web/App/DB-Server und effektiv gehen dann in 2 sekunden bis zur vollstaendigen Anzeige einer Seite 1.5sec im browser "drauf", weil DOM und JS alles wegfrisst. (oh, und SSL!)
 
double-p schrieb:
Insgesamt wird das Thema viel zu unterschaetzt. Wir tunen uns "den Wolf" an Web/App/DB-Server und effektiv gehen dann in 2 sekunden bis zur vollstaendigen Anzeige einer Seite 1.5sec im browser "drauf", weil DOM und JS alles wegfrisst. (oh, und SSL!)
Zum Vergrößern anklicken....
Kann ich nur unterstreichen!

Es gibt glücklicherweise immer mehr Bücher, Webseiten und Tools, die einem helfen können. Denn leider sind es ja längst nicht mehr 2 Sekunden, die eine übliche Webseite braucht. Statistisch gibt es dabei sehr hohe Korrelationen zwischen Anzahl der benötigten Resourcen sowie zu übertragende Kilobytes auf der einen und Pageload-Zeiten auf der anderen. Haupt-Verursacher für lange Ladezeiten sind heute 1. Bilddateien (ich sehe immer wieder Seiten, die Bilder wenig komprimiert und in sowas wie 4000x3000 Pixel auf die Startseite hauen - manchmal sogar mehrere) und 2. "Third Parties" (angefangen von den ganzen Social Media Buttons bis sonstwo... weil die Marketingabteilung es ja am besten weiß).

Gerade auf Mobilgeräten kommt aber auch das Ausführen von JavaScript und das Anwenden der Stylesheets als Bremse hinzu. Chrome's Developer Tools bieten daher mittlerweile einige Throttling-Einstellungen (schon länger: Netzwerk; neu: CPU), um schlechtere Netzanbindung und langsamere Devices zu simulieren. Facebook hat ja bekanntermaßen letztes Jahr für seine Mitarbeiter den "2G Tuesday" eingeführt, damit die Mitarbeiterinnen und Mitarbeiter mal sehen, wie ein Großteil der Kunden im Netz unterwegs ist. Aber selbst LTE kann oft nicht helfen, wenn die Latenz sehr hoch ist. Wenn ich über 100 Resourcen von x verschiedenen Domains einbinde bricht einem das schnell das Genick.

Google versucht mit seinen "Accelerated Mobile Pages" (AMP) Project gerade Verlage zu schnelleren Seiten zu ködern. Die meisten Anforderungen, die Google dafür stellt, sind aber auch unabhängig von diesem Projekt fast schon eine Garantie für kurze Ladezeiten.
 
Gestern entdeckte ich die Analyse eines Google-Mitarbeiters, der analysiert hat, warum die Airbnb-Webseite auf seinem Smartphone fast 10 Sekunden lang gar nix tut, wenn er nach dem Laden nur mal eben Scrollen wollte. Script-Parsing war der Verursacher. Gefunden mit verschiedenen Boardmitteln in Chrome:
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben