Responsive Design ist nicht genug, wir brauchen Responsive Performance

In letzter Zeit bin ich auf viele responsive Websites mit vielen Leistungsproblemen gestoßen. Bei den meisten von ihnen sind die Probleme so offensichtlich, dass sie auf etwas anderem als der neuesten Generation von Smartphones fast nutzlos sind. Angesichts der Tatsache, dass Responsiveness als Konzept ein breiteres Publikum erreichen soll, erscheint dies eher kontraproduktiv.

Den größten Beitrag zu diesem Thema leistet das immer noch vorherrschende Desktop-First-Designparadigma. Das Denken aus der Perspektive von Mobile First scheint das Problem zu lösen, aber das allein garantiert noch keine zufriedenstellende Leistung. Wir alle scheinen uns viel zu sehr auf mehr oder weniger würdevolle Erniedrigung zu verlassen. Wir verlassen uns auf Shims und Polyfills, um fehlende Funktionalität zu ermöglichen. Wir verlassen uns auf Bibliotheken, um eine schnelle Entwicklung zu ermöglichen und unseren Rücken zu decken, wenn die Browserkompatibilität ein Problem darstellt.

"Warum ärgern?" Sie könnten fragen. „Die meisten unserer Besucher haben leistungsstarke Smartphones mit den neuesten Betriebssystemversionen. Sie können mit unseren Websites umgehen. Die Analytik sagt uns das.“

Es tut mir leid wegen des Strohmann-Arguments, aber ich denke, es verdient es, laut gesagt zu werden, dass die Leute, die Ihre Website benutzen können , die Mehrheit Ihrer Benutzer sein werden. Wenn Sie Android 2.3 nicht in Ihren Analysen sehen, bedeutet das, dass es keine Benutzer mit diesen Geräten gibt? Oder bedeutet das, dass Ihre Website diesen Benutzern nichts zu bieten hat? Bedenken Sie, dass noch viele Geräte dieser Generation in den Regalen stehen und auch heute noch brandneu gekauft werden. Sie sollten es nicht direkt als Technologie von gestern abtun.

Daher möchte ich über die Idealfälle und tatsächlichen Ziele der Webentwicklung sprechen. Und über Praktiken und Paradigmen, die uns diesen Zielen näher bringen.

Brick-First-Designparadigma

Feature-Phones machen immer noch einen erheblichen Teil des jährlichen Telefonumsatzes aus. Ein noch größerer Teil der Bevölkerung kauft nicht jedes Jahr ein Telefon, hat aber dennoch ein internetfähiges Gerät in seinem Besitz. Fügen Sie zu diesen Zahlen die Smartphones der letzten Generation hinzu, die noch in Gebrauch sind, fügen Sie die Kindles und andere halbwegs webfähige Geräte (WAP-Geräte, Fernseher, Toaster, T-Shirts und Ziegelsteine) hinzu. Addiere sie alle und du könntest eine erstaunliche Summe erreichen.

Betrachten Sie die Anwendungsfälle für diese Zielgruppe. Sie werden keine langen Artikel lesen, stöbern und auf ihren Geräten recherchieren. Aber sie könnten den Horror durchmachen, eine URL auf der numerischen Tastatur einzugeben und mit den Richtungstasten auf der Seite zu navigieren, um zu einer Telefonnummer zu gelangen oder eine Adresse im Handumdrehen zu überprüfen.

Wie schwer ist es dann für uns, ein Sub-Mobile-First-Layout zu implementieren, das nur diese Informationen für die Geräte unterhalb einer bestimmten Schwelle an Fähigkeiten und Leistung bereitstellt?

Anmutige Verbesserung

Mit Graceful Degradation als minimale Best Practice haben wir ein Catch-All-Prinzip geschaffen, das (bis zu einem gewissen Grad) das Denken darüber hinaus behindert. Sobald die anmutige Degradation eingetreten ist, können wir mit Sicherheit sagen, dass unsere Arbeit erledigt ist, und zwar gut gemacht. Immer häufiger müssen wir nicht einmal darüber nachdenken, da es bereits von den verschiedenen verwendeten Frameworks und Bibliotheken abgedeckt wird. Und schließlich beseitigen Polyfills und Shims in einigen Fällen vollständig die Notwendigkeit einer Beeinträchtigung der Funktionalität.

Da diese Funktionalität immer leichter verfügbar wird, wird die Notwendigkeit, darüber nachzudenken (geschweige denn darüber hinaus), immer weiter entfernt.

Aus der Sicht dieses Artikels könnte es wie folgt aufgeschlüsselt werden:

Unangemessene Verschlechterung: Wenn eine Funktion nicht ohne Weiteres verfügbar ist, schlägt die Implementierung so fehl, dass sie unbrauchbar oder auf unerschwinglich unpraktische Weise nutzbar wird.

Anmutige Verschlechterung: Wenn eine Funktion nicht ohne Weiteres verfügbar ist, fällt sie auf eine Weise aus, die immer noch eine akzeptable Benutzerfreundlichkeit ermöglicht.

Unanständige Verbesserung: Wenn die Funktion nicht ohne Weiteres verfügbar ist, wird sie durch Polyfill oder Shim emuliert.

Dort Problem gelöst.

Nun, es sei denn, Sie berücksichtigen die Leistung derselben Low-End-Geräte.

Da ihnen die Verarbeitungsleistung und die Datenkapazitäten ihrer jüngeren Geschwister fehlen, müssen sie eine viel größere Last tragen. Polyfills als Lösung zu nehmen, erzeugt die Illusion, dass alle modernen Funktionalitäten jetzt auf allen Geräten verfügbar sind und bedenkenlos genutzt werden können.

Und so implementieren Sie für alle Fälle modernizr und polyfill. Das am wenigsten kompetente Gerät lädt am Ende die größte Datenmenge und führt den größten Verarbeitungsaufwand aus. So wird das „beste“ Endbenutzererlebnis sichergestellt.

Die Idee der eleganten Verbesserung würde das Konzept umkehren, indem mit den niedrigsten Funktionsanforderungen begonnen und Upgrades geladen werden, bis das Gleichgewicht zwischen Leistung und Benutzerfreundlichkeit basierend auf den Gerätefunktionen optimal ist. Somit würden der Datenverkehr und die Verarbeitungsanforderungen auf die dafür am besten geeigneten Geräte verlagert.

Sicher, im Moment ist das Konzept unerschwinglich komplex: Es wird von den meisten Frameworks und Bibliotheken nicht unterstützt, es wird größtenteils nicht diskutiert, und Verweise auf solche Praktiken sind wenige, weit voneinander entfernt und auf Mikrofunktionalitäten beschränkt. Aber irgendwann war das bei allen Konzepten und Funktionalitäten so.

Kann es, aber muss es?

Eine weitere bewährte Methode bei der Webentwicklung besteht darin, zu prüfen, ob eine Funktion auf einem Gerät verfügbar ist, bevor sie aktiviert wird.

Berücksichtigen Sie jedoch, dass Sie die neueste Version von Google Chrome auf Ihrem jahrelangen Android-Telefon installieren können, und es wird behauptet, dass es CSS-Animationen, WebGL, Hintergrund-Parallax-Effekte und viele andere Funktionen ausführen kann. Aber das kann es wirklich, wirklich nicht. So sehr, dass der Browser abstürzt und das gesamte Gerät bis zu einem Punkt nicht mehr reagiert, an dem es neu gestartet werden muss, um die Kontrolle wiederzuerlangen.

Dieses Problem hat in letzter Zeit große Auswirkungen auf Android-Anwendungen (aus Benutzersicht). Eine der auffälligsten Verschlechterungen in diesem Sinne betrifft das Upgrade der Google Talk/Hangouts-App, das ihren Dienst aufgrund von Leistungsproblemen auf älteren Geräten von der leichtesten verfügbaren Chat-Anwendung in eine fast unbrauchbare Anwendung verwandelt hat. (Um das noch einmal zu betonen: „älter“ bedeutet hier, dass man es in fast jedem Geschäft noch fabrikneu und nagelneu kaufen kann). Das gleiche Problem betraf die YouTube-App und die Twitter-App (meiner Erfahrung nach) und anscheinend viele andere.

Nehmen Sie sich also irgendwann während Ihrer Planungsphase einen Moment Zeit, um den Wert einer leistungsstarken Kernfunktion gegenüber hochmodernem Make-up zu bewerten. Oder lassen Sie zumindest die letzte Generation Ihrer App/Ihres Dienstes/Ihrer Inhalte in irgendeiner Form für die alten Benutzer verfügbar. Apropos…

Lassen Sie die Benutzer sich von Bleeding Edge abmelden

Haben Sie jemals versucht, Google Mail von einem alten Gerät oder über eine schlechte Verbindung zu verwenden? Dieser Link „Basis-HTML laden“ ist sicher praktisch.

Warum hat Ihre hochmoderne, ansprechende, animierte, berührungsorientierte Online-Schaufensterfront diese Funktionalität nicht?

Denken Sie darüber nach: Sie haben darum gebeten, dass es reaktionsschnell ist, damit Sie mehr potenzielle Kunden erreichen können. Sie haben es geschafft, den besten ersten Eindruck zu hinterlassen. Infolgedessen können weniger potenzielle Kunden auch nur die grundlegenden Informationen über Sie und Ihre Dienstleistungen erreichen. Wenn elegante Verbesserung ein zu kostspieliges Konzept für Sie ist, warum bieten Sie Ihren Besuchern nicht zumindest die Möglichkeit, auf eine Nur-Text-Version Ihrer Inhalte zuzugreifen, wenn die „WOW“-Version für ihre Geräte zu viel ist.

Brauchen Sie wirklich die ganze Bibliothek?

Schließlich ist die letzte Best Practice, die ich gerne etwas über den Standard hinausgeschoben sehen würde, „Use it or lose it“. Es ist manchmal mühsam, den Überblick darüber zu behalten, welche Bibliotheken und Module tatsächlich verwendet werden, und nur diese einzubinden, aber Ihr gesamtes Toolset auf jeder Seite zu halten, ist einfach schlampig.

In letzter Zeit habe ich angefangen, zu verfolgen, wie viele Funktionen ich tatsächlich verwende, wenn ich eine Bibliothek einfüge. Und das Tool, das ich am häufigsten verwende, ist jQuery. Oft stelle ich fest, dass ich nur eine oder zwei Funktionalitäten (wie $.extend oder $.ready) verwendet habe, oder noch schlimmer, dass ich sie nur verwendet habe, um Elemente nach Klasse oder ID zu erhalten. Manchmal lasse ich es so, manchmal gehe ich den Code zurück, um die Abhängigkeit zu entfernen oder zu entkoppeln.

Wäre es nicht schön, wenn Sie anhand der Ergebnisse automatisch analysieren könnten, was und wie viel von einer Bibliothek am Ende verwendet wurde und wie viel Gewicht verloren hat?

Viele Bibliotheken und Anwendungen bieten die Möglichkeit, das Loadout anzupassen, bevor Sie es verwenden. Aber ich habe immer noch das Gefühl, dass es nicht zu weit außerhalb unserer Reichweite liegen sollte, eine automatisierte „Use it or lose it“-Build-Architektur in unseren Bibliotheken zu standardisieren.

Ich habe eine Allergie gegen den „alles einbeziehen“-Ansatz. Aber die Verwendung in Verbindung mit einer solchen Funktionalität könnte den Ansatz in etwas verwandeln, das einem Prototyping-Board ähnelt: ein übermäßig flexibles Entwicklungstool, das nicht nur in der Syntax, sondern auch in der tatsächlichen Funktionalität selbst minimiert wird.

Was erforderlich wäre, wäre eine reine Entwicklungsversion der Bibliothek, die durch einen Komponententest der abhängigen Funktionalität die Verfolgung verwendeter Funktionen und die Ausgabe der minimalen Abhängigkeit oder zumindest des Nutzungsumfangs ermöglicht (z. B. die Frage, ob ich jQuery für 8 % seiner Funktionalität oder 80 %). Die Abhängigkeitsausgabe könnte dann verwendet werden, um die Ausgabe für die Produktion auszuwählen, zu aggregieren und zu minimieren.

Aber was kann ich dagegen tun?

Befassen Sie sich zunächst mit dem Thema . Denken Sie darüber nach, diskutieren Sie mit Ihren Kollegen und versuchen Sie, das Problem in realen Szenarien zu erkennen.

Versuch es. Holen Sie das Handy der letzten Generation heraus, das Sie irgendwo in einer Schublade verstaut haben. Versuchen Sie, es auf Ihren eigenen Websites zu verwenden, und prüfen Sie, ob der Inhalt überhaupt aus der Ferne nutzbar ist. Besuchen Sie einige Verwandte auf dem Land, die hinter der Zeit zurückgeblieben sind, und versuchen Sie, für sie ein Tech-Evangelist zu sein. Sehen Sie, ob ihre Verzögerung bei der Einführung von Technologien tatsächlich durch Barrierefreiheitsprobleme erleichtert wird.

Wenn Sie ein Käufer sind , der eine Website in Auftrag gibt, bitten Sie um (mindestens) Unterstützung auf niedriger Ebene zu diesem Thema. Denken Sie daran: Das Ziel ist nicht, eine vollständige Portierung aller Ihrer Funktionen auf Low-Level-Geräte zu erstellen. Alles, was verlangt wird, ist, dass diese Benutzer Ihre Kontaktinformationen erhalten, anstatt dass ihr Gerät abstürzt.

Reservieren Sie dafür tatsächliche Ressourcen: Die einfachste Lösung für das Problem sollte nicht länger als ein oder zwei Tage und einige vorausschauende Überlegungen erfordern. Denken Sie in erster Linie an die grundlegendsten Gründe für die Erstellung der Website (geschweige denn für die Erstellung einer responsiven Website).

Wenn Sie ein Paketentwickler sind, der an einer Bibliothek, einem Framework, einem Bundle oder einer anderen integrierbaren Software arbeitet: Sie sind derjenige, der hier den größten Unterschied machen kann. Wenn Sie diese Konzepte vereinfachen oder in Ihre Plattform integrieren können, werden Sie die gesamte Landschaft der Webentwicklung beeinflussen. Wenn Sie es in Ihr Verpackungsdesign integrieren, lassen Sie es mich wissen und ich werde für Sie evangelisieren.

Und schließlich, **wenn Sie ein Entwickler oder Designer sind**, hören Sie nicht nur bei Best Practices auf. Versuchen Sie immer, nur ein wenig über diesen Horizont zu blicken. Die harte Arbeit liegt bei Ihnen, diese Konzepte voranzutreiben, nach denen noch niemand gefragt hat, die nicht unterstützt und nicht dokumentiert sind, zum Nutzen Ihrer Kunden und Benutzer.

Wenn Sie schließlich hören möchten, wie jemand stundenlang darüber redet und sich in der Nähe von Zagreb wiederfindet, lassen Sie es mich wissen. Wir könnten eine Tasse Kaffee trinken gehen.