Responsive Content ist Overengineering

von Henry Zeitler

Responsive Web Design stellt den Content einer Website auf allen erdenklichen Endgeräten in einer konsumierbaren Form dar ohne ihn zu verändern. So lautet die Definition. Aber reicht die responsive Darstellung des Contents aus um den Ansprüchen auf z.B. mobilen Devices in Hinblick auf Performance und Konsumierbarkeit gerecht zu werden oder sollte auch der Content selbst optimiert ausgeliefert werden?

Responsive Inhalte für responsive Seiten

Die Idee hinter Responsive Content führt die Umsetzung einer responsiven Seite einen Schritt weiter über die optimierte Darstellung der Inhalte hinaus.
Auch die textlichen Inhalte der Seite werden dem gegebenen Platz sowie den Vorlieben der User und deren Endgerät entsprechend optimiert. Das Art Directoring der Bilder lasse ich hier mal bewusst außen vor, denn dafür gibt es mit dem neuen <picture>-Element bereits eine adäquate Lösung.
Auf großen Viewports werden lange und ausführliche Texte und Überschriften dargestellt. Je kleiner das Display, desto komprimierter werden die Texte ausgeliefert. Zu diesem Zweck können einige Passagen umformuliert werden, gänzlich wegfallen oder auch durch Icons ersetzt werden. Lange Texte werden nunmal nicht gerne auf kleinen Displays gelesen.

 

Anschauungsbeispiel Responsive Contents

 

Responsiver Content begünstigt also den Konsum durch den User auf dem gegebenen Endgerät und zusätzlich die ausgelieferte Dateigröße der Seite. Und optimaler Content gepaart mit kurzen Ladezeiten wiederum ruft die Suchmaschinen auf den Plan. So zumindest die Theorie.

Überlegungen zur technischen Umsetzung

Für die technische Umsetzung responsiver Inhalte kommen eigentlich nur drei Möglichkeiten in Betracht.

Lade alle Inhalte und blende sie ein oder aus
Alle Variationen des Contents werden initial in das Frontend geladen. Dort werden sie via Media Queries ein- bzw. ausgeblendet. Das Ein- und Ausblenden kann mittels display: none; bewerkstelligt werden.
Sniffe den User Agent und liefere die Inhalte entsprechend aus
Über den User Agent können ungefähre Rückschlüsse auf die Viewportgröße des Besuchers gezogen werden. Dementsprechend wird das vorbereitete Text-Snippet an das Frontend gesendet.
Ermittle die Viewportgröße mit JavaScript und lade die Inhalte über Ajax
Z. B. lässt sich das aktive Media Query recht einfach mit JavaScript ermitteln (lest mehr darüber hier). Die entsprechenden Inhalte können dann über einen Ajax-Request direkt in den Container geladen werden.

Die erste Variante widerspricht zuerst einmal allen Regeln des Responsive Web Designs. Diese besagen nämlich, dass Inhalte nicht verändert, sondern lediglich neu arrangiert werden. Selbst unter dem Aspekt, dass responsive Inhalte technisch gesehen nicht zwingend dem RWD zugeordnet werden müssen, ensteht hier auf jeden Fall ein Overhead, weil alle Texte auf einmal geladen werden. Also keine praktikable Lösung.

Die zweite Variante ist nicht responsiv, eher adaptiv. Das Auslesen des User Agents ist Grundlage für RESS und Webseiten, die für mobile Endgeräte optimiert wurden und über einen Redirect erreicht werden. UA-Sniffing ist für responsive Inhalte eine realistische Lösung, allerdings bringt sie auch die bekannten Nachteile wie z.B. hohen Wartungsaufwand bzgl. der Sniffing-Abfragen mit sich.

Die dritte Variante schließlich ist auf Grund der Neuerungen im Google-Algorithmus durchaus realistisch. Google ist nun bekanntlich in der Lage einen Ajax-Request zu feuern, um die nachgeladenen Inhalte zu crawlen. Allerdings muss aus Gründen der Barrierefreiheit und für User mit ausgeschaltetem bzw. defektem JavaScript eine Fallback-Lösung implementiert werden, sonst gibt es nämlich in solchen Fällen überhaupt keinen Content.

Sind Responsive Inhalte alltagstauglich oder ein Fall von Overengineering?

Google empfiehlt RWD. RWD macht es Google einfacher eine Website zu indexieren und ist damit ein Wirtschaftsfaktor für den Suchmaschinengiganten. Ein Content für alle Endgeräte – leicht zu indexieren, leicht zu pflegen. Responsive Inhalte jedoch erfordern eine Menge zusätzlicher Leistungen wie z.B. das indexieren der einzelnen Zustände und für den Redakteur einen höheren Aufwand bei der Contentpflege. Dazu kommen noch die technischen Erweiterungen im Frontend, je nachdem für welche Technik zum Ausliefern der Inhalte sich der Entwickler entscheidet.

Doch für welche Bereiche im Online-Business kommen gekürzte Texte für spezielle Endgeräte überhaupt in Frage? Für Shops wäre es durchaus vorstellbar, da die Texte zur Produktbeschreibung auch stichwortartig verfasst werden könnten. Aber wenn solche komprimierten Texte für Besucher mit mobilen Endgeräte ausreichen würden, warum dann nicht auch für Desktop-Devices und Tablets? Also warum nicht gleich Mobile First?
Für Online-Angebote wie z.B. Zeitungen, Magazine und Blogs wiederum ist eine Auslieferung von gekürzten Texten schwer vorstellbar. Eine Komprimierung würde im schlimmsten Fall einen Informationsverlust verursachen und den Artikel qualitativ abwerten und wer soll am Ende die zusätzliche Arbeit des Autors bezahlen?

 

Responsive Inhalte

TL;DR

Einen wahren Mehrwert für alltagstaugliche Projekte sehe ich in der Idee von Responsive Content nicht. Einen Vorteil für SEO gibt es nicht wirklich*, denn die Qualität des gesamten Contents wird hier gewertet, nicht die paar Kilobytes, die die verkürzten Texte auf mobilen Endgeräten einsparen.
Einen Vorteil für den Besucher der Seite sehe ich auch nur bedingt und wenn dann lediglich für ganz spezielle Bereiche und Devices (Wearables?), wobei für diese Geräte eine separate Mobile-Site eher geeignet wäre.
Und der Mehraufwand in der Contenterstellung und der Pflege steht hier sowieso in keinem Verhältnis.

Allerdings konnte ich auch noch keinen Anwendungsfall in einem realen Projekt ausfindig machen und keiner der Vertreter dieser Idee konnte mir einen konkreten Hinweis geben.
Hat jemand von euch Anwendungsbeispiele oder praktische Erfahrung mit responsiven Inhalten? Und wie denkt ihr eigentlich über die ganze Sache?

Weiterführende Links und Quellen

 


*Edit 14.09.2014 | Nachtrag: Erläuterung zu meiner Aussage bzgl. des SEO-Benefits

Meine Äußerung „Einen Vorteil für SEO gibt es nicht wirklich [...]” ist scheinbar doch noch erklärungsbedürftig.

Laut Statements von Google-Mitarbeitern wie z.B. John Müller werden Inhalte, die über display: none; versteckt wurden, im RWD ignoriert. Also werden die initial vom Bot vorgefundenen Inhalte (bei RWD also die Desktop-Version) indexiert. Vgl.: Diskussion auf Googles Product Forum oder John Mueller Google Plus Hangout – July 2013.
Das bedeutet, dass ein SEO-Benefit in erster Linie vom verbesserten Userverhalten (Bounce-Rate, Verweildauer,…) zu erwarten wäre. Auch hier gebe ich zu bedenken, dass optimierte Texte (unabhängig von responsiven Inhalten und ihrem Mehraufwand), eine performante sowie UX-optimierte Seite dieses bewerkstelligen. Die allgemeine Qualität ist eben entscheidend.
Die Aussage, dass durch die eingesparten KBs über responsive Inhalte ein Performance-Vorteil entsteht, wurde übrigens tatsächlich in verschiedenen Beiträgen zum Thema getätigt.
Desweiteren hat John Müller in einem anderen Webmaster Central Video bestätigt, dass RWD kein Ranking Signal Boost ist.

Ich hoffe die Erläuterung trägt zum besseren Verständnis der Aussage bei und möchte nochmal darauf hinweisen, dass SEO nur ein Teilaspekt dieses Artikels ist.

comments powered by Disqus