Von gemessener und wahrgenommener Browser Performance

Chris_ — Thu, 09 Oct 2014 12:48:28 +0000

In den letzten Tagen habe ich versucht, an den ganz hippen Performance Stellschrauben der Seite zu drehen. Render-blocking JavaScript and CSS in above-the-fold content scheint der moderne Bösewicht im Reich der Client-Performance. Relativ schnell war das Problem auf einer Testseite behoben und ich muss schon zugeben, Google belohnt die Mühen eindrucksvoll auf seinen diversen Testseite. Webpagetest dagegen zeichnet ein durchwachsenes Bild und da fingen dann meine Zweifel an.

Keine Frage, jeder Nutzer nimmt eine ordentlich schnelle Seite positiv wahr und sicherlich ist es noch nie gute Praxis gewesenen, Browser durch das Warten auf Ressourcen von der Arbeit abzuhalten. Laut alle Testtools war meine einzelne Testseite plötzlich beeindruckend gut. Aus menschlicher Sicht jedoch, sah ich erstmal nur Verschlechterungen, die man einfach mal so an einem Nachmittag nicht behebt.

Zwar kann ich meine externen Ressourcen (Google Webfont, noch jQuery) ersetzen und / oder direkt in der Seite laden, aber die externen Quellen sind so schnell, dass mein Server ein potentielle Verbesserung negiert. Dazu muss man sagen reden wir hier über Bruchteile von Sekunden und selbst ohne die Verbesserungen, pendelt sich die Seite bei einem sehr ordentlichen Webspeed Score von knapp über den magischen 1000 ein.

Wahrnehmung gewinnt

Ich lese immer wieder fasziniert von diversen Beispielen der Performanceoptimierung im Browser und Hut ab für den Aufwand, den viele Seiten da auf sich nehmen. Von nichts kommt auch hier nichts. Möchte man alle Stolperfallen vermeiden, ist mir der Aufwand für meine private kleine Seite hier, erstmal etwas zu groß, besonders, da die wahrgenommene Performance auch ohne diese Maßnahmen meinen persönlichen Ansprüchen genügt. Seit einiger Zeit sind meine eingebettet Videos – für mich ein der wirklich leicht zu lösenden Probleme – optimiert.

DOM-Manipulation ist ein echtes Problem. Beispielsweise benötigen alle Embeds bei mir noch zusätzliches HTML, das so noch nicht im jeweiligen Artikel in der Datenbank steht. Ein Verzögern dieser DOM-Manipulation führt zu einem dieser Unschönen Effekte, dass sich die Seite nach dem Layout und Rendern noch weiter verändert. Auch hier gibt es diverse Methoden genau diesen Effekt zu verhindern, nur ist dies eben wirklich harte Arbeit und mir jetzt gerade erstmal zu aufwändig. Ich werde beide Branches weiterentwickeln und schauen wohin die Reise führt, aber für den Livebetrieb bleibt das Weblog erstmal wie es ist. Die eigene Wahrnehmung ist mir momentan noch etwas wichtiger als Google Page Speed & Co.

Feedback: 0 Kommentare

HTML Media Embeds optimieren

Chris_ — Wed, 14 Nov 2012 13:42:56 +0000

Neben dem ganzen hippen Design Kram einer neuen Version des Weblogs, schaue ich gerade sehr penibel, wo und wie man noch mehr an der Performance Schraube drehen kann. Eine der erste Stellen meines Weblogs sind hier die vielen eingebettenen Filmchen, meistens von YouTube. Wer sich mal angeschaut hat, was da so alles unter der Oberfläche geladen wird, noch bevor man überhaupt den Gedanken gefunden hat, auf Play zu klicken, der findet schnell sehr viel unnötigen Ballast, den YouTube einem da schickt.

Auf mobilen Geräten habe ich mir das noch nicht genau angeschaut, was auch schwieriger ist, da hier der interne Mediaplayer gefüttert wird und nicht wie so oft auf Desktop Browsern Flash. Trotzdem ist der Grundgedanke bei Media Embeds irgendwie sehr verbesserungswürdig. Zeit daran etwas zu ändern.

Ein paar Lösungen existieren schon. Ich glaube Squarespace hat hier versucht etwas zu verbessern, aber ein Blick auf das HTML und ich bastle lieber meine eigene Lösung. Die Grundidee bleibt gleich. Statt direkt das Embed beim Aufrufen der Seite zu rendern und damit alle nötigen Daten vorzuladen, obwohl sie eventuell überhaupt nie gebraucht werden, bereitet man einen Platzhalter vor, der auf Klick erst dann das eigentliche Embed / iFrame oder was auch immer bastelt.

Was wird genau gebraucht? Im Falle von YouTube eine ID, sowie die Breite und Höhe des Embeds. Eventuell wäre auch eine Vorschau hilfreich und genau sowas bietet YouTube auch nativ für jedes Video an. Mein bisheriger HTML5 Quellcode Entwurf sieht wie folgt aus:


  
    
    Video Abspielen

Ich hab lange überlegt, ob ein figure-Tag hier semantisch vertretbar ist und die Frage für mich mit Ja beantwortet. Noch besser, durch das Caption bekomme ich ein zusätzlichen Knoten, den ich später noch zum Play-Button wandeln werde. Der Rest ist CSS und ein etwas Javascript eines Kollegen. Auf Klick der Caption, liest man die data-Attribute des Bildes aus und baut damit den iFrame. Der Rest ist CSS, aber was zum Teufel sucht dieses span-Tag dort? Jetzt kommen wir zu meinem Lieblingsteil des Artikels.

Responsive Fubar

Zwar existieren viele aufgeblähte Javascript- aber nur eine recht solide CSS-Lösung für responsive Videos. Ich verwende diesen Ansatz schon auf der Portal-Seite vom Film des Tages. Die Sache bröselt aber wie ein morscher Baum in sich zusammen, sobald ich richtig responsiv auslassen möchte. Das Problem mit nur einem Container-Knoten? Die Höhe ist zwar relativ bemaßt, aber nach dem Rendern eben doch ein fixer Wert. Ändert man nun die Margins respektive die Breite, so behält er die Höhe jedoch fix bei, womit das Seitenformat nicht mehr stimmt. Das Video behält eine konstante Höhe, jedoch eine flexible Breite.

Durch den zusätzlichen Knoten löst sich das Problem, weil die Breite des eigentlichen Film-Knotens, nicht mehr manipuliert wird, somit skalieren beide Seite immer proportional korrekt. In meinem Fall ändere ich nur das figure-Tag. Das span passt sich dann automatisch an, hier anzusehen.

Ein paar Dinge noch dazu. Ja, jQuery komplett zu laden, ist überhaupt fraglich geworden, aber für einen Prototypen passt es noch. Dass YoTube solche Optimierungen nicht nativ anbietet, ist bei einem Mutterkonzern, der sich so Performance verschworen hat echt merkwürdig. Das Endergebnis? Die Testseite mit zwei unterschiedliche Filmen, einmal mit meiner Lösung und einmal Standard YouTube Embed Code. Die Zahlen sprechen für sich:

Doch nur die halbe Wahrheit

Was im Desktop Chrome so enorm performanter wirkt, lässt sich nur teilweise für einen mobilen Browser anwenden, da hier was eingebettete HTML Media Daten betrifft, einiges doch anders läuft. Beispiel? Das Autoplay im mobilen Browser? Viel Glück dabei. Der Media Player ist hier auf HTML Ebene überhaupt nicht einfach ansprechbar. Im Endeffeckt, muss ein Nutzer, dann zwei- statt nur einmal den Play-Button berühren. Autoplay für iOS/Android ist zeitweise über hässliche Hacks zwar möglich, aber keine Alternative für mich, insofern muss man damit leben.

Ich bin noch am Überlegen ob ich zukünftig solche Embeds nutzen möchte. Die Performance ist ein schon ziemliches Todschlagargument dafür. Das Formatproblem mit dem zusätzlichen Knoten zu lösen, stört mich allerdings noch sehr. Hinzu kommt, dass sowas wieder keinem Standard entspricht und ich nicht weiß, ob YouTube einen solchen Ansatz nicht irgendwann mal nativ anbietet.