🚀 🥃 👩🏼‍🤝‍👩🏻 Precio JavaScript 2018 🥥 👩🏿‍🎤 🐚

La experiencia del usuario con sitios web interactivos puede incluir el paso de enviarles código JavaScript. A menudo, demasiado de este código. Si el sitio usa mucho JavaScript, esto afecta especialmente a los usuarios móviles. Por ejemplo, ¿alguna vez has estado en páginas web móviles que parecen estar listas para funcionar pero no responden a los clics en los enlaces o a los intentos de desplazarse por la página?

El código JavaScript que ingresa a los navegadores móviles sigue siendo el recurso más costoso, ya que, en muchos sentidos, puede retrasar la transición de las páginas a un estado en el que pueda interactuar con ellas. ¿Qué tipo de carga en los sistemas es JavaScript hoy? ¿Cómo analizar sitios? ¿Cómo acelerar la carga y el procesamiento por parte de los navegadores de páginas web interactivas? Eddie Osmani, cuya traducción publicamos hoy, decidió encontrar respuestas a estas y muchas otras preguntas que surgen con aquellos que usan JavaScript para desarrollar sitios web en 2018.

Disposiciones generales

Eche un vistazo a este informe, que demuestra el tiempo requerido para procesar el código JavaScript de CNN para varios dispositivos. Está construido sobre la base de mediciones tomadas por medio del proyecto WebPageTest.org ( aquí hay una tabla con los datos de origen para este informe, también hay datos en el sitio web de Walmart).

El tiempo que lleva procesar el código JS de cnn.com para varios dispositivos

Como puede ver, un teléfono de gama alta (iPhone 8) hace frente a la tarea de procesar el código JS en aproximadamente 4 segundos. Un teléfono de gama media (Moto G4) necesita unos 13 segundos para resolver el mismo problema. Un presupuesto, aunque sea un dispositivo moderno, como el Alcatel 1X, tarda unos 36 segundos.

Hoy hablaremos sobre las estrategias que los desarrolladores web pueden aplicar para crear sitios convenientes y modernos, por un lado, y por otro lado, para garantizar la carga, el procesamiento y el funcionamiento efectivos del componente JavaScript de estos sitios. Aquí, en resumen, están los puntos principales de nuestra conversación, que, por cierto, se basa en mi discurso reciente :

Para que los proyectos web funcionen rápidamente, solo necesita descargar el código JavaScript necesario para la página actual. El uso de tecnologías de división de código le permite organizar la carga lo más rápido posible de lo que el usuario definitivamente necesitará, y aplicar la técnica de carga diferida para otros fragmentos de código. Gracias a este enfoque, la página tiene la oportunidad de cargar más rápido que en otros casos y alcanzar rápidamente un estado en el que puede interactuar. Si usa sistemas que, por defecto, usan la separación de código basada en rutas, esto hace la diferencia.
Adhiérase a los límites establecidos para los parámetros del proyecto, el llamado "presupuesto de rendimiento", y aprenda a cumplirlos. Entonces, por ejemplo, espere que el tamaño del código JS minimizado y comprimido requerido para las páginas diseñadas para dispositivos móviles no exceda los 170 Kb . Al convertir dichos materiales a su forma normal, se obtienen aproximadamente 700 Kb de código. Tales restricciones son de gran importancia para el éxito del proyecto, sin embargo, solo ellas no pueden hacer milagrosamente un sitio lento rápidamente. La cultura del equipo , la estructura y los medios para monitorear la implementación de las reglas juegan un papel aquí. El desarrollo de proyectos sin presupuesto contribuye a una disminución gradual de la productividad y puede tener consecuencias desagradables.
Aprenda a auditar paquetes de JavaScript (ensamblajes) y reducir su tamaño. Es muy probable que los clientes tengan que descargar versiones completas de bibliotecas , mientras que solo se necesitan partes de ellas para que el proyecto funcione. Quizás el proyecto incluye polyfills para navegadores que no necesitan, y no se excluye la duplicación de código.
Cada interacción del usuario con el sitio es el comienzo de un nuevo período de espera, después del cual será posible trabajar con el sitio (esto es lo que se llama "tiempo de interactividad", TTI, Tiempo de Interactivo). Vale la pena considerar la optimización en este contexto. El tamaño del código transmitido es muy importante para redes móviles lentas, y el tiempo requerido para analizar el código JavaScript es para dispositivos con capacidades informáticas modestas.
Si el uso de JavaScript del lado del cliente no mejora su experiencia de usuario, considere usar JS en esta situación. Quizás en tal caso sería más rápido renderizar el código HTML en el servidor. Piense en limitar el uso de los marcos web del cliente, en usarlos solo para formar páginas que absolutamente no pueden prescindir de él. Tanto la representación en el servidor como la representación en el cliente, si estas tecnologías se usan incorrectamente, se convierten en una fuente de problemas graves.

Proyectos web modernos y el problema del uso excesivo de JavaScript

Cuando un usuario accede a su sitio, probablemente le esté enviando una gran cantidad de archivos, muchos de los cuales son scripts. Desde la perspectiva del navegador web, se parece a esto.

Así es como se siente un navegador, que está inundado de archivos

No importa cuánto me guste JavaScript, no puedo dejar de admitir el hecho de que siempre es la parte más cara y más difícil del sitio para que los navegadores procesen. En realidad, me gustaría hablar sobre por qué JavaScript puede convertirse en el principal problema del sitio.

JavaScript es la parte más difícil del sitio

Según el informe del Archivo JavaScript de julio sobre el uso de JavaScript, la página web promedio en estos días usa aproximadamente 350 KB de código JavaScript minificado y comprimido. Este código se descomprime en una secuencia de comandos de 1 MB que el navegador necesita procesar. Para que un usuario móvil pueda interactuar con dicha página, tendrá que esperar más de 14 segundos .

Una página promedio que contiene 350 KB de código JS comprimido se vuelve interactiva en un dispositivo móvil en aproximadamente 15 segundos

Si no sabe exactamente cómo afectan sus paquetes de JavaScript el tiempo que los usuarios tienen que esperar hasta que puedan interactuar con su sitio, eche un vistazo a la herramienta Lighthouse .

El tiempo de descarga de datos en redes móviles y su procesamiento en un procesador no rápido hacen una contribución importante mientras esperan que la página esté preparada para trabajar en dispositivos móviles.

Analicemos el estado de las cosas en el campo de las redes móviles observando los datos de OpenSignal . La siguiente figura, a la izquierda, muestra la disponibilidad de redes 4G en el mundo (cuanto más oscuro es el color con el que se pinta el territorio del país, mayor es la disponibilidad), las velocidades de transferencia de datos se muestran a la derecha (nuevamente, cuanto más oscura es la velocidad). Los países cuyo territorio está en gris no están incluidos en el estudio. Vale la pena señalar que en las zonas rurales, incluso en los EE. UU., La velocidad de transferencia de datos móviles puede ser un 20% más lenta que en las ciudades.

Disponibilidad de red 4G y velocidad de datos

Dijimos anteriormente que lleva una cierta cantidad de tiempo descargar y analizar 350 KB de código JS comprimido y minificado. Sin embargo, si observa sitios populares, resulta que envían a los usuarios mucho más código. Los datos que se muestran en la figura a continuación se toman de aquí . Son los tamaños de los paquetes de JavaScript desempaquetados de varios recursos web conocidos, como Google Sheets, cuyo código JS desempaquetado en plataformas de escritorio ocupa 5.8 MB.

Tamaños de ensamblaje JavaScript desempaquetados para varios recursos

Como puede ver, tanto en plataformas de escritorio como móviles, los navegadores a veces tienen que procesar varios megabytes de código JS para trabajar con varios sitios. La pregunta principal aquí es: ¿puede permitirse el lujo de usar volúmenes tan grandes de JavaScript?

JavaScript no es gratis

Según Alex Russell, los sitios que requieren grandes cantidades de JavaScript para funcionar simplemente no son accesibles para grandes capas de usuarios. Según las estadísticas, los usuarios no esperan (y no esperarán) la carga de dichos recursos.

¿Puedes permitírtelo?

Si tiene que enviar cantidades demasiado grandes de código JS a los usuarios, considere usar la tecnología de división de código para dividir paquetes en partes pequeñas, o reducir la cantidad de código usando el algoritmo de sacudida de árbol .

Los paquetes JS de sitios modernos a menudo incluyen lo siguiente:

Marco web del cliente o biblioteca de interfaz de usuario.
Una herramienta para administrar el estado de una aplicación (por ejemplo, Redux).
Polyfills (a menudo para navegadores modernos que no los necesitan).
Versiones completas de bibliotecas, y no solo aquellas partes que realmente se usan (por ejemplo, la biblioteca completa de Lodash, la biblioteca Moment.js en la versión con soporte para todos los estándares regionales).
Un conjunto de componentes de la interfaz de usuario (botones, encabezados, barras laterales, etc.).

Todo lo anterior contribuye al tamaño general del código que debe ser aceptado y procesado por el navegador del usuario. Naturalmente, cuanto más código, más tiempo le toma al navegador poder poner la página en condiciones de funcionamiento.

El proceso de cargar una página web es similar a la película en movimiento en el proyector, que captura tres pasos clave que responden las siguientes preguntas:

¿Esto está pasando? (¿Está sucediendo?)
¿De qué sirve esto? (¿Es útil?)
¿Se puede usar esto? (¿Es utilizable?)

Aquí se explica cómo imaginar estos pasos, que, a su vez, se pueden dividir en "cuadros" más pequeños, si continuamos la analogía con la película.

La carga de la página es un proceso. Recientemente, el enfoque de la industria web se ha desplazado a indicadores que reflejan la experiencia del usuario de trabajar con páginas web. En lugar de prestar toda nuestra atención a los domContentLoaded onload o domContentLoaded , ahora nos preguntamos si el usuario realmente puede trabajar con la página. Si hace clic en algo en la página, ¿habrá una reacción inmediata?

Proceso de carga de la página web

En el paso "¿Está sucediendo esto?" el sitio puede comenzar a transferir algunos datos al navegador. Aquí puede hacer preguntas sobre si se ha solucionado el acceso del navegador del usuario al servidor (por ejemplo, haciendo clic en un enlace determinado) y si el servidor ha comenzado a generar una respuesta.
En el paso "¿Cuál es el uso de esto?" el sitio muestra un texto u otro contenido que le permite al usuario, en primer lugar, aprender algo útil y, en segundo lugar, puede interesarle.
En el paso "¿Se puede usar esto?" el usuario puede comenzar una interacción completa con el sitio, lo que puede conducir a ciertos eventos.

Páginas interactivas y sus problemas.

Arriba, mencionamos un indicador como el tiempo de interactividad (Tiempo de interactividad, TTI). Hablemos de ello con más detalle. A continuación, en el dibujo animado preparado por Kevin Schaaf, puede ver cómo la página, no todos los materiales que se han descargado y procesado, hace que el usuario piense que puede realizar alguna acción, pero, de hecho, debido al hecho de que el JS correspondiente el código aún no se ha procesado completamente, esta acción no se puede realizar.

Usuarios molestos por páginas que tardan demasiado en prepararse

Para que una página sea interactiva, debe poder responder rápidamente a las interacciones del usuario. Las pequeñas cantidades de código JS que alimentan las páginas ayudan a reducir el tiempo necesario para preparar las páginas para el trabajo.

Si el usuario hace clic en el enlace o se desplaza por la página, debe ver que, en respuesta a sus acciones, sucede algo. Si la página no responde al impacto de los usuarios, no les gusta.

Aquí hay un informe generado en un entorno de prueba utilizando las herramientas de Lighthouse, que contiene un conjunto de indicadores (también hay tiempo para interactuar), centrado en cómo los usuarios perciben la página.

Informe de Lighthouse, que incluye indicadores que reflejan la percepción que el usuario tiene de la página.

Algo similar a lo que se muestra en la figura anterior ocurre cuando se usa la representación de un servidor en un determinado proyecto, y los resultados de lo que se genera en el servidor y el código JS que se usa para "revitalizar" la interfaz de usuario se transmiten al cliente (por ejemplo, , puede conectar controladores de eventos y algunos mecanismos adicionales responsables del comportamiento de la página).

Cuando el navegador está procesando dicho código que conecta eventos que probablemente necesitará el usuario, lo más probable es que todo esto se ejecute en el mismo hilo que procesa la entrada del usuario. Esta es la llamada corriente principal.

Cargar demasiado código JavaScript usando el hilo principal (por ejemplo, esto sucede cuando se usa la <script> ) tiene un efecto negativo en el tiempo de interactividad. La descarga del código JS que planea ejecutar en los trabajadores web o el almacenamiento en caché con los trabajadores del servicio no tiene un impacto negativo tan fuerte en TTI.

Aquí hay un video que muestra un ejemplo de un usuario que trabaja con un sitio fallido. Por lo general, el usuario puede seleccionar de forma segura las casillas de verificación o hacer clic en los enlaces. Sin embargo, si imita el bloqueo del hilo principal, el usuario no podrá hacer nada, ni marque la casilla ni haga clic en el enlace.

Intente minimizar las situaciones en las que el hilo principal puede estar bloqueado. Aquí está el material donde puede encontrar detalles sobre esto.

Vemos cómo los equipos con los que trabajamos sufren de JavaScript que actúa sobre TTI en muchos tipos de sitios.

JavaScript puede retrasar la salida de elementos visibles en modo interactivo

Esta situación puede ser un problema grave para muchas empresas. Arriba hay algunos ejemplos del motor de búsqueda de Google. Los elementos aparecen en la pantalla, parecen que ya es posible trabajar con ellos, pero si cantidades demasiado grandes de código JS son responsables de su funcionamiento, ingresan al modo de funcionamiento con cierto retraso. Esto puede no ser atractivo para los usuarios. Idealmente, todo lo que el usuario pueda interactuar debería estar operativo lo más rápido posible.

TTI y dispositivos móviles

Aquí están los TTI para news.google.com cuando se usa una conexión lenta a internet 3G. Aquí puede ver los datos en función de los cuales se construye este diagrama. Las mediciones se realizan mediante WebPageTest y Lighthouse.

TTI para news.google.com

Después de analizar estos datos, puede ver que entre los dispositivos de las categorías más bajas y más altas hay una brecha grave. Entonces, el dispositivo más poderoso en la prueba TTI es de aproximadamente 7 segundos. Como mínimo, ya son 55 segundos.

Aquí tenemos una pregunta sobre cuál debería ser la TTI. Creemos que debe esforzarse por hacer que las páginas sean más interactivas en dispositivos de rango medio conectados a redes 3G lentas en menos de 5 segundos.

Vale la pena luchar por TTI en 5 segundos

Quizás aquí diga que todos sus usuarios tienen teléfonos de alta gama y están conectados a redes rápidas. Sin embargo, ¿es realmente así? Quizás alguien esté conectado a una red Wi-Fi "rápida" en algún café, pero, de hecho, solo tiene a su disposición la característica de velocidad de las conexiones 2G o 3G. Al evaluar las capacidades de los usuarios, no se puede descartar la variedad de dispositivos y métodos de acceso a la red que utilizan.

Impacto de la reducción de tamaño del código JS en TTI

Estos son algunos ejemplos de cómo la reducción del tamaño del código de la página JS afectó a TTI.

El proyecto Pinterest redujo los paquetes JS de 2.5 MB a menos de 200 KB. El tiempo de interactividad disminuyó de 23 segundos a 5.6 segundos. Los ingresos de la compañía crecieron un 44%, el número de suscripciones aumentó un 753%, el número de usuarios semanales activos de la versión móvil del sitio creció un 103%.
AutoTrader redujo el paquete JS en un 56%, lo que resultó en una reducción de TTI de aproximadamente un 50%.
El recurso Nikkei.com redujo el tamaño del paquete JS en un 43%, lo que permitió que TTI mejore en 14 segundos.

Estos resultados sugieren que los sitios deben diseñarse para un entorno móvil flexible y, al mismo tiempo, intentar asegurarse de que no estén vinculados a grandes volúmenes de código JavaScript.

El diseño de sitios se basa en un entorno móvil flexible.

TTI tiene mucho que hacer. Por ejemplo, el uso de un dispositivo móvil para ver un sitio cuyas capacidades de red están limitadas por un determinado plan tarifario puede afectar este indicador, TTI puede verse afectado por el hecho de que el usuario trabaja a través de un punto de acceso Wi-Fi público, no particularmente rápido, o el hecho de que el usuario móvil está en constante movimiento, perdiendo periódicamente la red.

Cuando alguien está trabajando con su sitio en una situación similar a la que acabamos de describir, y al mismo tiempo, para garantizar que el recurso funciona, es necesario descargar y procesar una gran cantidad de código JS, para el usuario, la sesión con el sitio puede terminar vacía pantalla O, si el sitio aún muestra al menos algo en la pantalla, puede llevar mucho tiempo esperar antes de poder trabajar con él. Tales problemas, idealmente, pueden mitigarse simplemente reduciendo el tamaño del código JS necesario para que los sitios funcionen.

¿Por qué es tan caro JavaScript?

Para comprender por qué la preparación del código JavaScript para las páginas puede crear una gran carga en el sistema, hablemos de lo que sucede cuando el servidor envía datos al navegador.

Entonces, todo comienza con el hecho de que el usuario ingresa la URL del sitio al que desea ingresar en la barra de direcciones del navegador.

Todo comienza con ingresar una URL en la barra de direcciones del navegador

La solicitud se envía al servidor, que devuelve el marcado HTML al navegador. El navegador analiza este marcado y encuentra los recursos necesarios para formar la página: CSS, JavaScript, imágenes. Luego, el navegador debe solicitar todo esto al servidor y procesarlo.
Es en este escenario que todo sucede, por ejemplo, cuando se trabaja con Google Chrome.

La dificultad en todo este proceso es que JavaScript, al final, resulta ser el cuello de botella de todo el sistema. Idealmente, nos gustaría que el navegador muestre rápidamente una representación gráfica de la página, después de lo cual sería posible interactuar con ella. Pero, si JavaScript es un cuello de botella, entonces, después de mostrar algo en la pantalla, el usuario se ve obligado a examinar impotente con qué no puede trabajar.

Nuestro objetivo es garantizar que JavaScript deje de ser un cuello de botella en los escenarios modernos de interacción del usuario con los recursos web.

¿Cómo acelerar el trabajo con JavaScript?

La tarea de aceleración de JavaScript se puede dividir en varias subtareas. El tiempo dedicado a todo lo relacionado con JS es la suma de la carga, el análisis, la compilación y la ejecución del código.

La velocidad de JavaScript consiste en la velocidad de carga, análisis, compilación y ejecución de código

Todo esto significa que necesitamos velocidad tanto en la transferencia de código como en su procesamiento.
Si se pasa demasiado tiempo analizando y compilando el script en el motor JS, esto afecta la rapidez con la que el usuario puede interactuar con la página.

Considere algunos datos sobre los procesos anteriores. Aquí hay más información sobre cómo V8 , el motor de JavaScript utilizado en Chrome, pasa tiempo procesando páginas que contienen scripts.

Los pasos de análisis y compilación toman del 10-30% del tiempo en V8 al cargar una página

Los fragmentos que representan el tiempo requerido para analizar el código de los sitios populares se resaltan en naranja. El amarillo representa el tiempo de compilación. Juntas, estas dos etapas toman aproximadamente el 30% del tiempo total requerido para procesar el código JS de la página. El 30% es una cifra seria.

En Chrome 66, V8 compila el código en el hilo de fondo, lo que puede ahorrar hasta un 20% del tiempo de compilación. Sin embargo, el análisis y la compilación siguen siendo operaciones extremadamente costosas, por lo que rara vez se ve un script grande que comienza a ejecutarse en menos de 50 ms. después de cargar, incluso si se compila en el hilo de fondo.

¿En qué se diferencia JavaScript de otros recursos?

Debe tenerse en cuenta que el tiempo requerido, por ejemplo, para procesar un script con un tamaño de 200 Kb y para procesar una imagen que tenga el mismo tamaño, varía significativamente. En este ejemplo, la cantidad de datos transmitidos a través de la red puede ser la misma, el tiempo para su transferencia también. Esto no se puede decir sobre el costo de los recursos necesarios para convertir los datos en algo con lo que pueda trabajar.

200 KB de código JavaScript y un archivo JPEG del mismo tamaño son dos cosas diferentes.

La imagen JPEG debe decodificarse, rasterizarse y mostrarse. Y el paquete JS es necesario, si lo consideramos de manera simplista, cargar, analizar, compilar, ejecutar. De hecho, el motor tiene que resolver otros problemas en el proceso de procesamiento del código JS. En general, debe tenerse en cuenta que se gastan muchos más recursos del sistema en el procesamiento del código JavaScript, cuyo tamaño, en bytes, es comparable al tamaño de otros materiales.

Una de las razones que recientemente atrajeron tanta atención al tema de la velocidad de procesamiento del código JavaScript por parte de los navegadores es la increíble difusión de la tecnología móvil.

Web móvil y diversidad de dispositivos

Hay una gran variedad de dispositivos en el mundo web móvil. Si intenta, simplemente, clasificarlos por costo, entonces estos son teléfonos de nivel de entrada, ubicados en la región de $ 30, dispositivos de rango medio, cuyo costo no excede de $ 200, y dispositivos de gama alta, cuyo precio está en la región de $ 1000.

Varios dispositivos móviles

Si las circunstancias salen bien, entonces el sitio tendrá que funcionar en dispositivos de nivel medio y superior. Sin embargo, en realidad, no todos los usuarios tienen tales dispositivos.

Por lo tanto, la mayoría de los usuarios pueden trabajar en Internet desde dispositivos de nivel inicial e intermedio. Además, incluso si nos limitamos a estos dos niveles, el rango de capacidades de los dispositivos incluidos en ellos puede ser muy grande. Por ejemplo, los procesadores en algunos de ellos funcionarán a toda velocidad, y en algunos de ellos su frecuencia puede reducirse para ahorrar energía o evitar que los dispositivos se sobrecalienten.

Los procesadores comparables pueden tener diferentes tamaños de caché. Al final, los dispositivos pueden usar procesadores completamente diferentes, sin mencionar otros componentes del sistema. Como resultado, el tiempo requerido para procesar recursos, como JavaScript, dependerá en gran medida de las características de los dispositivos utilizados para ver los sitios. Además, los teléfonos de nivel básico se utilizan en todo el mundo, incluso en los Estados Unidos .

Aquí están los resultados de un estudio de los teléfonos inteligentes Android actualmente usados por newzoo . Como puede ver, el sistema operativo Android está instalado en el 75.9% de los teléfonos utilizados, mientras que se espera que en 2018 se les agreguen otros 300 millones de dispositivos. Muchos de estos nuevos dispositivos serán económicos.

Teléfonos inteligentes Android en 2018

Veamos cuánto tiempo lleva analizar y compilar JavaScript en varios dispositivos modernos. Aquí están los datos en bruto.

El tiempo requerido para procesar (analizar y compilar) 1 Mb de código JS sin comprimir (por ejemplo, puede ser de unos 200 Kb de código minimizado comprimido con gzip). Las mediciones se realizaron manualmente en dispositivos reales.

En la parte superior del diagrama hay dispositivos de primera clase, como el iPhone 8, que procesan los scripts con relativa rapidez. Si baja más, entonces ya hay dispositivos de gama media, como el Moto G4 y el muy simple Alcatel 1X. La diferencia entre estos dispositivos es visible a simple vista.

Con el tiempo, los teléfonos con Android se vuelven más baratos, pero no más rápidos . Por lo general, los teléfonos baratos usan procesadores débiles con un pequeño caché L2 / L3. Como resultado, si se enfoca en dispositivos de nivel superior, puede ignorar por completo las necesidades del usuario promedio que no tiene dicho dispositivo.

Volvamos, por ejemplo, con un sitio real, que ya hemos tocado. Las mediciones se llevaron a cabo utilizando WebPageTest, aquí están los datos de origen.

El tiempo que lleva procesar el código JS de cnn.com para varios dispositivos

En el iPhone 8 (usando el chip A11 ), el procesamiento tarda 9 segundos más rápido que en un teléfono de rango medio. Estamos hablando del hecho de que en el iPhone 8 el sitio será interactivo 9 segundos antes.

Ahora que cuando WebPageTest es compatible con Alcatel 1X (este teléfono se vendió en los EE. UU. Por alrededor de $ 100, se vendió al inicio de las ventas), podemos ver el " guión gráfico " del sitio web cnn.com cargando en teléfonos de nivel básico y medio. Alcatel 1X cargó completamente el sitio utilizando la red 3G en 65 segundos. Ni siquiera es "lento". Esto es simplemente inaceptable.

Descarga cnn.com con Alcatel 1X, Moto G gen 1, Moto G4

Este estudio sugiere que probablemente deberíamos dejar de pensar que todos nuestros usuarios están trabajando en redes rápidas en dispositivos potentes. Por lo tanto, las aplicaciones deben probarse en redes reales y en dispositivos reales. La variedad de dispositivos móviles en los que los sitios deben ejecutarse es un problema real.

No asuma que todos los usuarios usan redes rápidas y dispositivos potentes.

Ilya Grigorik dice que la volatilidad es lo que mata la experiencia del usuario. Incluso los dispositivos rápidos a veces pueden funcionar lentamente. Y las redes rápidas pueden ser lentas. La variabilidad puede ralentizar absolutamente cualquier cosa.

Si bien la variabilidad puede matar la experiencia del usuario, el desarrollo de proyectos web basados en dispositivos que no son los más productivos le permite hacer que los usuarios "rápidos" y "lentos" se sientan cómodos. Si su equipo puede analizar las estadísticas y comprender qué dispositivos se utilizan para trabajar con su sitio, esto le dará una pista sobre qué dispositivo probablemente vale la pena mantener en la oficina y lo usará para probar el sitio.

Los sitios de prueba están en dispositivos reales conectados a redes reales

Si la opción con su propio teléfono de gama media no le conviene, el proyecto WebPageTest ofrece acceso a teléfonos Moto G4 personalizados al elegir configuraciones de prueba móviles. Hay otras configuraciones allí.

Además, las pruebas deben realizarse en redes donde trabajan usuarios típicos. Anteriormente, hablé sobre la importancia de probar sitios en teléfonos de nivel básico y medio, y Brian Holt hizo el siguiente comentario excelente sobre este tema: es muy importante conocer a su audiencia. Él dice que conocer a la audiencia y optimizar el rendimiento de las aplicaciones para las necesidades de la audiencia es crucial.

Conoce a tu audiencia

Cabe señalar que no todos los sitios deberían funcionar bien en un dispositivo de nivel de entrada conectado a una red 2G. , — .

, , Google Analytics → Audience → Mobile → Devices. .

Google Analytics

, . — , , , , .

JavaScript — . : , , ( gzip , Brotli , Zopfli ).

,

.

JavaScript — .

—

-, , , , .

, , JavaScript, , , , .

JavaScript-,

, JS-, , , . , — ( code splitting ).

, JS- , , , . , .

—

, , , JS-, . , .

webpack Parcel . React , Vue.js Angular .

React

React- React loadable — , API, React, .

.

 import OtherComponent from './OtherComponent'; const MyComponent = () => ( <OtherComponent/> );

 import Loadable from 'react-loadable'; const LoadableOtherComponent = Loadable({ loader: () => import('./OtherComponent'), loading: () => <div>Loading...</div>, }); const MyComponent = () => ( <LoadableOtherComponent/> );