- Desde 2017, el aumento del ancho de banda ha superado hasta cierto punto el crecimiento del tamaño de transferencia de los sitios comunes, pero las exigencias de CPU de las apps web han crecido más rápido que el rendimiento de los dispositivos económicos, empeorando el acceso a la web incluso con internet rápido
- Incluso con una conexión de
1Gbps, en elTecno Spark 8Cel navegador se bloquea en foros de Discourse, y en elItel P32sitios como Discourse, Reddit, Shopify, Substack, Wix, Mastodon y Bluesky quedan en estado de FAIL o prácticamente inutilizables - Las mediciones compararon
LCP*y tiempo de CPU del hilo principal enM3 Max,M1 Pro, Chrome con throttling de CPU10x,Tecno Spark 8CyItel P32, y la puntuación de PageSpeed Insights mostró poca correlación con la velocidad percibida real - Sitios simples o antiguos como MyBB, phpBB, WordPress antiguo, HN y danluu.com funcionaron relativamente bien incluso en móviles económicos, mientras que sitios con mucha carga dinámica como Discourse, Medium, Reddit y Substack mostraron un claro retraso al hacer scroll, buscar y tocar
- Los usuarios de dispositivos económicos en regiones como Nigeria, India y Latin America son usuarios reales de la web, y si se construye la web pensando solo en iOS e internet rápido, se excluye tanto a usuarios menos acomodados como a usuarios de escritorio de bajas prestaciones
La web donde la CPU se volvió el cuello de botella más que el ancho de banda
- En 2017, el web bloat dañaba seriamente la usabilidad en conexiones lentas, y desde entonces el ancho de banda de las conexiones de gama alta ha aumentado rápidamente, cerca de un
50%anual según Nielsen - Sigue habiendo mucha gente con internet lento, y gran parte de la web moderna sigue siendo difícil de usar en conexiones lentas, pero en los sitios comunes el aumento del ancho de banda sí ha superado hasta cierto punto el crecimiento del tamaño de transferencia
- En cambio, los requisitos de rendimiento de CPU de las apps web no han mejorado tan rápido como el ancho de banda, así que incluso con una buena conexión a internet la web puede ser difícil de usar en dispositivos de bajas prestaciones
- Los foros “modernos” basados en Discourse pueden incluso hacer que el navegador se bloquee en un
Tecno Spark 8C, y la capacidad de respuesta entre bloqueos resultó peor que usar un BBS con un286 de 8 MHzy un módem de1200 baud - En Discourse, la carga comprimida para traer los títulos de los mensajes es de
2.6 MB, unas1000xmás transferencia que antes, aunque en una conexión de1Gbpseso es relativamente liviano - Del lado de CPU, incluso el
Tecno Spark 8Ccon8-core (2 1.6 GHz Cortex-A75 / 6 1.6 GHz Cortex-A55)no puede manejar Discourse, y ese CPU es aproximadamente100000xmás rápido que un286
Dispositivos y métricas de medición
- Los dispositivos de prueba fueron
M3 Max Macbook (14-core),M1 Pro Macbook (8-core),M3 Maxcon throttling10xen Chrome DevTools,Tecno Spark 8CyItel P32 - Para favorecer a los dispositivos, la red usada fue internet de
1Gbpsy un router WiFi con buena latencia bajo carga según benchmarks - La comparación incluyó blogs y microblogs, foros y plataformas para pequeños negocios
- Blogs y microblogs: danluu.com, Substack, Medium, Ghost, Hugo, Tumblr, Mastodon, Twitter, Threads, Bluesky, Patreon
- Foros: Discourse, Reddit, Quora, vBulletin, XenForo, phpBB, MyBB
- Plataformas para pequeños negocios: Wix, Squarespace, Shopify, WordPress
- Las métricas principales fueron tamaño comprimido transferido (
wire), tamaño descomprimido (raw),LCP*y tiempo de CPU del hilo principal LCP*no es el Largest Contentful Paint medido por Chrome, sino el momento en que aparece contenido realmente útil cuando una gran actualización visual no aporta nada al usuario- El tiempo de CPU no es un Core Web Vital, pero se usa como una métrica simple muy ligada a la usabilidad que perciben los usuarios en dispositivos lentos
La brecha de usabilidad que muestran las tablas
- danluu.com y HN funcionaron rápido en todos los dispositivos probados
- danluu.com:
6kB wire / 18kB raw,0.4s LCP* / 0.3s CPUenTecno Spark 8C - HN:
11kB wire / 50kB raw,0.5s LCP* / 0.5s CPUenTecno Spark 8C
- danluu.com:
- Los foros antiguos basados en PHP se comportaron mucho mejor en dispositivos lentos que los foros modernos
- MyBB:
0.8s LCP* / 0.8s CPUenTecno Spark 8C - phpBB:
1.7s LCP* / 1.5s CPU - vBulletin:
4.4s LCP* / 4.8s CPU - Discourse:
15s LCP* / 26s CPUy enItel P32daFAIL
- MyBB:
- Incluso entre plataformas de blogs, un tema antiguo de WordPress fue mucho más rápido en dispositivos de bajas prestaciones que Medium y Substack
- WordPress(old):
0.7s LCP* / 1.7s CPUenTecno Spark 8C - Medium:
2.8s LCP* / 33s CPU - Substack:
14s LCP* / 14s CPU
- WordPress(old):
- Varios sitios modernos fallaron en
Itel P32o quedaron prácticamente inutilizables- XenForo, Mastodon, Bluesky, Wix, Substack, Shopify, Discourse y Reddit dieron
FAIL - Threads:
28s LCP* / 66s CPU, Twitter:24s LCP* / 43s CPU, Medium:3.2s LCP* / 63s CPU
- XenForo, Mastodon, Bluesky, Wix, Substack, Shopify, Discourse y Reddit dieron
- Las páginas que usan
10s+ CPUdan una mala experiencia incluso después de cargar- El scroll puede caer a apenas unos FPS, y el retraso al tocar es tan largo que cuesta saber si el toque se registró
- Si se vuelve a tocar, el primer toque puede registrarse tarde y luego el segundo puede disparar una acción inesperada
Diferencias entre dispositivos reales y CPU throttling
- El CPU throttling de Chrome DevTools es práctico, pero no aproxima de forma consistente los resultados de dispositivos lentos reales
- En la comparación entre
M3/10yTecno Spark 8C, las diferencias variaron mucho según el sitio- danluu.com y Ghost se aproximaron más o menos bien
- Medium, Substack y Twitter fueron cerca de
3xmás lentos en tiempo de CPU enTecno Spark 8C - Reddit y Discourse fueron cerca de
4xmás lentos - Shopify mostró que
Tecno Spark 8Cera más de un orden de magnitud más rápido queM3/10
- Algunas páginas lentas se vuelven superlinealmente más lentas a medida que el dispositivo empeora, y la lentitud de una página no predice bien la de otra
- En
M3yM1, Discourse, Medium y Reddit no parecían usar tanto CPU, pero enTecno Spark 8Cquedaron entre los más lentos - Reddit usa
~90% CPUaun sin interacción, por lo que el CPU aparece como∞
La fortaleza de los sitios antiguos y las páginas simples
- En general, los sitios viejos fueron más rápidos que los recientes, y los que casi no han cambiado visualmente en 10 a 20 años estuvieron entre los más rápidos
- MyBB fue
3.6x / 5xmás rápido que Discourse enM3y19x / 33xmás rápido enTecno Spark 8C - WordPress(old) se midió como
17.5x / 10xmás rápido que Medium enM3 Maxy4x / 19xmás rápido enTecno Spark 8C - Ghost es una plataforma moderna lanzada un año después de Medium, pero es una excepción que logra competir en rendimiento con plataformas más viejas
- NodeBB también fue casi una excepción entre los foros modernos en las pruebas del apéndice
0.3s / 0.4senM13.4s / 7.2senTecno Spark 8C- Mucho más rápido que Discourse, y después de cargar el scroll y los toques funcionan de forma aceptable
La trampa de la carga dinámica y la optimización para métricas
- Sitios como Discourse, Reddit y Substack, que cargan primero una parte de la página y luego el resto de forma dinámica, son peores en la práctica de lo que sugieren sus números en la tabla
- En dispositivos lentos es difícil predecir cuánto se puede avanzar con scroll, y si se baja demasiado se puede activar una carga adicional que congele la página
- Las páginas que eliminan contenido anterior a medida que se hace scroll son prácticamente inutilizables en dispositivos lentos
- Las páginas con carga dinámica dificultan usar la búsqueda rápida del navegador con
Ctrl/Command+F, así que tienen que implementar su propia búsqueda- La búsqueda de Google Docs carga tan tarde que en los últimos meses o cerca de un año no ha sido fácil usarla justo después de abrir un documento
- La búsqueda de Discourse nunca ha funcionado bien en dispositivos lentos o ni siquiera en dispositivos no muy rápidos
- En teoría, más trabajo inicial de CPU podría acelerar la interacción posterior, pero en las páginas probadas fueron lentas la carga inicial, la carga posterior y también la interacción después de cargar
El gaming de LCP
LCPoriginalmente busca aproximar cuándo el usuario ve el contenido principal de una página, pero la medición de Chrome se parece más a registrar cuándo ocurrió una gran pintura en pantalla- Algunos sitios muestran rápidamente una pantalla grande de carga que no ayuda al usuario para bajar el
LCP, y luego dividen el contenido real en actualizaciones pequeñas para que no cuente comoLCP - Discourse introdujo públicamente Discourse Splash e indicó que con una gran pantalla splash durante cargas lentas redujo mucho el
LCP - La respuesta oficial de Discourse implicaba que si el banner del contenido real era más grande que el splash, eso perjudicaba el
LCP - Los casos donde más difirió el
LCP*basado en contenido útil y elLCPmedido por Chrome fueron Wix y Discourse- Wix:
6xenM3,12xenM1,3xenTecno Spark 8C - Discourse:
10xenM3,12xenM1,4xenTecno Spark 8C
- Wix:
Cómo impacta el rendimiento en el negocio
- En grandes empresas, mejorar el rendimiento de sitios y apps tuvo un valor económico considerable, lo bastante grande como para medirse con pruebas A/B
- Incluso en holdbacks de largo plazo, las mejoras de rendimiento aparecieron como intervenciones con un impacto relativamente grande en crecimiento y retención
- En Twitter, la latencia p99 observada por usuarios rondaba los
60sno solo en India y varios African countries, sino también en United States - En cada país había suficientes usuarios con dispositivos o conexiones lentas como para que el factor limitante estuviera más cerca de la paciencia del usuario que del promedio general de dispositivos y conexiones de toda la población
- Una mejora que baje de
60sa50sen dispositivos lentos también puede equivaler, para usuarios de dispositivos de gama alta, a bajar de5sa4.5s, con impacto en ingresos, crecimiento y retención
Diseñar pensando en dispositivos de bajas prestaciones
- En dispositivos lentos o con poco ancho de banda y conexiones inestables, la mejor experiencia suele ser cargar mucho contenido de una vez como página estática
- Tener atributos
width,heightyaltadecuados en las imágenes ayuda, pero los progressive JPEG no mostraron una ventaja especialmente grande - En dispositivos lentos con conexión rápida, las páginas estáticas livianas funcionan bien, y también pueden funcionar páginas dinámicas livianas si están diseñadas con rendimiento en mente
- En páginas pesadas, la carga adicional al hacer scroll y el secuestro de la búsqueda rompen modelos de interacción que sí eran utilizables
- En Substack, un artículo puede tener
LCPrápido en un iPhone 8, pero para pasar del encabezado hay casos donde hay que esperar6spara que cargue la siguiente página y luego otros1s~2s - Como caso opuesto, una página grande de plain HTML funciona relativamente bien incluso en dispositivos modestos
https://danluu.com/diseconomies-scale/tiene0.1 MB wire / 0.4 MB rawhttps://danluu.com/threads-faq/tiene0.4 MB wire / 1.1 MB raw- Una sola página de texto de
1.1 MBfunciona mejor en dispositivos lentos que la mayoría de los sitios modernos
- La documentación de la biblioteca estándar de Zig trae primero todo el código fuente y lo renderiza localmente, pero en
Tecno Spark 8Cusa4.7sde CPU y conserva una capacidad de respuesta razonable
Usuarios de bajos ingresos y accesibilidad
- El
Tecno Spark 8Cpuede conseguirse por unosUSD 50-60en Nigeria yUSD 100-110en India, pero como proporción del ingreso mediano del hogar en esas regiones representa mucho más que un iPhone actual en Estados Unidos - A escala mundial, el
Tecno Spark 8Cno está ni cerca de ser un dispositivo del segmento más barato, y elItel P32también está por encima de muchos dispositivos realmente mínimos que sí se usan - Según Alex Russell, la cuota de iOS es de
7%en India y6%en Latin America - Según telemetría de Windows, la mayoría de usuarios de laptops y desktops usan dispositivos de bajas prestaciones que probablemente sean más lentos que un iPhone reciente
- Entre los teléfonos “lifeline” entregados a personas que califican, hay iPhone 6 o iPhone 8, pero también muchos dispositivos peores que
Itel P32, y con límites de datos tan bajos que, al agotarse, se dificulta buscar trabajo, llenar formularios de beneficios o usar Maps - Las apps móviles pueden descargarse por adelantado cuando hay buena conexión, pero las web apps no son viables en conexiones limitadas si exigen bajar varios MB de JavaScript comprimido en cada acceso
Condiciones experimentales y límites
- Cada sitio se midió buscando, en la medida de lo posible, la experiencia “más básica”
- WordPress usó el demo del tema por defecto actual
twentytwentyfour - Shopify usó el primer tema que apareció en la lista de temas
- Discourse, vBulletin, XenForo, phpBB y MyBB usaron páginas encontradas en foros oficiales
- WordPress usó el demo del tema por defecto actual
- Este fue un proyecto corto, hecho en un día para recolectar y analizar datos, así que no refleja necesariamente los temas más comunes ni la distribución real de personalizaciones de usuarios
- Las laptops se probaron con cerca de
60%de batería, sin estar conectadas a corriente, en una habitación a20°C, tras acercarlas al equilibrio térmico - Los móviles se probaron con alrededor de
100%de carga, conectados a corriente y sin otras apps ni pestañas abiertas - En uso real, la mayoría de las personas probablemente verá peor rendimiento en el mismo dispositivo por tener más apps y procesos en segundo plano
- El tamaño se midió en móvil, así que cuando móvil y desktop reciben recursos distintos, se refleja el tamaño de los recursos móviles
CPUse midió como tiempo de CPU del hilo principal; se registró tiempo de otros hilos, pero no se usó en la métrica
Casos destacados por sitio
- Wix no mantiene un scroll estable en
Tecno Spark 8C, y enItel P32falla de forma no determinista - Patreon tiene peor rendimiento de scroll de lo que sugieren sus números de carga inicial, al punto de que resulta tan incómodo buscar publicaciones viejas que se mantiene un índice aparte de publicaciones de Patreon
- Discourse tiene un
LCPfuertemente gameado; incluso con1GbpsenM3 Max, elLCPmedido por Chrome fue de115ms, pero el contenido real cargó en1.1s - Bluesky muestra una pantalla vacía en
Itel P32 - Los dos primeros casos de uso reales de Shopify fueron mucho más lentos que la página de demo probada
- Tumblr lanza un error de JavaScript en
Itel P32, pero gracias a eso la página carga más rápido y el scroll y los clics en enlaces sí funcionan - MyBB no ofrece una versión móvil, lo que puede perjudicarlo frente a Google, pero en móviles lentos el scroll y los toques sí funcionan bien en la práctica
- Woo Commerce no se puede comparar con Shopify solo por rendimiento de carga inicial; haría falta una comparación aparte incluyendo flujos reales como carrito y checkout, por eso quedó fuera de la tabla
1 comentarios
Opiniones en Hacker News
Hace poco probé un teléfono Android relativamente lento, y hasta las páginas web que parecen tener solo texto e imágenes pueden ser realmente dolorosas de cargar.
El verdadero cuello de botella no parece ser la red, sino más bien los rastreadores, los anuncios y la hinchazón de JavaScript.
En teléfonos viejos y lentos, incluso un navegador completo como Firefox móvil resulta demasiado pesado, así que uno termina usando un navegador ligero como Firefox Focus; pero como no permite extensiones, tampoco se puede usar uBlock Origin, y la experiencia web empeora todavía más.
Algunos sitios se quejan si no usas un navegador “estándar” y se vuelven inutilizables, mientras que las empresas te empujan a instalar su app.
Antes había versiones simplificadas para dispositivos y conexiones lentas, pero están desapareciendo cada vez más; parece que sin la hinchazón de JavaScript es difícil hacer funcionar las redes de anuncios y rastreo.
Es especialmente peor cuando hay anuncios aleatorios incrustados en páginas con scroll infinito.
Un ejemplo reciente: la tienda web de Nike mostró un error inútil durante el pago, y soporte solo dijo “prueba con la app”.
Los sitios de reservas de aerolíneas europeas también son ejemplos típicos de sitios web de grandes empresas que fallan con frecuencia.
Es raro pensar que en 2024, teniendo recursos casi ilimitados, no poder hacer un sitio web que funcione no tenga un impacto negativo en la marca.
Tenía que funcionar en todos los países, y una buena parte de los celulares más lentos eran productos de esa misma empresa.
No es rápida, pero no tengo problemas para usar sitios web; simplemente no responde tan al instante como el hardware nuevo, aunque sigue siendo perfectamente usable.
Eso sí, uso uBlock Origin.
Me pregunto si esos dispositivos Android son realmente más débiles, en la práctica, que una MacBook básica de hace 11 años.
Estoy muy de acuerdo con el punto de Dan sobre tener presente el nivel de desigualdad en el mundo, pero también hay que incluir países de ingresos medios como los de América Latina y el sudeste asiático.
Por ejemplo, hay usuarios con límites mensuales de datos de un solo dígito en GB, y con RAM/CPU al nivel de un flagship estadounidense de hace 10 años.
No es que no puedan usar Discourse en absoluto, pero la experiencia probablemente se sienta desagradablemente lenta.
Creo que cuando Dan observó que mejoras graduales en CPU/RAM/disco aumentan la participación de forma medible, se refería sobre todo a este grupo de usuarios.
En los gráficos de Dan se ve que los usuarios de dispositivos de gama ultrabaja como el Itel P32 no obtienen gran beneficio de optimizaciones graduales.
Lo que podría ayudar es una estructura de cliente completamente distinta, que sacrifique funciones y sofisticación para entregar el código más liviano posible; es decir, una especie de modo ligero/básico alternativo.
Pero este enfoque no suele tener mucho éxito, porque vuelve a aparecer el problema de empatía: los desarrolladores estadounidenses juzgan mal qué conservar y qué descartar en nombre del rendimiento.
Me pregunto qué ofrece hoy Discourse que no ofrezcan PhpBB o los foros de DLang.
Salvo por un diseño amigable para móviles, en un mundo normal bastaría con ajustar unas pocas líneas de CSS responsivo.
30 GB de datos al mes cuestan $3.64, unas 4 a 6 horas de trabajo con salario mínimo.
Lo más importante es que la gente no consume datos a lo loco como en Occidente.
Hay Wi-Fi gratis en cafés, restaurantes, supermercados y centros comerciales; la mayoría pregunta primero la contraseña del Wi-Fi antes que el menú.
Nunca he visto ni escuchado a nadie decir que un sitio web le consume los datos demasiado rápido.
Suena como una preocupación inventada por gente que no ha vivido realmente en un país en desarrollo.
Aquí la gente se queda sin datos por ver videos en TikTok, Instagram y Facebook, no por la hinchazón de los sitios web.
Lo mismo aplica al bloatware que viene instalado junto con la computadora.
Hace poco compré una laptop nueva y me ofrecieron una “puesta a punto” de $50.
Suena raro si imaginas a un vendedor de autos nuevos haciendo una oferta así.
Si estás en una zona con mala señal, el problema empeora diez veces.
No hablo de una UI compleja donde solo se ve un tercio de la pantalla por encabezados fijos y anuncios, sino del tamaño mismo de sitios web armados de cualquier forma hasta que parecen el documento de diseño.
Sitios que ya habrían sido pesados aunque estuvieran bien hechos se vuelven imposibles de usar con una conexión lenta, por no hablar de hardware lento.
Es difícil imaginar cómo se siente usar internet en el entorno descrito, y solo espero que esas personas usen sitios locales adaptados a su ancho de banda y dispositivos, en vez de tener que lidiar con la basura inflada que sufrimos nosotros.
La mayoría de los sitios web son casi una tortura.
Es interesante que la mayoría solo culpe a los jefes o a las grandes corporaciones temibles.
Los desarrolladores no reconocen que también existe un grupo grande de programadores web poco competentes que no entienden bien la eficiencia y tampoco parecen querer entenderla.
Ellos también son responsables del triste mundo del software web, tanto como los jefes o las élites corporativas que obligaron a crear mal software.
Cuando les preguntabas por partes concretas del “resultado”, es decir, HTML, CSS, JS, te miraban como si hablaras otro idioma.
Venían del mundo de los frameworks de JavaScript y no habían pensado mucho en el resultado que había debajo.
Mi filosofía es casi lo contrario: preguntar cuál es el mínimo código mantenible que produce un resultado equivalente a un sitio web HTML+CSS+JS bien escrito a mano.
Por lo general, el resultado termina siendo varios órdenes de magnitud más pequeño.
Cuando me preguntaron cómo había logrado que 1000 filas de una tabla se filtraran en tiempo real y aun así cargaran rápido y funcionaran bien en móvil, les dije que simplemente enviaba todos los datos en la primera solicitud y ocultaba dinámicamente los que no coincidían con el filtro.
El servidor web solo tenía que entregar los mismos datos en caché a todo el mundo, y ese era todo el JavaScript que se ejecutaba en el sitio, así que para ellos parecía extrañamente rápido.
Al ver el HTML de filas de tabla similares en su solución basada en framework, el 80% era boilerplate que ni siquiera se usaba.
El desarrollo web se volvió demasiado rígido, y mucha gente se alejó demasiado de la esencia de las tecnologías web.
Si los usuarios principales fueran de EE. UU. o la UE, podría tener cierto sentido no optimizar demasiado para hardware de gama baja y conexiones inestables, de bajo ancho de banda y alta latencia.
Pero si el público objetivo era el África rural, una optimización agresiva parecía obvia.
Sin embargo, la página de inicio cargaba una imagen gigantesca de 2 MB reducida con CSS a 500×1000 píxeles, y lo que venía después era peor.
No recuerdo el tamaño exacto del payload de JS, pero eran varios MB, y aunque en su mayor parte parecía una app backend tradicional basada en templates, el frontend era extremadamente pesado.
Postulé porque el concepto era bueno, pero la tecnología era espantosa.
Como ni siquiera pasé de la primera entrevista, no sé por qué era así, pero cuesta imaginar otra cosa que no sea que los desarrolladores de Europa occidental no se daban cuenta bien de lo que estaban haciendo en este aspecto.
El punto de partida no son los desarrolladores, sino el presupuesto.
Si la alta dirección no entiende de tecnología o no tiene antecedentes de ingeniería, normalmente asigna presupuesto para nuevas funcionalidades, pero subestima o directamente no asigna presupuesto para mantenimiento y eliminación de deuda técnica.
Incluso cuando hay presupuesto de mantenimiento, casi siempre queda a cargo de equipos de mantenimiento en el extranjero, más baratos.
Un equipo de funcionalidades construye una funcionalidad durante 6 meses, hace una “sesión de KT” de 1 hora con el equipo de mantenimiento en el extranjero y luego le entrega el código.
El equipo en el extranjero tiene algo de información sobre la funcionalidad, pero no la suficiente para manejar la deuda técnica existente; apenas mantiene las cosas funcionando sin que se incendien.
Cuando este ciclo se repite entre 100 y 1000 veces dentro de una organización, enseguida se llega a una situación en la que un frontend que originalmente podría haber tenido como máximo 250 mil líneas termina teniendo 2 millones.
Aunque entren los mejores ingenieros al nuevo equipo de funcionalidades, tienen que trabajar dentro de la caja que ya existe.
Si el mockup no coincide con los elementos, puede que el mockup esté mal, que el UI kit se haya actualizado o que haga falta refactorizar el UI kit existente, pero no hay presupuesto para eso.
Así que al equipo se le indica que copie el componente y lo modifique para su funcionalidad.
Al entregarlo al equipo de mantenimiento, el nuevo equipo tampoco quiere tocar el trabajo de funcionalidades existente, así que lo deja como está.
La gerencia no técnica no nota la diferencia y, después de años de equipos copiando y pegando para ajustar nuevas funcionalidades, en el codebase terminan apareciendo más de 50 componentes llamados “Button”.
Si el equipo tiene desarrolladores experimentados que valoran la eficiencia, y empujan por un sitio más eficiente o lo construyen más eficientemente desde el principio, la página puede mejorar.
Pero en la mayoría de los casos es un problema de incentivos.
Si a la gerencia no le importa, es probable que el programador prefiera hacerlo funcionar en la mitad del tiempo y sacar pendientes del backlog, en lugar de dedicar tiempo a mejorar la eficiencia.
Por eso los dispositivos lentos son un excelente filtro para evitar la basura.
Recién hace poco pasé de un LG flagship de 6 años a un Galaxy nuevo, y la diferencia de rendimiento fue enorme.
Eso no debería pasar.
En su lanzamiento era un dispositivo de gama muy alta, no es tan viejo y todavía funciona como nuevo.
Al ver que unos Galaxy S9 de prueba sufren las mismas dificultades, tampoco parece ser un problema exclusivo de mi teléfono.
Me habría gustado que incluyeran Amazon en las pruebas.
Según mi experiencia, el sitio web de Amazon está entre lo peor de lo peor en dispositivos móviles de más de 4 años.
Incluso en hardware móvil de gama alta relativamente reciente, era el único sitio de los que visitaba con regularidad que resultaba casi inutilizable.
Uso como teléfono diario un OnePlus 5 con Android 14 mediante LineageOS, y la experiencia de usuario en tareas que no son juegos es bastante aceptable.
Este teléfono tiene 6 GB de RAM, así que es comparable incluso con equipos de gama media actuales.
Mi única queja es que tuve que cambiar la batería y desmontar el teléfono es molesto.
En cambio, un Galaxy S8 con el mismo SoC, 4 GB de memoria y Android 9 stock con modificaciones de Samsung se traba sin parar.
La diferencia de 2 GB de memoria puede influir, pero la diferencia entre ambos teléfonos es como la noche y el día.
No sé si la gestión de memoria de Android 14 es mucho mejor que la de Android 9, o si el software lento y pesado de Samsung está frenando al dispositivo.
En cualquier caso, molesta que muchas empresas no prueben en dispositivos viejos y de gama baja.
Si apuntas a usuarios de todo el mundo, tienes que considerar que la mayor parte del mundo no usa el flagship más reciente.
En realidad no funciona tan mal así.
Claro, estoy de acuerdo en que no debería ser necesario hacerlo.
Eso sí, uso Firefox con todos los bloqueadores de anuncios, así que eso parece ayudar.
La tecnología actual es demasiado indiferente incluso con las personas que no están familiarizadas con la tecnología
Creo que los smartphones son el ejemplo más representativo
He visto a muchísima gente que casi no puede usar su propio dispositivo, o directamente no sabe cómo, y para ellos todo parece magia negra
El mayor problema es que se depende demasiado de la navegación por gestos, que al no ser visible es como si no existiera
Aunque uno pueda descifrar de alguna forma la barra de gestos del iPhone, no hay concepto de Centro de notificaciones ni de Centro de control
Estas personas no son tontas, y en otros campos pueden ser mucho mejores que yo
En tecnología, el problema no es la falta de esfuerzo, sino la falta de interfaces intuitivas
Para ver documentación real hay que llegar hasta la página de documentación del sitio de Apple y, si se indaga un poco más, aparece una página que apenas muestra algunos gestos disponibles
Sobre cuándo usar qué gesto no hay más que ejemplos de una oración
Y esto es solo hablando del sistema operativo
Me pregunto cuántas apps incluyen documentación que explique cómo se usan las funciones por gestos dentro de su propia app
https://support.apple.com/guide/iphone/learn-basic-gestures-...
Seguramente crecieron rodeadas de esos dispositivos
Por eso creo que no es un problema exclusivo de la tecnología moderna
En vez de permitir que el usuario elija el diseño y las interacciones que le convienen, el diseñador o el responsable de producto actúa como si supiera qué es lo mejor para todos los usuarios
Fue una de mis mayores quejas después de pasarme desde Android
No sé dónde está el botón de atrás, dónde está el botón de inicio, ni dónde están los botones en general
Odio de verdad la obsesión de Apple con el minimalismo, y cuando este teléfono muera volveré a Android
Este artículo, en escritorio, es básicamente difícil de leer para mí, que tengo 48 años
Al agregar lo siguiente al
bodyen las herramientas de desarrollo, se volvió legiblefont-size: 18px;line-height: 1.5em;max-width: 38rem;Así se ve lo fácil de leer y lo bonito que queda
Leo mucho a Dan Luu, pero cada vez tengo que modificarlo de esta manera
En serio, gente técnica: hacer que una página sea más legible solo cuesta 64 bytes adicionales
Esa página estaba casi bien; simplemente bastaba con ampliar con CTRL +
Esa página es casi puro texto y casi no tiene controles
Tú tienes una solución adecuada para tu caso de uso, y yo tengo la mía
Un lector con discapacidad visual también puede acceder con su propia solución
Como el código fuente es simple, las soluciones de accesibilidad también se vuelven razonablemente simples
Creo que Dan sabe cómo comunicarse de manera efectiva
Mantenerlo simple y no asumir que necesariamente se va a leer con los ojos
Uno mismo puede cambiar fácilmente la presentación según su propósito
Si no te gusta esa forma de presentación, puedes reformatearla tú mismo antes de leer
Dan, en la práctica, entregó el mensaje como un flujo de texto simple y fácil de manipular
Es muy probable que, en general, el público lector de Luu prefiera un enfoque con poco estilo
El usuario puede cambiar el tamaño de la ventana, el tamaño de la fuente, los colores, etc., según sus preferencias
No debería tener que cambiarlo archivo por archivo cada vez, y debería permitirse agregar y usar un archivo CSS de usuario que se aplique a varios archivos
Está en la página de configuración predeterminada de Firefox
Si un sitio web fuerza
font-size: 18px;, para un usuario que eligió una fuente más grande en el navegador el texto podría terminar viéndose más pequeñoPero también se puede usar el modo lectura del navegador, y en vez de dar varios pasos en las herramientas de desarrollo, basta con un clic
Como referencia, en Raspberry Pi 3 no se puede usar YouTube.
Esto pasó en el último año; antes se podían “ver” videos a unos 10–15 FPS, lo suficiente para ver videos de reparaciones en el taller.
Cuando salió Raspberry Pi Model B, es decir, el primer modelo, se podían reproducir videos 1080p del almacenamiento, ver YouTube y jugar.
No sé qué está haciendo YouTube, ni qué están haciendo otros servicios.
Si nos tomamos en serio la crisis climática y el cambio climático, habría que examinar con mucha severidad este tipo de maniobras de Google y Meta.
Quemar ciclos de CPU por lucro —si tuviera que adivinar improvisadamente, por la tecnología publicitaria—, es decir, que YouTube se arruine en dispositivos de bajo consumo, debería recibir una fuerte crítica en la prensa, y aunque la experiencia general de usuario sea peor, deberíamos usar servicios más eficientes.
La Pi3 tiene aceleración por hardware para x264, pero YouTube empezó a usar otros códecs desde hace un tiempo.
Incluso en una MacBook Air Intel de principios de 2021, con carga media, los videos se congelan al azar, algo que antes no pasaba.
Atacar ese lado para resolver el cambio climático tiene tan poco sentido como prohibir popotes de plástico o bolsas de plástico.
Como otro punto de referencia, el YouTube de hace 10 años habría funcionado perfectamente en ese hardware.
El culpable es la hinchazón general de la web y, más concretamente, los monstruos de abstracción que se volvieron comunes en JS.
Incluso a alguien que no cree en absoluto en la “crisis climática” se le puede decir que, con el tiempo, la artesanía y la calidad desaparecieron y eso produjo este desorden.
Por eso creo que es un tema en el que todos pueden estar de acuerdo a lo largo de todo el espectro político.
Podría ser al estilo de Consumer Reports, o un add-on que funcione como los ratings de Nielsen.
Esa persona de Discourse es un caso típico de alguien que diseña productos pensando en el mundo que le gustaría que existiera, no en el mundo real en el que vivimos.
Existen miles de millones de dispositivos con SoC de Qualcomm, seguirán existiendo y se seguirán fabricando y vendiendo.
Por más que se quejen, eso no va a cambiar.
Hay que aceptarlo y optimizar para esos dispositivos.
A los usuarios de esos dispositivos no les importan las quejas de los desarrolladores; si el software se cuelga, simplemente pensarán que son desarrolladores de software incompetentes.
Normalmente me gustan los textos de Dan Luu, pero sentí que este se desvió.
La tabla de LCP/CPU estaba buena, pero después de eso derivó en psicología de sillón.
A partir de unos comentarios aleatorios del fundador de Discourse, le pide al lector que imagine las actitudes de los ingenieros de software.
Incluso arrastra a Knuth por sus comentarios sobre rendimiento de un solo núcleo frente a multinúcleo y sobre Itanium, pero esos son puntos viejos de debate académico.
Sentí que el texto es demasiado endeble y depende demasiado de peleas de internet como para sostenerse bien.
Las palabras del fundador de Discourse simplemente son muy ilustrativas.
Si has usado la web recientemente, se ha inflado a un nivel inimaginable, al punto de que Google ahora dice que un Largest Contentful Paint de 2.4 segundos es rápido: https://blog.chromium.org/2020/05/the-science-behind-web-vit...
Ese material es de hace 4 años, así que probablemente ahora esté peor.
No hace falta ir muy lejos: desde YouTube cargando 2.5 MB de CSS en escritorio, hasta el fundador de Vercel presumiendo un sitio supuestamente muy rápido que, con apenas un poco de restricción, tarda 20 segundos en cargar: https://x.com/dmitriid/status/1735338533303259571
Si un servicio API simple para el frontend tiene un tiempo de respuesta de 500 ms, nadie se burla.
También me pregunto cuántos ingenieros saben cuánto cuestan sus servicios en la nube y se preocupan por eso.
La paralelización actual no se usa en el 90% del software, salvo en casos de uso especializados o cuando se ejecuta el mismo programa de un solo hilo sobre múltiples elementos de datos.
Tanto los lenguajes de programación como el hardware no soportan bien la paralelización de grano fino, y hacer que el software clásico sea rápido con un enfoque paralelo es muy difícil.
Más bien, Luu escribió de forma bastante generosa.
Lo de Knuth se parecía más a una queja de que se estaba acabando el almuerzo gratis que duró décadas.
Jeff Atwood solo fue elegido como ejemplo.
Famosos pensadores del desarrollo web con muchos seguidores siguen lanzando puntos de vista similares, y muchos seguidores simplemente los aceptan.
Todas las empresas dejaron de preocuparse, en especial las que estaban a la vanguardia de los estándares y las buenas prácticas de diseño web, como Google y Apple.
Google cerró hace poco HTML Gmail, que funcionaba rápido y bien incluso en un teléfono Android de 2008 con 256 MB de RAM y en versiones antiguas de Firefox.
Como era de esperarse, la nueva versión inflada con JavaScript mata el navegador.
Es un ejemplo extremo, pero los teléfonos de gama baja tienen 2 GB de RAM, y ya es difícil esperar un rendimiento razonable al navegar la web con estos dispositivos.
La web móvil es pésima, y eso es intencional para empujar a los usuarios hacia apps “nativas”.
Porque a empresas como Apple y Google les resulta más fácil recopilar datos y mostrar publicidad.
Sus sitios son terribles en móviles, y Decathlon también es terrible en escritorios que no son de alto rendimiento.
Pero ni siquiera promocionan la app de forma destacada, así que parece que simplemente son incompetentes.
Da la impresión de que los desarrolladores prueban todo solo en dispositivos de gama alta conectados al backbone.
RIP Google
El nuevo Reddit no se puede usar, y old Reddit está demasiado anticuado.
Twitch apenas se puede usar por los problemas del chat y del stream de video.
La lista sigue.
Si ya tienes la fórmula final, cualquier cambio se convierte en un mal cambio para garantizar puestos de trabajo.
Algún día los simios de este pedazo de barro se darán cuenta de que los empleos y el dinero no existen, pero para entonces será demasiado tarde.
No, eso es ahora.
RIP Humans