Ich habe kürzlich darüber geschrieben, wie schwierig Bilder sind (images are hard) und es entwickelte sich zu einer großen Checkliste mit Dingen, die man beim Platzieren von Bildern auf Websites bedenken und implementieren könnte/sollte.
Ich finde es ermutigend zu sehen, dass Frameworks – diese beliebten Werkzeuge, die wir zum Erstellen von Websites nutzen – zusätzliche Werkzeuge innerhalb von sich anbieten, um diese Checkliste zu bearbeiten und die schwierigen (aber für Computer perfekt geeigneten) Aufgaben der Bildanzeige zu übernehmen.
Einige Beispiele
Ich bin mir nicht sicher, ob ich einem von ihnen in Bezug auf die Benutzerfreundlichkeit Bestnoten geben würde. Es gibt Dinge zu installieren, zu konfigurieren, und es ist wahrscheinlich, dass man sich nur dann damit beschäftigt, wenn man bereits weiß, dass man es tun sollte, und das vorhandene Wissen über Bildleistung einem dabei helfen kann. Das ist kein Versäumnis dieser Frameworks; diese Dinge sind kompliziert und die Zielgruppe sind Entwickler, die, wenn man ehrlich ist, eine gewisse Vorliebe für Kontrolle haben.
Ich muss meinem BFF WordPress hier zustimmen. Man tut buchstäblich nichts und bekommt responsives Bildmaterial direkt aus der Box. Wenn man die Filter nutzen muss, um Dinge zu steuern, kann man das tun, wie man alles andere in WordPress kann: über Hooks. Wenn man sich für Jetpack entscheidet (und ich empfehle es Ihnen wärmstens), schaltet man die (unglaublich, kostenlose) Site Accelerator-Funktion ein, die all diese Bilder nimmt, optimiert, über CDN hostet, lazy-loaded lädt und sie in Formaten wie WebP ausliefert, wenn möglich (ich nehme an, es werden schließlich weitere Next-Gen-Formate hinzukommen). Jetpack ist ein Sponsor, also volle Transparenz hier, aber ich benutze es sehr bewusst, weil die Erfahrung die Bildverarbeitung zu etwas macht, über das ich buchstäblich nicht nachdenken muss.
Ein weiterer interessanter Aspekt von Frameworks, die bei Bildern helfen, ist, dass ein Teil davon aus Googles Engagement entstanden ist. Google nennt es „Aurora“
Seit fast zwei Jahren arbeiten wir mit einigen der beliebtesten Frameworks wie Next.js, Nuxt und Angular zusammen, um die Web-Performance zu verbessern.
Das Projekt macht allerhand, darunter Geldzahlungen zur Finanzierung von Open-Source-Tools und direkte Unterstützung spezifischer Initiativen. Wie eben Bilder
Eine Bildkomponente in Next.js, die Best Practices für das Laden von Bildern verkörpert, gefolgt von einer Zusammenarbeit mit Nuxt an derselben Sache. Die Verwendung dieser Komponente hat zu signifikanten Verbesserungen der Ladezeiten und Layout-Verschiebungen geführt (Beispiel: 57% Reduzierung des Largest Contentful Paint und 100% Reduzierung des Cumulative Layout Shift auf nextjs.org/give).
Cool, oder? Ich finde schon? Was mich daran ein wenig verwirrt, ist, dass es sich bedeutsam anfühlt, wenn Googles Team auftaucht, um zu einem Framework beizutragen. Sie haben sich nicht für Außenseiter-Frameworks entschieden, sicherlich mit Absicht, weil sie wollen, dass ihre Arbeit die meisten Menschen beeinflusst. Also profitieren bereits erfolgreiche Frameworks von Beiträgen der A-Liga. Eine Situation, in der die Reichen noch reicher werden. Ich bin mir nicht sicher, ob das ein großes Problem ist, aber es ist einfach etwas, worüber ich nachdenke.
Einführung
Ich weiß nichts über Gatsby und Eleventy Bildkomponenten, aber zu NextJs kann ich meinen Senf dazugeben.
Erstens denke ich, dass NextJs großartige Arbeit geleistet hat, um Bilder für alle zugänglich zu machen. Sie haben wirklich die Grenzen verschoben und praktisch jeder Junior-Entwickler ohne jegliche Erfahrung kann es schnell erlernen.
Nachteile
Mit diesem gesagt, gibt es auch viele Nachteile mit dieser Komponente.
Das idiotensichere Design mag für Anfänger großartig sein, aber es entwickelt sich darüber hinaus nicht weiter.
Der Artikel erwähnte, dass Entwickler gerne die Kontrolle haben möchten, aber dafür gibt es Gründe…
Riesiger DOM-Bloat
Jedes Bild hat 2 Wrapper. Das bedeutet, wenn Sie 20 Bilder auf Ihrer Seite haben, verwenden Sie bereits 60 DOM-Knoten. Das ist wirklich nicht effizient, man könnte das gleiche Ergebnis leicht mit nur einem Wrapper erzielen.
Styling-Entscheidungen:
!importantoder mehr DOM-BloatDie NextJs-Bildkomponente gibt Ihnen keinen Zugriff auf ihren äußeren Wrapper, Sie steuern nur das
<img>-Tag.Um Ihrem Leben etwas Würze zu verleihen, verwendet sie auch Inline-Styles…
Wenn Sie nicht die nukleare Option
!importantmit einem zerbrechlichen CSS-Selektor verwenden möchten, der leicht brechen kann, wenn Sie etwas auf Ihrer Seite ändern, ist der einzige Weg, Ihr Bild richtig zu stylen, einen zusätzlichen Wrapper darüber zu legen.Nach dem vorherigen Beispiel werden aus den 20 Bildern jetzt 60 bis 80 DOM-Knoten…
Das sind 3 Wrapper pro Bild, obwohl Sie das exakt gleiche Ergebnis mit nur einem Wrapper erzielen könnten.
Und diese Inline-Styles, Sie können das exakt gleiche Ergebnis bei 95%+ der Browser erzielen, indem Sie 77% davon deaktivieren…
Inline-Styles = CSP-Kopfschmerzen
Wenn Sie eine sichere Content Security Policy (CSP) einbeziehen möchten, können Sie das vergessen. Die Inline-Styles stehen in direktem Gegensatz zur Sicherheit.
Entweder senken Sie Ihre Sicherheitsanforderungen, indem Sie
inline-unsafeverwenden, oder Sie schauen sich anderswo um.Bildoptimierung auf großen Bildschirmen
Standardmäßig basiert die Bildoptimierung auf dem Viewport.
Das funktioniert erstaunlich gut für Mobilgeräte, Sie können einfach ein 4K-Bild als Quelle nehmen und es wird für den Viewport des Benutzers optimiert. Dies bedeutet enorme Einsparungen bei der Optimierung.
Aber wenn es auf Desktops angewendet wird, versagt die Lösung. Dieses 4K-Bild wird immer noch für Ihren Viewport optimiert, nicht für seine tatsächliche Größe auf dem Bildschirm…
Wenn Ihr Viewport also 2560 Pixel beträgt, Sie aber ein 600 Pixel breites Bild haben wollten, liefert die Optimierung dem Browser ein für 2560 Pixel optimiertes Bild (von 4K) und der Browser skaliert es auf 600 Pixel herunter, um die von Ihnen angegebene Breite zu erreichen.
Das ist ein riesiges Versäumnis, die übertragene Datenmenge ist viel höher als nötig. Mit 4K-Bildschirmen ist es noch schlimmer.
Caching-Mechanismus auf dem Client
Um fair zu sein, hat NextJs in Version 11.0 eine
import-Methode für Bilder hinzugefügt, die den Zustand der Dinge erheblich verbessert hat.Die neue
import-Methode fügt automatisch einencache-control-Header mitimmutablezu Ihren Bildern hinzu und fügt einen Hash zum Namen hinzu. Mit dieser Änderung pingen Benutzer Ihren Server nicht jedes Mal an, wenn sie die Seite neu laden, um zu sehen, ob das Bild noch das neueste ist.Aber selbst mit der neuen Methode gibt es Fehler
Was passiert, wenn Ihre Bilder von Benutzern bereitgestellt werden?
Was passiert, wenn Ihr Inhalt in Markdown vorliegt?
Tja, Pech gehabt! Sie müssen die alte Methode der Bildnutzung verwenden, nämlich das Übergeben eines Strings mit dem Pfad des Bildes an die Komponente.
Die alte Methode erlaubt es Ihnen nicht, Ihren Caching-Mechanismus zu wählen. Sie sind auf ein 60-Sekunden-Caching beschränkt, und das war's. Danach ist jeder Reload ein Ping an den Server. Zugegeben, es ist nur ein Etag-Check, aber es ist immer noch eine Netzwerkanfrage, die mindestens 40 ms Latenz verursacht.
Mit der alten Methode sind Sie auch der serverseitigen Neuberechnung Ihrer Bilder "on the fly" unterworfen, was bis zu 3 Sekunden Verzögerung verursachen kann.
Caching-Mechanismus auf dem Server
Auch das ist eine interessante Sache: Die optimierten Bilder werden nur 60 Sekunden lang auf dem Server gespeichert.
Nach 60 Sekunden wird NextJs Ihr Bild bei der nächsten Anfrage neu optimieren. Das kann zwischen 200 ms und 3000 ms dauern. Ja, 3 Sekunden, das ist kein Tippfehler.
Es spielt keine Rolle, ob sich Ihr Bild geändert hat oder nicht, NextJs wird es neu optimieren.
Die Bildoptimierung verwendet eine AWS Serverless Function, die aus Ihrem eigenen NextJs-Konto ausgeführt wird.
Obwohl es sehr sicher ist, die Bilder so zu trennen, dass jede Website getrennt ist, ist es immer noch eine Serverless Function, die bei gutem Traffic jede einzelne Minute ausgeführt wird.
Multiplizieren Sie das mit Hunderttausenden von Websites, und Sie erhalten eine riesige Ressourcenverschwendung, sie werden sicherlich nicht bald einen grünen Preis gewinnen…
Und wenn Sie diese 60-Sekunden-Caching-Strategie ändern wollen?
Nun, bis vor kurzem konnten Sie das nicht. Diese Option, die ich noch nicht testen konnte, wurde nach unzähligen Beschwerden über mehr als 8 Monate hinzugefügt.
Fazit
Es ist wichtig, die Leute daran zu erinnern, dass diese Frameworks viel Gutes für Unbedarfte tun.
Aber es ist auch fair zu sagen, dass sie nicht genug tun. Die von mir aufgeführten Probleme sind nur die, auf die ich gestoßen bin, es gibt noch andere…
Es ist ein sehr kompliziertes Thema und Frameworks wie NextJs helfen sehr, die einfachen Erfolge zu erzielen. Selbst nach all meinem Gerede verbessert ihre Lösung die Gesamtsituation immer noch.
Mein Punkt ist eher, dass wir als Entwickler ein gewisses Maß an Kontrolle über diese Lösungen haben müssen. Die Aufgabe dieser Frameworks ist es, Ihnen die besten Standardeinstellungen zu geben, oder was sie dafür halten, mit vielen Griffen, um sie an unsere Situation anzupassen.
Das sind hilfreiche Informationen, danke fürs Teilen!