Vi un tweet de un buen amigo y colega, Mariko , acerca de las pruebas en una gama de dispositivos de gama baja que lo mantienen realmente conectado a tierra.
El contexto del tweet es que estamos analizando cómo es el desarrollo web cuando construimos para usuarios que viven diariamente en estas clases de dispositivos.
El equipo está haciendo mucho trabajo ahora en este espacio, pero pasé un día construyendo un sitio y fue increíblemente difícil hacer que algo funcionara a un nivel de rendimiento incluso ligeramente razonable.
Hace un par de semanas estuve en China para el Día del desarrollador de Google y les mostré a todos mi QRCode scanner, estaba funcionando muy bien hasta que me desconecté. Cuando el usuario estaba fuera de línea (o parcialmente conectado), la cámara no se iniciaría, lo que significaba que no podía ajustar los códigos QR. Me tomó una edad para averiguar qué estaba pasando, y resultó que estaba arrancando la cámara por error en mi evento onload y la solicitud de Google Analytics se bloqueó y no se resolvió de manera oportuna.
Dan de Redfin tiene una excelente publicación sobre cómo priorizar la velocidad de la web:
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.
Eric Bidelman en las actualizaciones de la web del desarrollador de Google, escribe:
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!
