Schlagwort: Performance

Gelesen am Wochenende

Meine Internetverbindung lahmt heute rum, so habe ich etwas Zeit, die für das Wochenende gespeicherten Artikel schon jetzt zu lesen (während die siebte Folge Picard aus der Leitung auf die Platte tröpfelt).

HTML: The Inaccessible Party macht mit meinem Irrglauben Schluss, in Sachen A11Y auf der sicheren Seite zu sein, wenn ich HTML5-Elemente nutze. Die paar verbliebenen Webbrowser entwickeln sich in den letzten Jahren einigermaßen schnell—da kannte ich andere Zeiten—die Screenreader kommen aber nicht entsprechend hinterher. Und haben Fehler. Zusammen ergibt sich eine Liste von Elementen, die zumindest nicht out-of-the-box zugänglich sind.

Ich habe mir zwei Titan Keys von Google zugelegt, um mal auszuprobieren, wo man die FIDO-kompatiblen Schlüssel überall einsetzen kann. How To Set Up and Use The Google Titan Key Bundle hat ein wenig geholfen, tatsächlich ist es aber zur Zeit noch etwas schwierig, mehr im Netz zu finden, als aufbereitete Versionen der Betriebsanleitung, die alle als Ausgang haben, dass man seinen Google-Account mit dem Schlüssel als zweitem Faktor absichert. Dazu muss ich wohl mal einen ganzen Artikel schreiben, wenn Zeit dazu ist.

Tim Kadlec liefert mir mit When CSS Blocks – Web Performance Consulting zwar keine Lösung zu einem meiner aktuellen Probleme, wohl aber einen Einblick, auf welchem Level von Wahnsinn die creme de la creme der Performance-Gurus in ihrer täglichen Arbeit schon angekommen sind. Quasi auf Thread-Level herauszufinden, welches CSS oder Script gerade in Sekunde 0,05 der Timeline das Parsing der Website blockt ist sicherlich eine interessante Arbeit. Mir würde ja schon reichen die abermillionen verschwendeten Millisekunden für Third-Party-Mist mal los zu werden.

Und noch ein Kopfschüttler zum Ende: Hacking und Spionage – Ist WhatsApp sicher genug für die Diplomatie? fragt netzpolitik.org. Was ja nur eine rhetorische Frage sein kann, denn hey, ich bin ja nicht ohne Grund bei WhatsApp ausgestiegen, meine Frau hat ja nicht einfach so alle ihre Kontakte in andere Dienste überredet und die komplette europäische Diplomatie nutzt das Facebook-Produkt, als hätte es den NSA-Skandal nie gegeben?! Na fein…

Morgenlese XXIX

Ich habe schon viel zu lange keine technischen Artikel gelesen und empfohlen. Dann aber jetzt.

Sven Wolfermann zeigt, was man in alles mit dem Sass Parent Selector – ‚&‘ (ampersand) anfangen kann. Sollte sich ja eigentlich inzwischen herumgesprochen haben, Sven liefert aber gleich ein sehr schönes BEM-Template als Beispielcode mit. Also understand, copy and paste it!

Ebenso für den interessierten Webdev-Neuling empfohlen sei das Tutorial Get Started with Debugging JavaScript in Chrome DevTools, das die Jagd nach einem Scriptfehler mithilfe von Entwicklerkonsole und Debugger Schritt für Schritt vortanzt. Bitte nachmachen.

Chris Heilmann zeigt 7 tricks to have very successful conference calls, auf die aber IMHO jeder von selbst kommen könnte, der schonmal in rund hundert Telefon-/Videokonferenzen seine Lebens- und Arbeitszeit verbrannt hat. Dass Videocalls niemals, niemals, niemals auf Anhieb funktionieren erwähnt Christian nur am Rande.

Und schließlich: Web Performance Stats are Overrated:

We discuss web performance statistics as if the web were a monolith, as if all web applications were uniform, like performance improvement effects are linear. They may not be represented by a simple exponential equation, but performance isn’t a simple science, and metric interpretation shouldn’t be assumed to be linear, or even accurate.

Happy coding!

Bild: Parker Byrd auf Unsplash

Morgenlese III

Schneller sein und länger bleiben

Die Washington Post ist dabei ihre so called mobile experience auf eine progressive webapp umzustellen und wird dadurch lightning fast, wie sie selbst schreiben. Und ja, die Website wird dadurch tatsächlich sehr schnell.

Einer der ersten Nutzerkommentare dazu lautet jedoch:

I never recognized a problem with loading speed. What I do recognize is my vision going blurry after looking at it for about 10 minutes or more. That absolutely deters me from reading articles on it.

Vielleicht eine sehr subjektive Aussage, eine Mindermeinung, ist mir gar nicht so aufgefallen. Trotzdem sehr überraschend in dem Zusammenhang.

Und das deckt sich irgendwie mit meiner Erfahrung. Na klar, schnellere Webseiten klicken besser, wissen wir alle, die Absprungsraten nach zwei Sekunden sind astronomisch und so weiter und so fort. Die Websitenutzer entscheiden solche Dinge aber ausschließlich mit den Füßen, will sagen: durch wegbleiben. Das ist die eine Kohorte der Nutzer. Die schnell da, schnell wieder weg Nutzer. Man will ja nicht wie ein Werbefritze klingen, aber: die schnellen User haben (noch) keine Beziehung zur Website. Sie müssen erst konvergiert werden. Und hier ist Schnelligkeit nur ein Punkt, im Grunde erstmal nur jener, der die Auswahl möglichst groß macht.

Was dann aber folgt, dürfen wir nicht aus den Augen verlieren. Irgendwo zwischen Geschwindigkeitsrausch und Werbeverschreckung muss Platz bleiben, den Nutzer vom schnellen Vorbeisurfer zu einem regelmäßigen Nutzer zu machen. Dafür ist natürlich vor allem der Inhalt einer Website verantwortlich, dass der Nutzer also das findet, was er sucht. Aber auch hier haben wir als Webentwickler es in der Hand, an den Reglern zu drehen: Lesbarkeit, Struktur, Informationsarchitektur, Funktionalität bei hoher Zugänglichkeit, es gibt so viele Dinge, die man ausser Geschwindigkeit und minimalistischem Design richtig machen kann und muss. Bitte nicht vergessen: there is more to web than speed.

Foto: Steven Wei