HTML Media Embeds optimieren

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.

Natürlich spart man mit so einem Ansatz auch keine echten Requests, aber das initiale Laden einer Seite, die ein Media Embed enthält, fühlt sich schneller an, gerade auch wenn man in Betracht zieht, dass nicht jeder Besucher der Seite, überhaupt so ein Embed anschaut.