Responsive Websites zur Leistung bringen
Es gab eine Zeit, in der Sie sicher zwischen einer Desktop-Webseite und einer mobilen Webseite unterscheiden konnten. So sehr, dass eine ganze Branche um die Umnutzung von Desktop-Sites für Mobilgeräte herum entstand.
Eine Zeit lang waren Sie niemand, wenn Sie keine separate mobile Website auf einer separaten Domain hatten. Dann begannen sich die Dinge zu ändern.
Mobile Displays wurden bis zur Unkenntlichkeit verbessert. So auch mobile Browser. Tablets warf ein weiteres Element in die Gleichung. 4G kam hinzu. Retina-Displays boten Endnutzern ein neues Maß an Klarheit.
Plötzlich war die Grenze zwischen Desktop und Mobilgerät verschwommen.
Gleichzeitig gab es eine wachsende Vielfalt in der Größe und Auflösung von Desktop-Displays.
Und ein wachsendes Kopfzerbrechen für Webdesigner.
Vorbei sind die Zeiten, in denen Sie nur eine Handvoll Viewport-Größen berücksichtigen mussten. Die Dinge wurden kompliziert.
Glücklicherweise gab es Abhilfe in Form von Medienanfragen und dem Konzept des responsiven Designs.
Dank Medienabfragen wurde es möglich, Stile und Layout – sogar Inhalte – je nach Ansichtsfensterbreite und Bildschirmauflösung des Benutzers zu variieren. Natürlich sind Media Queries bei weitem nicht das einzige Werkzeug in der Trickkiste des Responsive Designers, aber man kann durchaus sagen, dass sie die Grundlage der Technik bilden.
Das waren großartige Neuigkeiten für Mobilgeräte. Responsive Design bedeutete, dass Sie verschiedene Versionen derselben Website effektiv auf verschiedenen Geräten bereitstellen konnten. Und das alles, ohne eine separate mobile Website auf einer anderen Domain zu entwickeln.
Was ist mit der Leistung?
Website-Eigentümer beginnen zu erkennen, dass sich Endbenutzer um die Leistung kümmern. Insbesondere Einzelhändler beginnen zu erkennen, dass das Einsparen von Millisekunden ohne Ladezeit zu Millionen in der Bilanz führen kann.
Glücklicherweise bieten responsive Websites einen klaren Leistungsvorteil gegenüber ihren dedizierten mobilen Cousins: Die Weiterleitung zu einer mobilen Domain entfällt.
Trotzdem hat es Responsive Design geschafft, sich einen gewissen Ruf für schlechte Leistung zu erwerben.
In gewisser Weise ist das ziemlich unfair, aber es lohnt sich, einen Blick auf die zusätzlichen Leistungsherausforderungen zu werfen, die reaktionsschnelles Design für Unvorsichtige mit sich bringt …
Bilder
Bilddateien sind groß. Und weil sie groß sind, sind sie oft für langsame Ladezeiten verantwortlich. Sie sind daher ein guter Ausgangspunkt für alle, die versuchen, die Leistung einer Website zu optimieren.
Leider war eine der ersten Lösungen zur reaktionsschnellen Bereitstellung von Bildern nicht besonders leistungsfähig.
Die Technik ist wunderbar einfach. Verwenden Sie einfach max-width: 100%, um sicherzustellen, dass Bilder auf die Breite des enthaltenden Elements skaliert werden:
img
{
max-width: 100%;
}Wenn der Container verkleinert wird, um sich an kleinere Ansichtsfenster anzupassen, werden alle darin enthaltenen Bilder mit verkleinert. Einfach!
Aber es gibt ein Problem. Die Größe des Bildes kann auf dem Bildschirm schrumpfen, aber die Größe der Datei bleibt gleich. Dies ist aus Performance-Sicht alles andere als ideal. Sie könnten ein Bild mit 800 x 800 Pixeln über die Leitung senden, nur damit es mit 80 x 80 Pixeln angezeigt wird: Mit anderen Worten, Sie könnten Hunderte (oder Tausende) unnötiger Bytes übertragen. Das Laden des Bildes dauert nicht nur sehr lange, all diese redundanten Bytes könnten das wertvolle Datenvolumen des Endbenutzers aufbrauchen.
Dies ist jedoch nicht der einzige – und nicht einmal der beste – Weg, responsive Bilder zu liefern. Zum einen funktioniert ein Bild, das mit einer Breite von 800 Pixeln funktioniert, nicht unbedingt so gut mit verschiedenen Bruchteilen dieser Größe.
Um dies zu umgehen, können Sie eine Medienabfrage verwenden, um je nach Größe des Darstellungsbereichs verschiedene Versionen des Bildes anzuzeigen, indem Sie eine Medienabfrage verwenden und Folgendes anzeigen: keine.
CSS:
@media (min-width: 601px) {
#croppedImage
{
display:none;
}
}
@media (max-width: 600px) {
#largeImage
{
display:none;
}
}HTML:
<img id="largeImage" width="400" height="400" alt="" src="images/largeImage.webp">
<img id="croppedImage" width="200" height="200" alt="" src="images/croppedImage.webp">Auf diese Weise können Sie verschiedene Versionen eines Bildes anzeigen, anstatt nur dasselbe Bild in unterschiedlichen Größen. Die Anzahl der Bytes wird jedoch nicht verringert. Tatsächlich wird die Gesamtseitengröße größer, da alle Bilder geladen werden, unabhängig davon, ob sie angezeigt werden oder nicht.
Eine bessere Alternative – wenn es praktisch ist – ist die Verwendung von Hintergrundbildern <divs>anstelle von <img>Elementen. Dies ist vorzuziehen, da Bilder, auf die in CSS verwiesen wird, nur geladen werden, wenn sie verwendet werden (solange es sich nicht um Daten-URIs handelt):
@media (min-width: 601px) {
#largeImage
{
width:400px;
height:400px;
background-image:url(/images/largeImage.webp);
}
#croppedImage
{
display:none;
}
}
@media (max-width: 600px) {
#croppedImage
{
width:200px;
height:200px;
background-image:url(/images/croppedImage.webp);
}
#largeImage
{
display:none;
}
}Das funktioniert gut: Besucher laden nur die Bilder herunter, die sie benötigen, wann immer sie sie brauchen. Das Problem ist, dass es unordentlich ist und Inhalte effektiv als Stil behandelt. Als solches führt dies möglicherweise zu einem Wartbarkeitsproblem und kann auch dazu führen, dass wichtige Bilder von Suchmaschinen ignoriert werden.
Warum verwenden Sie stattdessen nicht SVG (skalierbare Vektorgrafiken): ein Bildformat, das von Natur aus skalierbar ist? SVG-Bilder haben auch den Vorteil, dass sie einfach mit CSS gestaltet werden können (siehe dieses großartige Tutorial, wie man SVGs mit CSS responsive macht). Das ist perfekt für Icons und Logos, aber leider können Sie SVGs nicht für Fotos verwenden – für diese müssen Sie auf Rasterformate wie JPEG zurückgreifen.
Eine weitere Option besteht darin, eine von mehreren JavaScript-Lösungen zu verwenden, um responsive Bilder bereitzustellen. Dies ist eine beliebte Methode, fügt jedoch eine weitere Ebene der Komplexität hinzu. Da JavaScript die DOM-Konstruktion blockiert, kann außerdem jede Lösung, die JavaScript verwendet, das Rendering aufhalten. Obwohl es einige sehr clevere Plugins gibt, geben Sie sich durch die Einführung von JavaScript in die Gleichung bis zu einem gewissen Grad mit dem kleineren von zwei Übeln ab.
Bis vor kurzem waren dies die einzigen Optionen.
Jetzt jedoch bringen die Elemente <picture>und und die Attribute srcset und size endlich wirklich reaktionsschnelle Bilder ins Web. <source>Die neue Spezifikation beginnt auch, Browserunterstützung zu erhalten, mit vollständiger Unterstützung in Chrome und Opera und Unterstützung für die Auflösungsumschaltung in Safari. Bis andere Browser aufholen, gibt es ein ausgezeichnetes JavaScript- Polyfill.
In dieser schönen neuen Welt können Sie mit srcset eine Liste mit Kandidatenbildern erstellen, aus der der Browser auswählen kann. Sie können dann eine Medienabfrage im Größenattribut verwenden, um die Größe festzulegen, in der das Bild angezeigt wird. Wenn Sie das <picture>Element zusammen mit Medienabfragen innerhalb eines oder mehrerer Elemente verwenden, können Sie einen unterschiedlichen Bereich von Bildern für unterschiedliche Bedingungen angeben (z. B. für Darstellungsfenster bis zu einer bestimmten Breite Bild a, b oder c verwenden und für größere Darstellungsfenster Bild verwenden x, y oder z). Dies ist nützlich, wenn Sie eine zugeschnittene Version eines Bildes für Benutzer mit kleinen Bildschirmen bereitstellen müssen.
Die genauen Details zur Verwendung der neuen Syntax würden den Rahmen dieses Artikels sprengen, aber Sie finden ein ausgezeichnetes Tutorial bei alistapart.
Der vielleicht einzige Nachteil dieser neuen Spezifikation ist, dass sie ziemlich langatmig ist, was auf Seiten mit vielen Bildern zu aufgeblähtem HTML führen kann. Allerdings überwiegen die Vorteile bei weitem die Nachteile.
Laden von CSS, das Sie (unbedingt) nicht benötigen
Obwohl Sie mit Medienabfragen je nach den von Ihnen festgelegten Kriterien unterschiedliche CSS-Regeln anwenden können, kommt man nicht umhin, dass Endbenutzer alle CSS herunterladen müssen, die möglicherweise zutreffen. Dies gilt auch dann, wenn Sie Ihr CSS in separaten Dateien ablegen und Ihre Medienabfrage im <link>Element platzieren.
Beispielsweise werden die beiden folgenden Stylesheets geladen, unabhängig von der Breite des Ansichtsfensters:
<link rel="stylesheet" media="(max-width: 600px)" href="css/style1.css">
<link rel="stylesheet" media="(min-width: 601px)" href="css/style2.css">Dies ist kein Browserfehler. Die Kriterien, die in Medienanfragen verwendet werden, beziehen sich häufig auf Dinge, die sich während eines Besuchs auf einer Seite ändern. Beispielsweise kann ein Besucher entscheiden, die Größe des Browserfensters zu ändern oder sein Tablet/Mobilgerät zu drehen. Die resultierende Änderung der Anzeige sollte nahtlos sein, und das Auslösen einer Anfrage nach einer anderen CSS-Datei wäre alles andere als ideal. Dies gilt insbesondere für mobile Geräte, die versuchen, Funkverbindungen so früh wie möglich zu schließen, um Batterieleistung zu sparen. Möglicherweise muss diese Verbindung erneut hergestellt werden, wenn sich die Größe des Ansichtsfensters ändert, was eine schlechte Nachricht für die Akkulaufzeit sein könnte.
Chrome bemüht sich jedoch, auf intelligente Weise mit diesen unterschiedlichen Dateien umzugehen. Während alle Dateien heruntergeladen werden, blockiert nur die mit der aktuell übereinstimmenden Medienabfrage das Rendern. Alle anderen werden mit niedrigerer Priorität geladen.
Leider sind andere Browser nicht ganz so kulant. In Firefox zum Beispiel blockieren ungenutzte CSS-Dateien nicht nur das Rendern, sondern auch das Laden anderer Objekte auf der Seite.
Das folgende Wasserfalldiagramm veranschaulicht diesen Punkt. Die Bilder auf dieser Seite werden erst geladen, wenn die unbenutzte CSS-Datei vollständig heruntergeladen wurde:
Sie können dies umgehen, indem Sie JavaScript verwenden, um CSS bedingt zu laden, aber wie wir bereits gesehen haben, bringt JavaScript seine eigenen Leistungseinbußen mit sich.
Was bedeutet das alles für die Leistung einer responsiven Website im Vergleich zu einer mobilen Website?
Nun, mobile Benutzer und Desktop-Benutzer auf einer responsiven Website müssen dasselbe CSS herunterladen.
Und es wird mehr davon geben als auf einer Website, die nur für Desktop- oder Mobilgeräte konzipiert ist.
Darüber hinaus verwendet eine dedizierte mobile Website mit größerer Wahrscheinlichkeit eine leichtere, abgespeckte Version des Desktop-CSS (obwohl dies jetzt vielleicht weniger zutrifft, da Benutzer zunehmend ein reichhaltigeres Erlebnis auf immer ausgefeilteren mobilen Displays erwarten).
Unter sonst gleichen Bedingungen sieht es so aus, als ob etwas in dem Argument steckt, dass eine responsive Website wahrscheinlich langsamer ist als eine mobile Website, weil zusätzliches CSS erforderlich ist. Solange Designer sich jedoch der potenziellen Fallstricke bewusst sind, sollten sie in der Lage sein, schnell ladende Stylesheets für eine responsive Website zu erstellen. Insbesondere ist es eine gute Idee:
- Vermeiden Sie die Verwendung von Daten-URIs für Bilder – binäre Hintergrundbilder werden (normalerweise) nur geladen, wenn/wenn sie benötigt werden, aber alle Daten-URIs werden trotzdem geladen.
- Halten Sie es leicht – da alle CSS heruntergeladen werden müssen, ist es wichtig, effizient zu sein. Das bedeutet, Duplikate zu vermeiden und sicherzustellen, dass globale Regeln außerhalb des von Medienanfragen gesteuerten CSS festgelegt werden.
RESS (Responsive Webdesign + serverseitige Komponenten)
RESS ist eine Mischung aus reaktionsschnellem und adaptivem Design, bei dem Benutzeragenten auf dem Server schnüffeln, um die Eigenschaften des Clientgeräts zu untersuchen und dafür geeignete Inhalte bereitzustellen.
Wenn einer der Einwände gegen responsives Design darin besteht, dass alle Inhalte auf allen Geräten bereitgestellt werden müssen, warum sollten Sie dem nicht entgegenwirken, indem Sie einige dieser Inhalte ausschließen, wo Sie können?
Das kann viel Sinn machen. Wenn es ein Bild gibt, von dem Sie wissen, dass Sie es niemals auf Geräten anzeigen möchten, deren Bildschirm kleiner als eine bestimmte Größe ist, können Sie es genauso gut nicht an diese Geräte senden, um Bandbreite und Ladezeit zu sparen.
Wenn Sie außerdem Medienabfragen verwenden, von denen Sie wissen, dass sie auf bestimmten Geräten möglicherweise nicht erfüllt werden können, gibt es zumindest ein Argument dafür, Ihr CSS in verschiedene Dateien aufzuteilen und diese bedingt zu laden.
Es ist wichtig zu bedenken, dass dieser gesamte Prozess in Bezug auf die Leistung nicht „kostenlos” ist. Einige Arbeiten müssen natürlich auf dem Server durchgeführt werden, was Zeit in Anspruch nimmt – wahrscheinlich nicht genug, um die Vorteile aufzuwiegen, aber es ist etwas, dessen man sich bewusst sein sollte.
Das Urteil
Sind responsive Websites langsam?
Es kommt darauf an, was man unter langsam versteht.
Ist die am schnellsten reagierende Website, die Sie erstellen könnten, wahrscheinlich langsamer als die schnellste dedizierte mobile Website, die Sie erstellen könnten?
Wahrscheinlich.
Wir haben auch gesehen, dass es ein paar Fallstricke gibt. Wenn Sie nicht aufpassen, ist es leicht, Benutzer dazu zu zwingen, viele redundante Bilder und CSS herunterzuladen, wodurch Ihre reaktionsschnelle Website viel langsamer wird, als sie sein müsste.
Es muss jedoch nicht so sein. Es ist durchaus möglich, eine reaktionsschnelle Website zu erstellen, die genauso schnell ist, wie sie sein muss, und eine hervorragende Benutzererfahrung bietet. Und da sowohl Standards als auch Browser beginnen, mit dem Schritt zu halten, was Entwickler liefern wollen, sollte es einfacher werden.