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