SVG, yeah you know me

Update: Der hier besprochene Bug wurde inzwischen gefixt.

Oder eher I know you. Über den meiner Meinung nach vorliegenden Safari SVG Sprite Bug hatte ich ja schon berichtet. Kurz zusammengefasst: neuere (mobile) Safari laden ein SVG-Sprite jedesmal komplett runter, wenn ein SVG-Icon daraus angezeigt wird. Das konnten beim ersten Aufruf ohne gefülltem Cache bei der Homepage von zeit.de schon mal bis zu 17MB sein. Um es kurz zu machen, die Welt interessiert sich nicht dafür, weder Apple, die den Safari baut, und auch nicht die Autoren von svg4everybody, die die SVG-Sprite-Technik populär gemacht haben (unter Webentwicklern).

Update: Martin Wolf hat den Screencast zum Bug gedreht.

Lösungssuche

Also mussten wir anderweitig handeln und die Sprites ersetzen. Wenn man nun einmal SVG eingeführt hat, will man nicht wieder zurück auf Pixelbilder umsteigen. Ich habe also lange recherchiert, nach Techniken gesucht, versucht das Problem irgendwie wegzubekommen, allerdings ohne Erfolg. Eine Idee war, und die halte ich durchaus für valide, die SVG per XHR in die Seite zu laden. Für uns sprachen jedoch zwei entscheidende Dinge dagegen:

  • progressive enhancement: es gibt in dem Sinne keine wirkliche Basis, von der die AJAX-Lösung enhancen könnte, ausser vielleicht man schreibt einen Text anstelle des SVG und lädt an dieser Stelle dann die Grafik hinein. Grafik und Text nehmen aber nur selten den gleichen Raum ein, ein fürchterliches Geruckel und Gezucke wäre vorprogrammiert, überall dort, wo der Text größer als die Grafik wäre
  • unsere großen und komplizierten Logos: die Signets der ZEIT, des ZEIT MAGAZIN und so fort sind auch nach vielen Optimierungen immer noch sehr große SVG-Dateien mit vielen Knotenpunkten, gerade diese sollten aber immer vorhanden sein, dürfen also nicht durch Text ersetzt und per XHR nachgeladen werden. D.h. für die Logos musste sowieso eine andere Lösung gefunden werden (die noch verbleibenden Icons sind dann schon fast unerheblich klein).

Für die Logos war schnell klar, dass wir diese oldschool in das HTML einbetten müssen, so wie es auch bspw. Github mit seinen Icons macht. Am Ende haben wir uns entschieden, es mit allen Icons so zu machen: wir betten sie ins HTML ein.

<svg xmlns="http://www.w3.org/2000/svg" width="17" height="15" viewBox="0 0 17 15" class="svg-symbol" preserveAspectRatio="xMinYMin meet" role="img" aria-label="Leserempfehlung">
    <path d="M8.5 11.454L3.322 15l1.983-5.73L.12 5.73l6.405.004L8.5 0l1.975 5.734 6.404-.005-5.185 3.54L13.678 15"></path>
</svg>

Nach- und Vorteile

Das birgt tatsächlich ein paar Nachteile, vor allem weil die Grafiken damit zu Textcontent werden, zumindest aus Sicht des Cachings, es wird also nahezu nicht gecached. Das SVG-Sprite, dass nun wegfällt hingegen wurde natürlich auf ewig gespeichert. So wiegt die Seite nur beim initialen Laden weniger als vorher. Das ist leider weitestgehend ungelöst, auch wenn ich die Hoffnung habe, dass sich die SVG wenigstens sehr gut gzippen. Es bleibt aber eine lästige Abhängigkeit, die man eigentlich nicht haben will. Ohne Zweifel ist der Gewinn für Nutzer des mobile Safari allerdings grandios.

Die Lösung bringt aber auch Vorteile. Zunächst mal können wir uns nun eine Sonderlösung für cross-domain-Seiten einsparen und haben eine Menge polyfills abgeschafft, da das inlinen von SVG eine hervorragende Browserunterstützung genießt. Unser Grunt-Workflow hat sich dadurch auch deutlich verschlankt, weil wir bspw. keine Fallback-Bilder im PNG-Format mehr produzieren. Für das Einlesen der SVG habe ich einen Jinja-Helper geschrieben, der die Daten von der Platte holt (und das Ergebnis wegcached), und noch ein paar Änderungen am Code vornimmt, die wir sonst im Grunt mit svgstore gemacht haben (bspw. fill-Attribute wegstrippen). Außerdem kann man beim Aufruf das Füllen der ARIA-Attribute beeinflussen, damit in Situationen, in denen das Icon direkt neben einem erklärenden Text steht, kein doppeltes Vorlesen passiert:

<a href="#leserempfehlung">
<svg xmlns="http://www.w3.org/2000/svg" width="17" height="15" viewBox="0 0 17 15" class="svg-symbol" preserveAspectRatio="xMinYMin meet" role="img" aria-hidden="true">
    <path d="M8.5 11.454L3.322 15l1.983-5.73L.12 5.73l6.405.004L8.5 0l1.975 5.734 6.404-.005-5.185 3.54L13.678 15"></path>
</svg>
Leserempfehlung
</a>

Zumindest wurde so der Prozess auf Entwicklerseite stark vereinfacht. Und ein paar nodige Abhängigkeiten entfernt.

Geschmäckle

Was bleibt ist die Frage, warum das Problem eigentlich niemanden so richtig interessiert. Zunächst mal nehme ich inzwischen an, dass wir als Hochlastwebsite mit Massencontent zu den Paradiesvögeln gehören, wenn wir moderne Techniken des Web einsetzen. Die Verbreitung einer Lösung wie SVG-Sprites und da kann Chris Coyier noch auf sovielen Konferenzen dafür Werbung machen, scheint vergleichsweise gering, jedenfalls auf Seiten, die vielleicht mehr als ein oder zwei Icons pro Seite haben. Und dann interessiert es die Betreiber der Seiten, die das nun doch nutzen vielleicht auch nicht richtig, wieviel Megabytes für iPhone-Nutzer durch den Äther gejagt werden. Vielleicht monitoren sie das auch nicht so. Der Kunde merkt es vielleicht auch nur, wenn die sogenannte Flatrate schon Mitte des Monats leergesaugt ist. Apples Verhältnis zu Safari scheint sowieso ein Gebrochenes zu sein, was sich widerum im Verhältnis von Safari zu aktuellen Webtechnologien zeigt, da wird sogar zurückgebaut! Und schlussendlich muss ich auch zugeben, wahrscheinlich haben wir es mit unserem Sprite von der Größe her ein wenig übertrieben, zumindest hat das dem Bug vorschub geleistet.

Safari SVG Sprite Bug?

Update: Der hier besprochene Bug wurde inzwischen gefixt.

Ich hatte es schon getweetet, aber es liegt mir doch sehr auf der Seele, deswegen nochmal ausführlich hier…

Vor ein paar Tagen haben unsere Backend-Kollegen einen starken Anstieg an Downloads einer bestimmte Datei unserer Website festgestellt, nämlich jener SVG-Datei, in der unsere SVG-Sprites abgelegt sind. Die Datei wurde mit einem Male so exorbitant oft heruntergeladen, dass es in den Logs auffiel. Zunächst gingen wir natürlich von einem Fehler unsererseits aus, auffällig war allerdings von Anfang an, dass nur Safaribrowser (Desktop, vor allem aber Mobile) ab Version 9 die vielen Downloads verursachten.

Meiner Meinung nach haben wir es mit einem Bug in Safari zu tun. Und seit nun schon ein paar Tagen bin ich auf der Suche nach diesem Bug. Ich habe einen Testcase gebaut (um Knnfigurations- und Serverfehler zu vermeiden auf einem anderen Server), mit dem man das Problem nachvollziehen kann. Und nachdem ich nach langer langer Recherche sprichwörtlich nichts darüber im Netz finden konnte, habe ich einen Bug bei Apple eingetütet und ein Issue bei svg4everybody erstellt, dort wird die betroffene Technik ausgiebig genutzt, die sollten sich dafür interessieren. Bisher gab es keine Reaktionen.

svguse

Was ist denn das Problem?

Wir nutzen eine externe SVG-Spritemap. Darin befinden sich alle Icons und Logos, und braucht man ein Icon, wird es auf diese Weise in den Code eingebunden:

<svg class="svg-symbol logo_bar__brand-logo" role="img" aria-labelledby="title">
    <use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="icons.svg#svg-logo-zon-black"></use>
</svg>

Das geht natürlich nur in modernen Browsern, deswegen nutzen wir svg4everybody um das ganze für ältere Browser zu polyfillen, was aber keinen Einfluss auf den Bug hat. Auf einer Artikelseite mit Kommentaren, können so bis zu 30 Icons auf einer Seite auftauchen. In Chrome, Firefox und anderen wird das Sprite genau einmal geladen pro Seitenaufruf und dann natürlich gecached. In Safaris > 9 (unter iOS 9.3.1 oder auf dem Desktop 9.1.1) wird die SVG-Datei einmal pro angezeigtem Icon heruntergeladen, was ein sehr hohes Datenaufkommen verursachen kann (siehe oben). Uns fällt sowas in den Logs auf, Nutzer von mobile Safari spüren es womöglich auf ihrer Telefonrechnung.

Was bedeutet das?

Einfach gesagt: das Netz ist sowas von kaputt… man braucht keine leftpadding-Funktion via npm einzubauen, um eine Website kaputt zu machen. Allein schon ein Browserupdate kann einen in Teufels Küche bringen. Kann natürlich immer noch sein, dass der Fehler bei mir liegt (und ja, die Datei ist viel zu groß, da kann man ansetzen), vielleicht findet ja einer meiner Leser etwas… Mich beschleicht aber auch irgendwie das Gefühl, dass Apple SVG nicht so richtig im Safari haben will.

Für uns bedeutet das letztlich, dass wir unsere Art der SVG-Einbindung nochmal komplett überarbeiten müssen, wir wollen ja nicht noch mehr Daten ausliefern, als wir sowieso schon tun…

Update: Martin Wolf hat den Screencast zum Bug gedreht.

Fronteers Spring 2016

Talkshow

 

Jedesmal wenn ich auf einer Fronteers Conference war: hintendran diese Lobhudelei. Kann ich mir aber auch in diesem Jahr nicht verkneifen, auch und besonders im Vergleich mit meiner letztjährigen Konferenzpleite (ich nenne sie liebevoll the event that should not be named). Also liebe jungen Webentwicklerkollegen, die noch nie auf einer Fronteerskonferenz waren (gibt’s die?), fangt sofort an euren Chef zu löchern und bucht euch eine, z.B. im Oktober, da kann man nichts falsch machen.

Konferenzfrühlingsgefühle

Die Frühlingsausgabe in diesem Jahr stand unter dem inhaltlichen Thema »Performance« und dem Motto Frühling. Und während der englisch-pessimistische Host Phil Hawksworth eher Regenschirme verteilt hätte, gab es als einziges Konferenzgimmick in diesem Jahr eine Fronteers-Sonnenbrille, die Organisatoren wussten warum.

Das Format

Das Format der Springconference war IMHO schon experimentell, aber zum allergrößten Teil auch gelungen. In drei Themenblöcken gab es drei Talks zu jeweils 20 Minuten und danach eine gemeinsame Talkrunde mit den Sprecherinnen und Sprechern. Hier wurden dann auch die per Twitter aus dem Publikum gestellten Fragen eingebaut.

Dazwischen blieb viel Platz fürs coffiedrinke und kommunikatie maken im wunderbaren futuristischen Veranstaltungsort EYE.

EYE von oben

Mein einziger Kritikpunkt hier sind vielleicht die 20-Minuten-Talks, bei denen die Sprecher öfter zum Schnellsprechen und Foliendurchwinken tendierten, anstatt sich thematisch zu konzentrieren und einzuschränken. Aber das hatte im Grunde nur Auswirkungen auf meine geliebten conference notes, inhaltlich war alles top.

Das Thema performt

Der Tag war eingeteilt in drei Unterbereiche:

  • Visual Performance, hier ging es um das Gefühl von Schnelligkeit auf Webseiten, Zeit und Geschwindigkeit an sich und wie man all dies für seine Seite einsetzt, um dem Nutzer ein flüssiges Nutzungsgefühl zu vermitteln, das vielleicht gar nicht immer das schnellste ist;
  • Accessible Performance, hier wurde gezeigt, dass man bei allem Herausholen von Millisekunden, die Zugänglichkeit der Seite nicht aus dem Blick verlieren darf, und das eben diese Zugänglichkeit auch ein Performancewert ist;
  • Technical Performance, hier ging es nun darum, wie man technisch am besten und sichersten eine guter performende Website hinbekommt.

Abgeschlossen wurde der Tag dann mit einer Keynote, in der Kristian Sköld vermittelte, wie man die Arbeit an der Performance von Webseiten innerhalb des Unternehmens oder beim Kunden bewirbt und sich Sponsoren für den Kampf um Millisekunden sucht. Den Tag über war eben genau diese Frage, wie üblich gemischt mit etwas Unmut, in mir aufgekommen: wer soll das eigentlich alles bezahlen?! Die perfekte inhaltliche Klammer also.