 Ja, willkommen zu meinem Talk. Ich werde was über Bilder erzählen. Erst mal zu mir. Ich bin Walter Ebert. Ich bin freier Webentwickler aus Frankfurt, Armeien. Ist das nicht an? Noch mal? Nee. Jetzt besser. Jetzt? Jetzt geht es gut. Jetzt passt? Ja. Okay. Drei Stück. Drei Stück. Okay. Jetzt geht es besser. Okay, jetzt geht es besser. Mein Name ist Walter Ebert. Ich bin freier Webentwickler aus Frankfurt, Armeien. Ich mache seit den letzten Jahren auch viel WordPress und beschäftigen auch mit dem Thema Performance. Und Bilder sind ein Teil davon. Über den letzten Jahren ist es halt so, dass Webseiten immer größer werden. In den letzten fünf Jahren, umfangsdurchschnittliche Webseite ist dreimal so groß geworden. Und der größte Anteil besteht halt aus Bildern. Und jetzt ist halt so, dass Bildern optimiert werden können. Die werden einfach so hochgeladen und nicht für das Web optimiert. Das wird immer wichtiger, insbesondere für Mobile. Weil bei Mobile hat man eingeschränkte Bandbreite. Es gibt natürlich LTE, aber das hat man nicht überall. Jeder kennt es am Ende des Monats, dass man über seinen Datenlimit kommt. Und dann wird man gedrosselt. Und dann hat man vielleicht LTE, aber in der Praxis dann halt doch nicht. Und jeder, der mal mit der Bahn gefahren ist, weiß, wenn man mal LTE hat, ist das nicht über die ganze Strecke der Fall. Und das ist halt ein wichtiger Grund, Bilder zu optimieren. Da noch kommt hinzu. Natürlich, wenn man in Deutschland ist und Webseiten aufruft, ist es ja okay. Aber es gibt noch Leute, die nicht aus Deutschland sind und in Deutschland auch Besuch kommen und ihr Handys nutzen wollen. Hier ist ein Beispiel von Christian Heilmann. Er ist in Frankfurt, der in England lebt. Der Ballett ist in Deutschland und er hat Nachricht gekriegt. Die Kosten für Datenverkehr sind 6 Volt pro MB. Das umgerechnet 8 Euro pro Megabyte. Die durchschnittliche Seite ist 2 MB. Also pro Saudi-Aufruf muss man 16 Euro zahlen. Auch im Grund, um da zu optimieren. PHP Insight ist ein Tool von Google, weil Performance ist ein Ranking-Signal für die SEO. PHP Insight gibt so Bewertungen und Bilder sind da auch ein wichtiger Teil von hier. Hier ist ein Beispiel von einer Seite, wo man 1,8 MB sparen könnte laut Google. Natürlich bei Überbildern muss man halt gucken, welches Bildformat man wählen kann und sollte. GIF, PNG, JPEG sind halt die drei bekannten Formate, weil alle Browser die unterstützen. GIF ist gut für Logos, Grafiken. Das Vorteil von GIF ist, dass es auch Transprenz hat. Nachteile sind nur 256 Farben darstellen kann. Aktuell wird es oft genutzt, wenn Leute halt Animationen haben wollen. Das ist eigentlich auch das einzige Format, wenn das jetzt geht. PNG, wo da das Alternative für GIF erstellt, können wir Farben, also können bis zu 16 Millionen Farben darstellen. Auch ein Format, das für Logos, Grafiken gut geeignet ist. PNG unterstützt auch Transparenzen halt in mehreren Stufen, nicht wie bei GIF, wo man halt transparent hat oder nicht. PNG kann man unterschiedliche Anzahl der Farben einstellen, PNG 8 hat nur 256 Farben, das kann man gut als Alternative für GIF nutzen, weil das im Durchschnitt 21 Prozent kleiner Dateikröse ergibt. Und PNG kann man die Komprimierung einstellen. Man sollte immer die größte Komprimierung haben, das ist also 9, das hat man an Anfang einstellbar gemacht. Das Format ist ja schon 20 Jahre alt und die Rechner waren vor 20 Jahren nicht so schnell, deswegen hat man damals gesagt, dass man das einstellbar macht. Aber die Rechner sind so schnell, dass das kein Problem mehr ist. Es gibt natürlich JPEG, was explizit für Fotos entwickelt wurde. Weil es für Fotos entwickelt wurde, unterscheidet es auch keine Transparenzen. Wichtig Unterschied ist, dass die Bildqualität einstellbar ist. Das ist von 1 bis 100 Prozent. Das ist nicht klar definiert in den Standards. Jeder Softwarehersteller kann die Prozentzahl selber interpretieren, wie stark 50 Prozent ist. Da hat sich der WordPress 4.5 was geändert, weil Standard war, dass WordPress 90 Prozent Komprimierung macht. 4.5 hat man das auf 82 Prozent standardmäßig gesetzt, um halt kleinere Dateien zu generieren, aber mit Behalt von der Bildqualität. Wenn PAP Image Magic Extension installiert ist, dann wird noch automatisch an den Metadaten optimiert und ein paar Sachen rausgenommen. Und Update lohnt sich halt für Bilder, weil Dateigrößen einfach optimiert werden. Man kann natürlich, bevor man ein Bild hochlegt, auch vorher selbst optimieren. Das sind ein paar Tools, die man auf dem Desktop nutzen kann. Sie sind frei verfügbar. Image Optimum ist das beste Tool, was es da gibt, aber leider nur für Mac. Bei Trimages ist es so, dass es nur PNGs und JPEGs optimiert uns keine GIF-Bilder. Man kann es natürlich auch, wenn man Entwickler ist, automatisieren. Es gibt das Imageman-Paket, das man halt auch über Gold oder Grund nutzen kann. Das ist halt ganz nett für die Themenentwickler, dass man halt die Bilder, die man da nutzt, automatisch optimiert. Es gibt ja jetzt auch neue Formate. SVG ist schon relativ alt, aber explizit für Vektor-Grafiken gedacht. Also Sachen, die man in Illustrator oder Inkscape nutzt, dass man die halt in der Webseite anbauen kann. Es gibt halt so paar nette Features, dass man Animationen programmieren kann und auch mit CSS und JavaScript darauf zugreifen kann. Aber das ist mir so, wenn man gestalterisch was machen will. Interessant. Support ist eigentlich ganz gut. Eigentlich alle Browser und Justits außer IE8. Das ist natürlich abhängig vom Projekt, ob der Kunde will, dass IE8 noch unterstützt wird. Ich sag mal, wenn man Webseiten baut, die auf Endkunden sich rechnen, braucht man das nicht. Oft bei Unternehmenswebseiten, wenn man auch verlangt wird, dass IE8-Unterstütze wird, weil halt Mitarbeiter noch mit so einem alten Pause unterwegs sind. Aber das wird immer weniger. Und hoffentlich ist es bald dann komplett weg. Wenn man Fallback machen muss, ist das so mit Source-Set-Attribut das Einfachste. Es gibt so andere Methoden, aber das funktioniert halt ohne JavaScript und keine Trickserei. Bei Source-Set ist es halt so, dass es die Priorität hat über den Source-Attribut. IE8 kennt den Source-Set-Attribut nicht, also nimmt automatisch das Source-Attribut in diesem Fall. Natürlich kann man SVGs optimieren. Wenn es direkt aus Illustrator kommt, dann stehen da ganz viele Infos drin, die für Illustrator interessant sind, aber nicht für den Browser. Also das sollte man bevor man es hoch lädt, noch mal optimieren. Dann gibt es halt so ein paar Tools, die man nutzen kann. Und hier das SVG-OMG ist halt eine Webseite, wo man es halt online machen kann. Und die anderen sind es halt so, Kommandenzahlen sind toll, das ist nicht unbedingt jeder Mannssache. Ja, die htexs, sollte man auch ein paar Sachen reinschreiben, damit man sicher ist, dass SVG richtig unterstützt wird. Erstmal, ja, das SVG vom Browser erkannt wird. Das Add-in-Coding GZIP ist halt, wenn man das SVG vorher schon komprimiert, mit der Endung SVGZ, dass der Browser halt weiß, das ist schon komprimiert. Und in anderen Fall, wenn es halt nicht komprimiert ist, dass der Server die SVGs nochmal komprimiert, weil SVG ist ein Text-Datei. Und das wird dann über dein Browser komprimiert, damit der Datei halt kleiner wird bei der Übertragung. Ja, WordPress unterstützt SVG-Standard nicht in der Mediathek. Hier ist halt ein Snippet, damit man dafür sorgen kann, dass man SVGs in der Mediathek hochladen kann. Das ist manchmal notwendig und so ist es am schnellsten umgesetzt. Ja, die Formate, die ich bis jetzt gehören, dann gibt es schon ziemlich lange. Google hat sich mal Gedanken gemacht, von das muss doch besser gehen. Die haben sich das Web-P-Format ausgedacht, dass irgendwie eine Kombination ist von der SVG von GIF, PNG und JPEG. All die Ergenschaften haben die halt in Web-P kombiniert und nochmal die Kompromierung verbessert. Ein Nachteil ist halt, dass es nur von Google-Brausern unterstützt wird. Das wird sich vielleicht in Zukunft ändern. Firefox und auch Microsoft Edge überlegen sich, ob sie es vielleicht unterstützen. Ist noch nicht so weit. Es kann trotzdem interessant sein, Web-P zu unterstützen, weil Chrome-Markt einen Teil von über 50% hat. Mit dem HTML5-Picture-Element kann man das halt so aufbauen, dass man sagt, wenn ein Browser Web-P unterstützt, dass er Web-P nehmen soll. Und wenn nicht, dann nimmt er halt ein JPEG. Es fällt so eine Methode, dass man das unterstützen kann. Das kann man auch noch weitertreiben, weil es gibt Browser, die bestimmte Detail-Formate unterstützen. IE ist zum Beispiel der einzige Browser, der JPEG XR unterstützt. Das ist auch eine beste Gruppierung. Safari ist der einzige Format, der JPEG 2000 unterstützt. Dann hat man Web-P und JPEG. Ist natürlich Aufwand, lohnt sich für die meisten nicht, nur wenn man Riesen-Traffic hat. Und Nachteil ist natürlich das WordPress, das auch nicht unterstützt. Also da muss man sich dann was bauen oder über ein CDN irgendwie gehen. Also das ist nur interessant, weil man das entsprechende Budget hat. Den HTML-Figure-Element ist auch noch interessant, weil man da Informationen an Bild zuweisen kann. Man hat natürlich das Alt-Altribut, aber das ist eigentlich nur für Screenreader interessant. Und mit Fake-Caption kann man als Kommentar noch sichtbar machen. Und WordPress benutzt das Standards schon in der Galeriefunktion, also ist schon in WordPress mit dabei. Man kann auch bei dem Figure-Element mehrere Bilder nutzen und eine Caption dafür nutzen. Über die HD-Access kann man noch mal explizit zahlen, wie lange die Datei gecached werden soll, weil Standard ist dann nichts vorgegeben. Das ist halt dafür zu sorgen, dass der Browser auch Bilder gecached und beim nächsten Seitenaufruf nicht neu runterlädt. Das wird auch von Google zum Beispiel abgewertet, wenn das nicht der Fall ist. Wenn man schaut von was so in der Welt genutzt wird, ist ganz klar, JPEG ist ganz vorne mit dabei für Fotos und natürlich GIF-PNG. Andere Formate sind noch relativ unbekannt. SVG wird langsam mehr, dass immer wer bekannt wird, was man mit SVG machen kann. Natürlich auch wegen der Retina-Auflösung. Faktoreografische sind dann immer scharf dargestellt. Das heißt noch die Zukunft. Es ist die Frage von, wie viel kann man jetzt sparen, wenn man Bilder optimiert? Ich habe hier mal ein Beispielbild genommen. Es ist über 800 KB groß, wenn man das halt mit Standard JPEG Tools optimiert. Das ist das erste Teil. Dann kann man schon ein paar KB sparen, also über 100 KB. Bei JPEG ist es halt so, dass es zwei Methoden gibt, um ein Bild abzuspeichern. Das ist ein Baseline-Encoding. Das kann man sehen, wenn ein Bild geladen wird. Das sind für Zeile LED. Eine Alternative ist Progressive-Encoding. Das kann man auch sehen, wenn ein Bild geladen wird. Das ist erst total für Pixel. Dann wird dann immer schärfer. Bei JPEG ist es halt so, dass es progressiv speichern, wenn man das extra Datenvolumen spart. Die ganzen Diskussionen, neue Bildformate, Mozilla, die Hersteller von Firefox haben gesagt, wir machen da nicht mit. Die haben gesagt, wir nehmen die Standard JPEG Tools und versuchen die Tools nochmal zu optimieren. Das ist dann unter das Projektnamen JPEG jetzt zusammengeführt. Wenn man das benutzt, kann man da auch noch ein paar Kilo extra rausholen. In diesem Beispiel kann man 18 % sparen. Das ist alles ohne Qualitätsverlust. Ich schraube an die Qualität und versuche, die Dateigröße zu beeinflussen. So zwischen 75 und 85 % ist so. Was ganz okay ist, was jetzt bei WordPress Standard 82 % ist, also es ist da zwischendrin, kann natürlich auch noch sagen, ich kumpelt mir es noch stärker, 50 % nachtal ist, dass man das auch zieht. Aber man kann zum Beispiel 50 % nehmen, wenn man schwarz-weißbilder hat. Und da funktioniert es eigentlich ganz gut, weil man halt die Farben da nicht hat. Also da kann man noch mitspielen, wenn man schwarz-weißbilder hat. Man kann natürlich auch wegen Mobile sagen, ein großes Bild ist ja Quatsch, ich nehme ein kleineres Bild und da kann man eigentlich viel mehr sparen. 2012 hat jemand mal so alle großen Webseiten mal studiert, die responsive sind und damals festgestellt, dass responsiven Webseiten in der mobilen Ansicht genauso schwer sein wie die Desktop-Ansicht, ist natürlich schlecht, weil mobile und mobile Netzwerke langsamer sind. Da muss man dann was machen. Und daraus ist das responsive images Initiative entstanden und was jetzt auch aus HTML5 Standard verabschiedet wurde, und auch in WordPress 4.4 eingeführt wurde. In WordPress benutzt man das Source-Element, um die responses of images zu nutzen. Es gab auch neue Funktionen, um damit zu arbeiten. Eigentlich ist es so, dass WordPress Standards das macht. Wenn ein Team sich einen ganzen WordPress Standard hält, hat man auch automatisch responsive images, braucht man im Prinzip nicht zu viel zu machen. Da kann man noch bei dem Sizes-Attribut optimieren, weil WordPress halt nicht weiß, wie das Design aussieht. Was das Sizes-Attribut halt macht, ist, den Browser sagen, wie groß das Bild auf dem Bildschirm dargestellt wird. Hier oben kann man sehen, dass ich gesagt habe, bis 800 Pixel soll das Bild 100% des Viewports einnehmen. Also, VW ist kurzform für Viewport With. Es gibt noch VOH und Viewport Hive, aber das benutzt eigentlich keiner. Also, ich habe es noch nie irgendwo gesehen. Und als Fallback kann man sagen, von das Bild soll dann, wenn es halt nicht größer als 800 Pixel ist, dann 680 Pixel sein, in diesem Beispiel. Da kann man auch mehr media queries nutzen, abhängig von Design. Und da kann man halt die Bilder optimieren, abhängig von das Team, das man dann hat. Es gibt noch eine zweite Möglichkeit für responsive images, das ist halt übers Picture-Element. Da definiert man halt im Source-Element die media query. Das Picture-Element wurde explizit entwickelt, um Art Direction möglich zu machen. Das Source-Element ist eine Empfehlung für ein Browser. Aber der Browser entscheidet selber, welches Bild er dann tatsächlich nimmt. Und das erscheint anhand von der Pixel-Dichte, Größe des Bildschirms. Und es gibt auch die Möglichkeit, dass der Browser guckt, wie schnell die Verbindung ist. Zum Beispiel, wenn der Browser feststellt, ich habe eine langsam verbindung, dann nehme ich nicht die retina Auflösung, sondern die einfache Auflösung. Da ist der Browser frei. Bei Picture-Element ist es halt explizit definiert, und der Browser muss es dann so, die Bilder so nehmen, wie sie definiert sind. Das ist halt interessant, weil zum Beispiel hier in dem Foto hat man ein Hund vor einem Gebäude für das weiße Haus. Auf Mobile will man nicht einfach das ganze Bild kleiner machen, und dann erkennt man halt nicht, dann will man halt einen Ausschnitt nehmen und so beeinflusst, wie das Bild dargestellt wird. Das ist halt der Punkt vom Picture-Element, um das möglich zu machen. Natürlich bei WordPress gibt es ganz viele Blockins. Es ist immer ganz toll, dass man große Auswahl hat. Und ich will mal so ein paar Blockins erwähnen, die sinnvoll sind. Also das ewewewe Image Optimizer ist ein Tool, das dafür sorgt, wenn man ein Bild hochlegt, dass es automatisch optimiert wird. Es gibt auch die Möglichkeit, dass man JPEGs und PNGs in Wer-P-Format umwandelt, was halt WordPress-Standard nicht unterstützt. Nachteil von dem Blockin, dass man bestimmte Programme mitgeliefert werden, die auf der Kommando-Zeile ausgeführt werden müssen von PRP und nicht jeder Webhoster erlaubt das. Also muss man halt ausprobieren und wenn das Blockin irgendwie alles rot anzeigt, dann hat man halt... Also muss man halt ausprobieren, wie das funktioniert. Wenn es halt nicht geht, dann kann man halt noch auf eine Plange zurückgreifen, die bestimmte Webdienste nutzen. Heißt halt, dass das WordPress an ein Webdienst schickt und das optimierte Bild dann zurückkriegt. Hier ist zum Beispiel Kraken-IOS, die Kondensant aus Berlin. Optimus wurde von Sergey Mulder ursprünglich entwickelt. Aber man hat ja abgegeben, also wird noch immer unterstützt. Tiny-PNG ist auch so ein Dienst, was sehr beliebt ist und seit neuesten gibt es Image-Fly als Dienst. Das sind von den Leuten von WP Rocket. So kann man Kaspar mal fragen, wenn man da Interesse hat. Insanity ist ein praktisches Blockin, weil es ist halt so, man kann in WordPress Bilder hochladen und oft ist so, dass Redakteure oder Kunden halt irgendwie ein iPhone 6S haben oder ein Galaxy S7, wo halt hochauflösende Fotos mitgemacht werden, das direkt in WordPress hochladen. Dann hat man halt so Bilder, die 2, 3 MP groß sind oder noch größer. Und abhängig von, wie das Team gebaut ist, kann es halt sein, dass die Bilder in voller Größe dargestellt wird. Wenn zum Beispiel in Overlay das Bild dargestellt wird, dass dann die volle Größe geladen wird. Das kann man mit Insanity halt vermeiden und da kann man halt definieren, was die maximale Größe ist. Und damit ist es Standard bei 2.000 Pixel gemacht. Hat auch den Vorteil, wenn man nicht so teures Webhosting hat und irgendwie nur 100 MB Speicherplatz zur Verfügung hat, dass es auch nicht so schnell ausgereist wird. Yeah, regenerate Thumbnails werden wahrscheinlich die meisten kennen. Es ist halt, wenn man irgendwie Einstellungen, Vorschaubildern gemacht hat, kann man die Bilder neu generieren lassen. Bei WordPress ist es so, wenn man ein Bild hochlädt, wird automatisch mehrere Auflösungen gespeichert. Natürlich, jetzt ist mit WordPress 4.5 die Einstellungen noch mal optimiert. Kann man regenerate Thumbnails noch mal drüberlaufen lassen, dass man auch die neuen Einstellungen kriegt. Andere Technik ist Lazy-Loading. Das ist, wenn man ganz viele Bilder hat. Das sorgt dafür, dass das Bild erst geladen wird, wenn es in den sichtbaren Bereich kommt. Es ist halt interessant, wenn man, insbesondere auf der mobilen Ansicht, bei WordPress ist es standard, die letzten 10-arten Blockposts werden auf der Startseite angezeigt, aber nicht jeder scrollt bis zum letzten Blockpost auf der Startseite runter. Und damit mit Lazy-Loading vermeidet man, dass die Bilder alle geladen wird, wenn der Besucher nicht ganz nach unten scrollt. Und das ist halt schade, wenn Bilder geladen werden, die ein Besucher nie gesehen hat. Aber er hat trotzdem Daten verbraucht. Ja, Eigenfonds blieb das Thema, oder blieb das Technik. Das macht man, damit man halt mehrere Bilder in den Fund steckt. Beim Webbrowser ist es halt so, dass das Anzahl der HTTP-Request eingeschränkt ist. Die Browser können maximal 6, hat die HTTP-Request absenden. Und wenn man natürlich dann Javascript noch hat und CSS-Dateien wird die Webseite langsamer, weil er halt die 6-Request abarbeiten muss, und dann kann er die nächsten 6 abarbeiten. Und mit Eigenfonds kann man halt mehrere Eigens nehmen, in eine Datei zusammenpacken und durch Request sparen. Problemen nur bei Eigenfonds ist, dass zum Beispiel Leute, die in Leserstörungen haben, gerne Eigenfonds definieren und damit den Eigenfonds abschalten, sozusagen, und die Eigens dadurch kaputtgehen. Und jetzt ist halt auch so, dass im iOS 9 zum Beispiel und auch bei manchen Adblocker, die von uns auch blockiert werden, und dann kriegt man auch als auch komperter, eher kaputter Eigens. Und Opera Mini ist halt ein mobiler Browser, was in Deutschland nicht ganz so viel genutzt wird, aber in Afrika und Asien ist es blieb, dass da auf den Handys eigentlich der Standardbrowser, und das unterstützt die Eigens von uns gar nicht, und das werden sie in Zukunft auch nicht machen. Also wenn man in den Markten unterwegs ist, ist das schon ein wichtiger Punkt. Natürlich, Eigenfonds ist ganz praktisch, aber wenn man es meistens nicht nutzen kann, dann kann man noch eine Alternative nutzen, das SVG Sprites, was halt unterschiedliche SVGs nimmt, das ist halt in einen großen SVG kombiniert. Muss man natürlich von Anfang an als SVG haben, damit man das nutzen kann. Ein gutes Tool ist iCommun, was ursprünglich für Eigenfonds gedacht wird. Die haben halt die Option, dass man es auch als SVG speichern kann. Natürlich, wenn man es selber macht, hat Joschi Kuhfall ein Skript geschrieben, dass man uns in welchen SVGs uns breit macht, kommt zufällig aus Nürnberg. Also das ist praktisch, wenn man halt mehrere SVGs, dann lässt man das Skript drauflaufen und dann kriegt man ein Komplettpaket mit CSS zurück. Animierte Gifts sind ziemlich beliebt. Hier ist ein Beispiel von der Washington Post, wo sie halt im Artikel GIF genutzt haben. Das Problem ist, dieser Teil ist 4,3 mb groß. Da kann man noch WebP nehmen, weil die auch Animationen unterstützt. Dann ist man bei 3,3 mb. Hätten sie jetzt einfach in Videoformat mp4 genommen, wäre es nur 143 Kilo weit groß gewesen, also ein Unterschied von 300. Deswegen will ich sagen, GIF-Animation muss man nicht unbedingt benutzen. Da ist Video besser. Mit HTML5 haben wir ja das Videotech und da gibt es das Autoplay-Attribut. Da kann man als gute Alternative benutzen. Es ist natürlich für ältere Browser, die HTML5 nicht unterstützen, geht das nicht. Dann würde ich sagen, das ist einfach ein statisches Bild. Das betrifft eigentlich nur den IE8. Das ist der beste Kompromiss, das an allen Browser 4,3 mb große GIF zu schicken. HATIDB2 hat vielleicht ein paar andere schon mal gehört. Das wurde explizit entwickelt, um das ganze HATIDB-Protokoll nochmal zu beginnen auf Performance. Da gibt es halt so ein paar Änderungen, die Best-Practices oder Techniken, die man genutzt hat, eigentlich ungültig machen. Ein Beispiel ist Spriting. HATIDB2 ist so, dass keine Obergrenze gestellt ist, wie viel Request abgesendet werden. Heißt, wenn man mehrere Requests gleichzeitig abzenden kann, dann hat das Spriting nicht mehr so viel Sinn. Dann kann man viele kleine Dateien schicken, und das geht alles parallel. HATIDB2 hat auch den Vorteil, wenn man Spriting nutzt, hat man eine Datei, und wenn in der Datei eine kleine Änderung ist, muss man die komplette Datei wieder neu runterladen. Wenn man viele kleine Dateien, ist es nur eine kleine Datei, die sich dann ändert. Inlining macht man auch, hat man früher auch gerne gemacht. Es ist natürlich kompliziert, dass man Sachen in HATIDB1 einbettet. Bei HATIDB2 kann man Server Push machen, was das komplett ersetzt. Das ist natürlich so ein Ding, etwas Technisches, um das einzusetzen, was man definieren muss. Aber es kann sich schon lohnen, wenn man HATIDB2 nutzen kann, um das mal näher anzuschauen. Was man auch im Moment gerne macht, ist Domainschading. Das hat man halt gemacht, weil es nur sechs HATIDB-Requests pro Domain erlaubt sind. Dann nehmen wir halt mehr Domains. Wenn wir zwei Domains haben, kann man halt 2x6. HATIDB12 hat die TBA-Requests. HATIDB2 ist ein Nachteil, weil HATIDB2 ist ein Protokoll, womit der Browser und der Server kommunizieren, auch Prioritäten feststellen können und den ganzen Verkehr automatisch automatisch optimieren können. Das geht halt verloren, wenn man auf mehrere Domains verteilt. Auch im Nachteil, wenn man mehrere Domains hat, man muss noch ein DNS-Request extra absetzen. Für jede Domain, was auch Zeit braucht. Das ist das falsche Bild. Eine Unterstützung für HATIDB ist ganz gut. Alle modernen Browser-Unterschützen, das ist eigentlich nur der IE, der es nicht unterstützt. Also daher, wenn es einen Web-Hoster anbietet, sollte man das auch nutzen. Hier ist ein Demo von CDN-Anbieter, zeigt halt Unterschied zwischen HATIDB1 und HATIDB2. Da sieht man, dass es 5-mal schneller mit HATIDB2. Das ist halt ein Bild, das aufgeteilt wurde in 200 kleinere Bilder. Da sieht man, was es halt bringen kann, wenn man viele kleine Bilder nutzt oder ganz viele kleine Dateien hat, weil es gilt auch für CSS und ja, was krebt. Das ist eigentlich auch, was ich erzählen wollte. Ich hoffe, dass ihr euch was gebracht habt und neue Ideen und Tools zur Verfügung stellt und ihr das auch nutzen könnt. Ich wollte mich hier nicht bedanken fürs Zuhören. Gibt es Fragen? Die Frage war, wie ich zu EXIF-Informationen stehe. EXIF-Informationen sind halt die ganzen Metadaten. Ich würde diese rausfiltern. Bei den meisten Seiten ist es nicht relevant. Aus meiner Sicht ist es nur, wenn man so eine Fotoseite hat. Dann würde ich sagen, dann will man sie halt trennen haben und die Originale aufbewahren. Ich kann natürlich auch sagen, dass man die in die Tomp-Nails, das EXIF-Daten raus irgendwie das Original verlinkt. EXIF-Daten sind halt nur interessant für Leute, die mehr Informationen über das Fotomaterial haben wollen. Für ein Browser ist das nicht relevant. Da muss man natürlich immer gucken, ist man an den Daten interessiert oder nicht? Okay. Daher kann man natürlich so dann einstellen, dass man beim Hochladen die EXIF-Daten halt speichert und das WordPress das optimieren lässt. Wenn es schon in der Mediathek ist, dass die Daten halt schon abgespeichert sind und danach die EXIF-Daten entfernt. Aber man muss natürlich gucken, ob man das so will. Das ist unterschiedlich. Ja. Bei iOS und Android funktioniert das nicht. Das macht aus meiner Sicht auch Sinn. Man will nicht automatisch ein Video auf Mobile abgespielt. Es ist halt so bei, zum Beispiel, Firefox auf Android unterstützt es und Windows Phone unterstützt es auch und Blackberry unterstützt es auch. Das muss man sich überlegen. Da muss man vielleicht explizit sagen, von auf Mobile nicht. Da muss man da halt mit Javascript noch arbeiten. Das ist natürlich die Frage, wie man das Handhaben will. Das muss man halt sich überlegen, wie wichtig das einem ist. Und wenn man sagt, ich will auf Retina immer die Retina-Auflösung, dann muss man halt das mit dem Picture-Element arbeiten. Bei WordPress ist es halt so, dass der Source-Element nimmt und einfach den Browser sagt, in welche Auflösung die Bilder zur Verfügung steht und der Browser entscheidet dann selber, was irgendwie Sinn macht. Was für mich persönlich ein guter Weg ist, natürlich, wenn der Kunde sagt von Retina, das soll hochauflösend sein, dann hat man halt den Achtel, dass das Bild auch viermal so groß ist und dass es halt auf die Performance schlägt. Dann ist es halt die Frage, was ist wichtig an die Performance oder dass es irgendwie scharf aussieht. Muss der Kunde halt dann entscheiden? Okay, keine Fragen mehr. Vielen Dank.