🙅🏿 💊 🚞 Prix JavaScript 2018 🍌 🚩 🚶

L'expérience utilisateur avec des sites Web interactifs peut inclure l'étape de leur envoyer du code JavaScript. Souvent - trop de ce code. Si le site utilise beaucoup de JavaScript, cela affecte particulièrement les utilisateurs mobiles. Par exemple, avez-vous déjà visité des pages Web mobiles qui semblent être prêtes à être consultées, mais qui ne répondent pas aux clics sur les liens ou aux tentatives de faire défiler la page?

Le code JavaScript qui pénètre dans les navigateurs mobiles est toujours la ressource la plus coûteuse, car il peut, à bien des égards, retarder la transition des pages vers un état dans lequel vous pouvez interagir avec elles. Quel type de charge sur les systèmes est JavaScript aujourd'hui? Comment analyser les sites? Comment accélérer le chargement et le traitement par les navigateurs de pages Web interactives? Eddie Osmani, dont nous publions la traduction aujourd'hui, a décidé de trouver des réponses à ces questions et à bien d'autres qui se posent à ceux qui utilisent JavaScript pour développer des sites Web en 2018.

Dispositions générales

Jetez un œil à ce rapport, qui montre le temps nécessaire pour traiter le code JavaScript de CNN pour divers appareils. Il est construit sur la base de mesures prises au moyen du projet WebPageTest.org ( voici un tableau avec les données sources de ce rapport, il y a aussi des données sur le site Walmart).

Le temps qu'il faut pour traiter le code JS cnn.com pour divers appareils

Comme vous pouvez le voir, un téléphone haut de gamme (iPhone 8) se charge de traiter le code JS en environ 4 secondes. Un téléphone de milieu de gamme (Moto G4) a besoin d'environ 13 secondes pour résoudre le même problème. Un budget, bien qu'un appareil moderne, comme l'Alcatel 1X, prend environ 36 secondes.

Aujourd'hui, nous allons parler des stratégies que les développeurs Web peuvent appliquer afin de créer des sites pratiques et modernes, d'une part, et d'autre part, pour assurer le chargement, le traitement et le fonctionnement efficaces du composant JavaScript de ces sites. Voici, en bref, les principaux points de notre conversation, qui, soit dit en passant, est basée sur mon récent discours :

Pour que les projets Web fonctionnent rapidement, il vous suffit de télécharger le code JavaScript nécessaire pour la page actuelle. L'utilisation des technologies de fractionnement de code vous permet d'organiser le plus rapidement possible le chargement de ce dont l'utilisateur aura certainement besoin et d'appliquer la technique de chargement paresseux pour d'autres fragments de code. Grâce à cette approche, la page a la possibilité de se charger plus rapidement que dans d'autres cas et d'atteindre rapidement un état dans lequel elle peut interagir. Si vous utilisez des systèmes qui, par défaut, utilisent la séparation de code basée sur l'itinéraire, cela fait une différence.
Respectez les limites fixées pour les paramètres du projet, le soi-disant «budget de performance», et apprenez à vous y conformer. Ainsi, par exemple, attendez-vous à ce que la taille du code JS minifié et compressé requis pour les pages conçues pour les appareils mobiles ne dépasse pas 170 Ko . Lors de la conversion de ces matériaux à leur forme normale, environ 700 Ko de code sont obtenus. De telles restrictions sont d'une grande importance pour la réussite du projet, mais elles seules ne peuvent miraculeusement pas accélérer un site lent. La culture d'équipe , la structure et les moyens de suivi de la mise en œuvre des règles jouent ici un rôle. Le développement de projets sans budget contribue à une baisse progressive de la productivité et peut entraîner des conséquences désagréables.
Découvrez comment auditer des bundles JavaScript (assemblys) et réduire leur taille. Il est très probable que les clients doivent télécharger des versions complètes des bibliothèques , alors que seules certaines parties sont nécessaires pour que le projet fonctionne. Peut-être que le projet comprend des polyfills pour les navigateurs dont ils n'ont pas besoin, et la duplication de code n'est pas exclue.
Chaque interaction de l'utilisateur avec le site marque le début d'une nouvelle période d'attente, à l'issue de laquelle il sera possible de travailler avec le site (c'est ce que l'on appelle le «temps d'interactivité», TTI, Time to Interactive). L'optimisation mérite d'être envisagée dans ce contexte. La taille du code transmis est très importante pour les réseaux mobiles lents, et le temps requis pour analyser le code JavaScript est pour les appareils avec des capacités informatiques modestes.
Si l'utilisation de JavaScript côté client n'améliore pas votre expérience utilisateur, envisagez d'utiliser JS dans cette situation. Dans un tel cas, il serait peut-être plus rapide de rendre le code HTML sur le serveur. Pensez à limiter l'utilisation des frameworks Web clients, à les utiliser uniquement pour former des pages qui ne peuvent absolument pas s'en passer. Le rendu sur le serveur et le rendu sur le client, si ces technologies sont mal utilisées, deviennent une source de graves problèmes.

Projets web modernes et problème d'utilisation excessive de JavaScript

Lorsqu'un utilisateur accède à votre site, vous lui envoyez probablement tout un tas de fichiers, dont beaucoup sont des scripts. Du point de vue d'un navigateur Web, cela ressemble à ceci.

Voici à quoi ressemble un navigateur, qui est inondé de fichiers

Peu importe combien j'aime JavaScript, je ne peux qu'admettre le fait que c'est toujours la partie du site la plus chère et la plus difficile à traiter pour les navigateurs. En fait, je voudrais expliquer pourquoi JavaScript peut devenir le principal problème du site.

JavaScript est la partie la plus difficile du site

Selon le rapport de juillet sur les archives JavaScript de JavaScript, la page Web moyenne utilise aujourd'hui environ 350 Ko de code JavaScript réduit et compressé. Ce code est décompressé en quelque chose comme un script de 1 Mo que le navigateur doit traiter. Pour qu'un utilisateur mobile puisse interagir avec une telle page, il devra attendre plus de 14 secondes .

Une page moyenne contenant 350 Ko de code JS compressé devient interactive sur un appareil mobile en 15 secondes environ

Si vous ne savez pas exactement comment vos offres JavaScript affectent le temps que les utilisateurs doivent attendre avant de pouvoir interagir avec votre site, jetez un œil à l'outil Lighthouse .

Le temps de téléchargement des données sur les réseaux mobiles et leur traitement sur un processeur non rapide apportent une contribution sérieuse en attendant que la page soit préparée pour le travail sur les appareils mobiles.

Analysons la situation dans le domaine des réseaux mobiles en examinant les données OpenSignal . La figure suivante, à gauche, montre la disponibilité des réseaux 4G dans le monde (plus la couleur avec laquelle le territoire du pays est peint est sombre - plus la disponibilité est élevée), les vitesses de transfert de données sont affichées à droite (encore une fois - plus sombre - plus la vitesse est élevée). Les pays dont le territoire est grisé ne sont pas inclus dans l'étude. Il convient de noter que dans les zones rurales, même aux États-Unis, la vitesse de transfert de données mobiles peut être 20% plus lente que dans les villes.

Disponibilité du réseau 4G et débit de données

Nous avons dit ci-dessus qu'il faut un certain temps pour télécharger et analyser 350 Ko de code JS minifié et compressé. Cependant, si vous regardez des sites populaires, il s'avère qu'ils envoient aux utilisateurs beaucoup plus de code. Les données présentées dans la figure ci-dessous sont extraites d'ici . Ce sont les tailles des paquets JavaScript décompressés de diverses ressources Web bien connues, telles que Google Sheets, dont le code JS décompressé sur les plates-formes de bureau prend 5,8 Mo.

Tailles d'assemblage JavaScript décompressées pour diverses ressources

Comme vous pouvez le voir, sur les plates-formes de bureau et mobiles, les navigateurs doivent parfois traiter plusieurs mégaoctets de code JS pour fonctionner avec différents sites. La question principale est la suivante: pouvez-vous vous permettre d'utiliser de si gros volumes de JavaScript?

JavaScript n'est pas gratuit

Selon Alex Russell, les sites qui nécessitent de très grandes quantités de JavaScript pour fonctionner ne sont tout simplement pas accessibles à de larges couches d'utilisateurs. Selon les statistiques, les utilisateurs n'attendent pas (et n'attendront pas) le chargement de ces ressources.

Pouvez-vous vous le permettre?

Si vous devez envoyer des quantités trop importantes de code JS aux utilisateurs, envisagez d'utiliser la technologie de fractionnement de code pour diviser les faisceaux en petites parties ou réduisez la quantité de code à l'aide de l' algorithme d'agitation d'arbre .

Les offres JS de sites modernes incluent souvent les éléments suivants:

Cadre Web client ou bibliothèque d'interface utilisateur.
Un outil pour gérer l'état d'une application (par exemple, Redux).
Polyfills (souvent pour les navigateurs modernes qui n'en ont pas besoin).
Versions complètes des bibliothèques, et pas seulement les parties réellement utilisées (par exemple, la bibliothèque Lodash entière, la bibliothèque Moment.js dans la version avec prise en charge de toutes les normes régionales).
Un ensemble de composants d'interface utilisateur (boutons, en-têtes, barres latérales, etc.).

Tout ce qui précède contribue à la taille globale du code qui doit être accepté et traité par le navigateur de l'utilisateur. Naturellement, plus il y a de code - plus il faut de temps au navigateur pour mettre la page en état de fonctionner.

Le processus de chargement d'une page Web est similaire au déplacement d'un film dans le projecteur, qui capture trois étapes clés qui répondent aux questions suivantes:

Est-ce que cela se produit? (Cela se produit-il?).
À quoi ça sert? (Est-ce utile?).
Peut-il être utilisé? (Est-il utilisable?).

Voici comment imaginer ces étapes, qui, à leur tour, peuvent être divisées en «images» plus petites, si nous continuons l'analogie avec le film.

Le chargement des pages est un processus. Récemment, l'industrie du Web s'est concentrée sur des indicateurs qui reflètent l'expérience utilisateur de travailler avec des pages Web. Au lieu de porter toute notre attention sur les onload ou domContentLoaded , nous nous demandons maintenant si l'utilisateur peut vraiment travailler avec la page. S'il clique sur quelque chose sur la page, y aura-t-il une réaction immédiate?

Processus de chargement de page Web

À l'étape "Est-ce que cela se produit?" le site peut commencer à transférer certaines données vers le navigateur. Ici, vous pouvez demander si l'accès du navigateur de l'utilisateur au serveur a été corrigé (par exemple, en cliquant sur un certain lien) et si le serveur a commencé à générer une réponse.
À l'étape «À quoi ça sert?» le site affiche du texte ou d'autres contenus qui permettent à l'utilisateur, d'une part, d'apprendre quelque chose d'utile, et d'autre part, de pouvoir l'intéresser.
À l'étape "Peut-on l'utiliser?" l'utilisateur peut commencer une interaction complète avec le site, ce qui peut entraîner certains événements.

Les pages interactives et leurs problèmes

Ci-dessus, nous avons mentionné un indicateur tel que le temps d'interactivité (Time to interactive, TTI). Parlons-en plus en détail. Ci-dessous, dans le dessin animé préparé par Kevin Schaaf, vous pouvez voir comment la page, pas tous les matériaux qui ont été téléchargés et traités, fait penser à l'utilisateur qu'il peut effectuer une action, mais, en fait, en raison du fait que le JS correspondant le code n'a pas encore été entièrement traité, cette action ne peut pas être effectuée.

Les utilisateurs bouleversés par les pages qui mettent trop de temps à se préparer

Pour qu'une page soit interactive, elle doit pouvoir répondre rapidement aux interactions des utilisateurs. Les petites quantités de code JS qui alimentent les pages aident à réduire le temps nécessaire pour préparer les pages au travail.

Si l'utilisateur clique sur le lien ou fait défiler la page, il doit voir que, en réponse à ses actions, quelque chose se produit. Si la page ne répond pas à l'impact des utilisateurs, ils ne l'aiment pas.

Voici un rapport généré dans un environnement de test à l'aide des outils Lighthouse, contenant un ensemble d'indicateurs (il y a aussi Time to interactive), axé sur la façon dont les utilisateurs perçoivent la page.

Rapport Lighthouse, qui comprend des indicateurs qui reflètent la perception de l'utilisateur de la page

Quelque chose de similaire à celui illustré dans la figure précédente se produit lorsqu'un rendu de serveur est utilisé dans un certain projet, et les résultats de ce qui est généré sur le serveur et le code JS qui est utilisé pour «revitaliser» l'interface utilisateur sont transmis au client (par exemple, il , peut connecter des gestionnaires d'événements et certains mécanismes supplémentaires responsables du comportement de la page).

Lorsque le navigateur traite un code qui connecte les événements dont l'utilisateur aura probablement besoin, tout cela sera probablement exécuté dans le même thread qui traite les entrées de l'utilisateur. Il s'agit du flux principal.

Charger trop de code JavaScript à l'aide du thread principal (par exemple, cela se produit lors de l'utilisation de la <script> ) a un mauvais effet sur le temps d'interactivité. Le téléchargement du code JS que vous prévoyez d'exécuter dans les employés Web ou la mise en cache avec les employés de service n'a pas un impact négatif aussi fort sur TTI.

Voici une vidéo qui montre un exemple d'un utilisateur travaillant avec un site défaillant. Habituellement, l'utilisateur peut cocher les cases en toute sécurité ou cliquer sur les liens. Cependant, si vous imitez le blocage du thread principal, l'utilisateur ne pourra rien faire - ni cocher la case, ni cliquer sur le lien.

Essayez de minimiser les situations dans lesquelles le thread principal peut être bloqué. Voici le matériel où vous pouvez trouver des détails à ce sujet.

Nous voyons comment les équipes avec lesquelles nous travaillons souffrent de l'action de JavaScript sur TTI sur de nombreux types de sites.

JavaScript est capable de retarder la sortie des éléments visibles en mode interactif

Cette situation peut être un sérieux problème pour de nombreuses entreprises. Ci-dessus sont quelques exemples du moteur de recherche Google. Des éléments apparaissent à l'écran, on dirait qu'il est déjà possible de travailler avec eux, mais si de trop grandes quantités de code JS sont responsables de leur fonctionnement, ils entrent en mode de fonctionnement avec un certain retard. Cela peut ne pas plaire aux utilisateurs. Idéalement, tout ce avec quoi l'utilisateur peut interagir doit être opérationnel le plus rapidement possible.

TTI et appareils mobiles

Voici les TTI de news.google.com lors de l'utilisation d'une connexion Internet 3G lente. Ici, vous pouvez voir les données sur la base desquelles ce diagramme est construit. Les mesures sont effectuées au moyen de WebPageTest et de Lighthouse.

TTI pour news.google.com

Après avoir analysé ces données, vous pouvez voir qu'entre les appareils des catégories les plus basses et les plus élevées, il existe un écart important. Ainsi, l'appareil le plus puissant du test TTI est d'environ 7 secondes. Au plus simple - c'est déjà 55 secondes.

Ici, nous avons une question sur ce que le TTI devrait être. Nous pensons que vous devez vous efforcer de rendre les pages plus interactives sur les appareils de milieu de gamme connectés à des réseaux 3G lents en moins de 5 secondes.

Il vaut la peine de s'efforcer de TTI en 5 secondes

Peut-être direz-vous ici que tous vos utilisateurs ont des téléphones haut de gamme et sont connectés à des réseaux rapides. Mais est-ce vraiment le cas? Peut-être que quelqu'un est connecté à un réseau Wi-Fi «rapide» dans un café, mais, en fait, seule la caractéristique de vitesse des connexions 2G ou 3G lui est accessible. En évaluant les capacités des utilisateurs, on ne peut ignorer la variété des appareils et des méthodes d'accès au réseau qu'ils utilisent.

Impact de la réduction de code JS sur TTI

Voici quelques exemples de la façon dont la réduction de la taille du code de page JS a affecté TTI.

Le projet Pinterest a réduit les bundles JS de 2,5 Mo à moins de 200 Ko. Le temps d'interactivité est passé de 23 secondes à 5,6 secondes. Les revenus de l'entreprise ont augmenté de 44%, le nombre d'abonnements a augmenté de 753%, le nombre d'utilisateurs hebdomadaires actifs de la version mobile du site a augmenté de 103%.
AutoTrader a réduit le package JS de 56%, ce qui a entraîné une réduction du TTI d'environ 50%.
La ressource Nikkei.com a réduit la taille du bundle JS de 43%, ce qui a permis à TTI de s'améliorer de 14 secondes.

Ces résultats suggèrent que les sites devraient être conçus pour un environnement mobile flexible, tout en essayant de s'assurer qu'ils ne sont pas liés à de gros volumes de code JavaScript.

La conception de sites est basée sur un environnement mobile flexible

TTI a beaucoup à faire. Par exemple, l'utilisation d'un appareil mobile pour visualiser un site dont les capacités réseau sont limitées par un certain plan tarifaire peut affecter cet indicateur, TTI peut être affecté par le fait que l'utilisateur travaille via un point d'accès Wi-Fi public, pas particulièrement rapide, ou par le fait que l'utilisateur mobile est en mouvement constant, perdant périodiquement le réseau.

Lorsque quelqu'un travaille avec votre site dans une situation similaire à celles que nous venons de décrire, et en même temps, pour s'assurer que la ressource fonctionne, il est nécessaire de télécharger et de traiter une grande quantité de code JS, pour l'utilisateur, la session avec le site peut finir vide l'écran. Ou, si le site affiche toujours au moins quelque chose à l'écran, il peut s'écouler très longtemps avant de pouvoir travailler avec. De tels problèmes, idéalement, peuvent être atténués en réduisant simplement la taille du code JS nécessaire au fonctionnement des sites.

Pourquoi JavaScript est-il si cher?

Afin de comprendre pourquoi la préparation de code JavaScript pour les pages peut créer une énorme charge sur le système, parlons de ce qui se passe lorsque le serveur envoie des données au navigateur.

Donc, tout commence par le fait que l'utilisateur entre l'URL du site auquel il souhaite accéder dans la barre d'adresse du navigateur.

Tout commence par la saisie d'une URL dans la barre d'adresse du navigateur

La demande est ensuite envoyée au serveur, qui renvoie le balisage HTML au navigateur. Le navigateur analyse ce balisage et trouve les ressources nécessaires pour former la page: CSS, JavaScript, images. Ensuite, le navigateur doit demander tout cela au serveur et le traiter.
C'est dans ce scénario que tout se passe, par exemple, lorsque vous travaillez avec Google Chrome.

La difficulté de tout ce processus est qu'en fin de compte, JavaScript s'avère être le goulot d'étranglement de tout le système. Idéalement, nous aimerions que le navigateur affiche rapidement une représentation graphique de la page, après quoi il serait possible d'interagir avec elle. Mais, si JavaScript est un goulot d'étranglement, alors, après avoir affiché quelque chose à l'écran, l'utilisateur est obligé d'examiner impuissant ce avec quoi il ne peut pas travailler.

Notre objectif est de garantir que JavaScript cesse d'être un goulot d'étranglement dans les scénarios modernes d'interaction des utilisateurs avec les ressources Web.

Comment accélérer le travail avec JavaScript?

La tâche d'accélération JavaScript peut être décomposée en plusieurs sous-tâches. Le temps passé sur tout ce qui concerne JS est la somme du chargement, de l'analyse, de la compilation et de l'exécution du code.

La vitesse JavaScript consiste en la vitesse de chargement, d'analyse, de compilation et d'exécution de code

Tout cela signifie que nous avons besoin de rapidité à la fois dans le transfert de code et dans son traitement.
Si vous passez trop de temps à analyser et à compiler le script dans le moteur JS, cela affecte la rapidité avec laquelle l'utilisateur peut interagir avec la page.

Considérez quelques données sur les processus ci-dessus. Voici plus sur la façon dont V8 , le moteur JavaScript utilisé dans Chrome, passe du temps à traiter les pages contenant des scripts.

Les étapes d'analyse et de compilation prennent 10 à 30% du temps en V8 lors du chargement d'une page

Les fragments représentant le temps requis pour analyser le code des sites populaires sont surlignés en orange. Le jaune représente le temps de compilation. Ensemble, ces deux étapes prennent environ 30% du temps total requis pour traiter le code JS de la page. 30% est un chiffre sérieux.

Dans Chrome 66, V8 compile du code dans le thread d'arrière-plan, ce qui peut économiser jusqu'à 20% du temps de compilation. Cependant, l'analyse et la compilation sont toujours des opérations extrêmement coûteuses, donc vous voyez rarement un gros script qui commence à s'exécuter en moins de 50 ms. après le chargement, même s'il est compilé dans le thread d'arrière-plan.

En quoi JavaScript est-il différent des autres ressources?

Il convient de garder à l'esprit que le temps nécessaire, par exemple, pour traiter un script d'une taille de 200 Ko, et pour traiter une image ayant la même taille, varie considérablement. Dans cet exemple, la quantité de données transmises sur le réseau peut être la même, l'heure de leur transfert aussi. Cela ne peut pas être dit au sujet du coût des ressources nécessaires pour transformer les données en quelque chose avec lequel vous pouvez travailler.

200 Ko de code JavaScript et un fichier JPEG de la même taille sont deux choses différentes.

L'image JPEG doit être décodée, tramée et affichée. Et le bundle JS est nécessaire, si nous le considérons de manière simplifiée, charger, analyser, compiler, exécuter. En fait, le moteur doit résoudre d' autres problèmes dans le processus de traitement du code JS. En général, il convient de garder à l'esprit que beaucoup plus de ressources système sont consacrées au traitement du code JavaScript, dont la taille, en octets, est comparable à la taille d'autres matériaux.

L'une des raisons qui a récemment attiré autant l'attention sur la question de la vitesse de traitement du code JavaScript par les navigateurs est l'incroyable diffusion de la technologie mobile.

Web mobile et diversité des appareils

Il existe une grande variété d'appareils dans le monde du Web mobile. Si vous essayez, tout simplement, de les classer par coût, alors ce sont des téléphones d'entrée de gamme, situés dans la région de 30 $, des appareils de milieu de gamme, dont le coût ne dépasse pas 200 $, et des appareils haut de gamme, dont le prix est d'environ 1000 $.

Divers appareils mobiles

Si les circonstances tournent bien, le site devra fonctionner sur des appareils de niveau moyen et supérieur. Cependant, en réalité, tous les utilisateurs ne disposent pas de tels appareils.

Ainsi, la plupart des utilisateurs peuvent travailler sur Internet à partir d'appareils de niveau initial et intermédiaire. De plus, même si nous nous limitons à ces deux niveaux, la gamme de capacités des appareils qui y sont inclus peut être très large. Par exemple, les processeurs de certains d'entre eux fonctionneront à pleine vitesse et, dans certains d'entre eux, leur fréquence peut être réduite pour économiser de l'énergie ou empêcher les appareils de surchauffer.

Les processeurs comparables peuvent avoir différentes tailles de cache. Au final, les appareils peuvent utiliser des processeurs complètement différents, sans parler des autres composants du système. Par conséquent, le temps requis pour traiter des ressources, telles que JavaScript, dépendra en grande partie des caractéristiques des appareils utilisés pour afficher les sites. De plus, les téléphones d'entrée de gamme sont utilisés dans le monde entier, même aux États-Unis .

Voici les résultats d'une étude des smartphones Android actuellement utilisés par newzoo . Comme vous pouvez le voir, le système d'exploitation Android est installé sur 75,9% des téléphones utilisés, alors qu'en 2018, 300 millions d'appareils supplémentaires devraient leur être ajoutés. Beaucoup de ces nouveaux appareils seront économiques.

Smartphones Android en 2018

Voyons combien de temps il faut pour analyser et compiler JavaScript sur divers appareils modernes. Voici les données brutes.

Le temps requis pour le traitement (analyse et compilation) 1 Mo de code JS non compressé (par exemple, il peut s'agir d'environ 200 Ko de code minifié compressé avec gzip). Les mesures ont été faites manuellement sur des appareils réels.

En haut du diagramme se trouvent des appareils de première classe, tels que l'iPhone 8, qui traitent les scripts relativement rapidement. Si vous descendez plus bas, il existe déjà des appareils de milieu de gamme, comme le Moto G4 et le très simple Alcatel 1X. La différence entre ces appareils est visible à l'œil nu.

Au fil du temps, les téléphones fonctionnant sous Android deviennent moins chers, mais pas plus rapides . En règle générale, les téléphones bon marché utilisent des processeurs faibles avec un petit cache L2 / L3. Par conséquent, si vous vous concentrez sur des appareils de niveau supérieur, vous pouvez ignorer complètement les besoins de l'utilisateur moyen qui ne dispose pas d'un tel appareil.

Revenons par exemple avec un vrai site, que nous avons déjà touché. Les mesures ont été effectuées à l'aide de WebPageTest, voici les données source.

Le temps qu'il faut pour traiter le code JS cnn.com pour divers appareils

Sur iPhone 8 (utilisant la puce A11 ), le traitement prend 9 secondes plus vite que sur un téléphone milieu de gamme. Nous parlons du fait que sur l'iPhone 8 le site sera interactif 9 secondes plus tôt.

Maintenant que lorsque WebPageTest prend en charge Alcatel 1X (ce téléphone a été vendu aux États-Unis pour environ 100 $, il a été vendu au début des ventes), nous pouvons voir le « storyboard » du site Web cnn.com se charger sur les téléphones d'entrée de gamme et de milieu de gamme. Alcatel 1X a entièrement chargé le site en utilisant le réseau 3G en 65 secondes. Ce n'est même pas «lent». C'est tout simplement inacceptable.

Téléchargez cnn.com avec Alcatel 1X, Moto G gen 1, Moto G4

Cette étude suggère que nous devrions probablement cesser de penser que tous nos utilisateurs travaillent sur des réseaux rapides sur des appareils puissants. Par conséquent, les applications doivent être testées dans de vrais réseaux et sur de vrais appareils. La variété d'appareils mobiles sur lesquels les sites doivent fonctionner est un vrai problème.

Ne présumez pas que tous les utilisateurs utilisent des réseaux rapides et des appareils puissants.

Ilya Grigorik dit que la volatilité est ce qui tue l'expérience utilisateur. Même les appareils rapides peuvent parfois fonctionner lentement. Et les réseaux rapides pourraient être lents. La variabilité peut ralentir absolument tout.

Bien que la variabilité puisse tuer l'expérience utilisateur, le développement de projets Web basés sur les appareils non les plus productifs vous permet de mettre à l'aise les utilisateurs "rapides" et "lents". Si votre équipe peut analyser les statistiques et comprendre quels appareils sont utilisés pour travailler avec votre site, cela vous donnera un indice sur quel appareil vaut probablement la peine d'être conservé au bureau et l'utiliser pour tester le site.

Les sites de test sont sur de vrais appareils connectés à de vrais réseaux

Si l'option avec votre propre téléphone milieu de gamme ne vous convient pas, le projet WebPageTest offre un accès à des téléphones Moto G4 personnalisés lors du choix des configurations de test mobiles. Il existe d'autres configurations.

De plus, des tests doivent être effectués sur des réseaux où travaillent des utilisateurs typiques. Plus tôt, j'ai parlé de l'importance de tester les sites sur les téléphones d'entrée de gamme et de milieu de gamme, et Brian Holt a fait l' excellente remarque suivante à ce sujet: il est très important de connaître votre public. Il dit qu'il est crucial de connaître l'audience et d'optimiser les performances des applications pour les besoins de l'audience.

Connaissez votre public

Il convient de noter que tous les sites ne devraient pas fonctionner correctement sur un appareil d'entrée de gamme connecté à un réseau 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/> );