Ich habe einen Tweet von einem guten Kumpel und Kollegen Mariko , in dem es darum ging, mit einer Reihe von Low-End-Geräten zu testen, was Sie wirklich auf dem Mariko hält.
Der Kontext des Tweets ist, dass wir untersuchen, wie Web Development aussieht, wenn Benutzer für Benutzer erstellen, die täglich mit diesen Geräteklassen leben.
Das Team arbeitet derzeit sehr viel in diesem Bereich, aber ich habe einen Tag damit verbracht, eine Website zu bauen, und es war unglaublich schwer, alles auf einem nur halbwegs vernünftigen Niveau funktionieren zu lassen.
Ich war vor ein paar Wochen für den Google Developer Day in China und habe allen meinen QRCode-Scanner gezeigt, es funktionierte großartig, bis ich offline ging. Wenn der Benutzer offline war (oder teilweise verbunden war), konnte die Kamera nicht starten, was dazu führte, dass QR-Codes nicht ausgelöst werden konnten. Ich brauchte ein ganzes Alter, um herauszufinden, was passierte, und es stellte sich heraus, dass ich irrtümlich die Kamera bei meinem Onload-Ereignis gestartet hatte und die Google Analytics-Anfrage hängen blieb und nicht rechtzeitig gelöst werden konnte.
Dan von Redfin hat einen tollen Beitrag über die Priorität der Webgeschwindigkeit:
JavaScript Is the Web’s CO2 As a web developer, I find that most problems can be solved with just a little more JavaScript. Without someone or something to force the industry to cut back, web developers will continue to make web sites that only load “fast enough” via wifi on a fast laptop.
The browser vendors can’t save us.
Eric Bidelman auf Google Web des Entwicklers aktualisiert, schreibt:
Building for the web is a rocky adventure. It’s hard enough to build a top-notch web app that nails performance and uses all the latest best practices. It’s even harder to keep that experience great over time. As your project evolves, developers come on board, new features land, and the codebase grows. That Great Experience ™ you once achieved may begin to deteriorate and UX starts to suffer!
