Dans un article rĂ©cent sur Hacker News, il a Ă©tĂ© soutenu que la vitesse des pages Web ne s'amĂ©liorait pas mĂȘme si la vitesse d'Internet augmentait.
Dans mon article, j'expliquerai pourquoi une telle conclusion ne peut ĂȘtre tirĂ©e des donnĂ©es initiales.
Nous examinerons également les changements qui se sont produits sur les appareils et le Web au cours des dix derniÚres années et comment ces mesures ont affecté la vitesse du Web.
Interprétation des données d'archive HTTP
Ce graphique, extrait d'un article du Nielsen Norman Group, nous montre clairement que l'augmentation de la bande passante mobile n'a pas entraßné des temps de chargement des pages plus rapides.
Cependant, la vitesse de connexion utilisée par l'archive HTTP n'a pas augmenté pendant cette période.
Au lieu de cela, il a chuté en 2013, passant du WiFi à une connexion 3G émulée .
Depuis 2013, la mĂ©trique onLoad a augmentĂ© de 55%, passant de 12,7 secondes Ă 19,7 secondes. Si vous avez achetĂ© un tĂ©lĂ©phone en 2013 et que vous vous ĂȘtes connectĂ© Ă Internet via 3G depuis lors, le Web est devenu plus lent pour vous.
Avant de parler de l'évolution des appareils et du Web au cours des dix derniÚres années, voici quelques notes sur la façon d'interpréter ces données.
Pourquoi regarder onLoad?
L'événement est
loaddistribué par la page lorsque toutes les ressources de la page telles que les scripts et les images ont été téléchargées.
Si l'en-tĂȘte de la page est rendu rapidement, mais que la page charge Ă©galement 20 images supplĂ©mentaires ci-dessous, la mĂ©trique onLoad nous indiquera que la page est lente.
Une autre page peut initialement ne pas rendre quoi que ce soit d'utile, mais commence seulement à charger des ressources supplémentaires et à rendre le contenu déjà fortement aprÚs l'événement onLoad. Cependant, une telle page apparaßtra rapidement.
Par conséquent, onLoad n'est pas trÚs approprié pour mesurer si un utilisateur perçoit une page aussi vite.
Pourquoi se donner la peine de regarder cette métrique? Parce qu'il est utilisé depuis longtemps et que l'archive HTTP le suit depuis 2010. Des métriques plus récentes telles queFirst Contentful Paint, ou Time to Interactive, n'a été ajouté à l'archive HTTP qu'en 2017.
Doit-on s'attendre à une augmentation de la bande passante pour accélérer le chargement des pages?
L'augmentation de la bande passante n'accĂ©lĂ©rera le chargement des pages que si la bande passante est un goulot d'Ă©tranglement Ă un moment donnĂ©. Cela n'aidera pas si vous ĂȘtes sur une connexion gigabit et le temps de transmission du signal dans les deux sens sur le rĂ©seau est Ă©gal Ă une seconde.
Cependant, la connexion émulée HTTP Archive 3G à 1,6 Mbps est trÚs lente, vous devez donc vous attendre à une augmentation significative de la vitesse lorsque vous augmentez votre bande passante. Le site Web moyen télécharge 1,7 Mo de données en 2020, ce qui signifie qu'il faudra au moins 9 secondes pour télécharger avec une vitesse de connexion HTTP Archive.
Autres subtilités de HTTP Archive
Dans cet article, je parlerai beaucoup du «site Web moyen». Il est à noter que HTTP Archive ne collecte des données que sur les pages maßtres, pas sur les pages plus profondes dans la hiérarchie du site. De plus, au fil du temps, le corpus de domaines testés s'est agrandi.
Les tests n'Ă©taient pas toujours effectuĂ©s sur le mĂȘme appareil. Ă l'origine, un iPhone 4 physique Ă©tait utilisĂ© et aujourd'hui, les tests sont effectuĂ©s sur un appareil Android Ă©mulĂ©.
Dans cet article, nous examinons les valeurs métriques médianes. Si la plupart des sites Web sont rapides, mais qu'un site Web sur cinq ralentit le téléphone pendant 20 secondes, nous ne pourrons pas améliorer cette métrique.
Vitesse sur les ordinateurs de bureau
Dans cet article, nous examinerons la vitesse sur les appareils mobiles américains. Cependant, si vous regardez les données de bureau de l'article d'origine, il convient de noter qu'en 2013, la bande passante de test a augmenté et la latence a diminué.
Comment les réseaux et appareils mobiles ont-ils évolué au cours des dix derniÚres années?
Regardons quatre facteurs:
- bande passante réseau
- délai réseau
- vitesses du processeur
- vitesse du navigateur
Bande passante mobile aux Ătats-Unis
Ce graphique montre la bande passante moyenne du réseau mobile américain au fil des ans, sur la base de diverses sources. Il est passé de 1 Mbps à environ 30 Mbps.
(Je n'ai pas collectĂ© ces donnĂ©es trĂšs soigneusement. Par exemple, je n'ai pas toujours dĂ©terminĂ© si la date de collecte des donnĂ©es Ă©tait la mĂȘme que celle de leur publication. Mes sources sont disponibles ici .)
Latence sur les réseaux mobiles américains
Les données pour ce paramÚtre étaient plus difficiles à trouver, mais les résultats montrent que la latence est passée d'environ 200 ms (2011) à 50 ms (2020).
Vitesses du processeur mobile
Je n'ai pas pu trouver de donnĂ©es sur les vitesses mobiles moyennes aux Ătats-Unis. Cependant, Alex Russell et Surma publiĂ© le calendrier note GeekBench 4 ainsi que la libĂ©ration de diffĂ©rents tĂ©lĂ©phones pendant des annĂ©es.
MĂȘme les tĂ©lĂ©phones Ă©conomiques sont 4 fois plus rapides et les iPhones 20 fois plus puissants.
Comment les navigateurs ont-ils changé?
Au cours des dix derniÚres années, beaucoup de travail a été fait pour améliorer les navigateurs. JavaScript est devenu une partie encore plus importante du Web, de nombreuses améliorations sont donc concentrées dans ce domaine.
Sur la base de ce graphique du blog V8, la consommation CPU par page a été réduite quatre fois.
La mise en réseau
Le travail des navigateurs avec le rĂ©seau s'est Ă©galement amĂ©liorĂ©. Par exemple, depuis l'introduction de HTTP / 2 en 2015, 64% des requĂȘtes sont traitĂ©es via HTTP / 2.
Comment les sites Web ont-ils changé?
Jetons un coup d'Ćil aux donnĂ©es de l'archive HTTP pour comprendre comment les sites Web ont changĂ©.
Poids de la page
Le poids des pages mobiles a augmenté de 337% entre 2013 et 2020 . Cela est principalement dû à l'augmentation du nombre d'images et de code JavaScript.
Le volume des autres ressources a également beaucoup augmenté - je suppose qu'il s'agit principalement de vidéo.
Le graphique commence en 2013 car en octobre 2012, les archives HTTP ont changĂ© la mĂ©thodologie de mesure. Auparavant, le poids de la page Ă©tait sous-estimĂ© car le test Ă©tait terminĂ© aprĂšs le dĂ©clenchement de l'Ă©vĂ©nement de chargement de page, mĂȘme si d'autres donnĂ©es Ă©taient chargĂ©es aprĂšs lui.
Runtime JavaScript
Si, malgré l'accélération des réseaux mobiles, les pages ralentissent, alors JavaScript est le coupable le plus probable. Malheureusement, les archives HTTP n'ont commencé à collecter ces données qu'à la fin de 2017, et elles semblent stables depuis.
La baisse à la mi-2018 est probablement due à une modification du corpus des URL testées.
Notez que la durĂ©e absolue de la performance (0,5 seconde) est infĂ©rieure Ă ce que l'on trouve habituellement dans des instruments comme le phare. Ces outils ralentissent gĂ©nĂ©ralement l'exĂ©cution de JavaScript pour Ă©muler un appareil mobile, mais dans les tests HTTP Archive, ce systĂšme Ă©tait dĂ©fectueux . Par consĂ©quent, bien que ce chiffre puisse ĂȘtre rĂ©aliste pour les tĂ©lĂ©phones de milieu de gamme, on pense gĂ©nĂ©ralement que les tĂ©lĂ©phones Ă petit budget sont environ quatre fois plus lents.
RĂ©pondre Ă la question si le Web est devenu plus lent
Le Web est-il devenu plus lent? En général, cela dépend de votre appareil, de la connexion réseau et des sites Web les plus fréquemment visités.
Nous aurions besoin de mesurer les donnĂ©es de vitesse du monde rĂ©el pour obtenir une distribution qui montre comment la perception du Web change au fil du temps par diffĂ©rents utilisateurs. En outre, la question demeure, l'expĂ©rience de quelqu'un qui ouvre des milliers de pages par jour doit-elle ĂȘtre comptĂ©e de la mĂȘme maniĂšre que l'expĂ©rience de quelqu'un qui ne visite Facebook qu'une fois par semaine?
Je ne dispose pas de données détaillées pour les utilisateurs individuels, mais nous pouvons examiner ce problÚme sous plusieurs angles différents:
- Données utilisateur réelles du rapport Chrome UX (CrUX)
- Modélisation naïve basée sur les changements de site Web et d'appareils
J'ai également essayé de télécharger d'anciennes versions de pages depuis archive.org et de les tester avec Lighthouse, mais je n'ai pas pu obtenir de données significatives dans un délai raisonnable. Par exemple, des images sont parfois absentes de l'archive de page.
Données du rapport d'expérience utilisateur Chrome
La grande limitation des données CrUX est qu'elles n'ont commencé à collecter qu'à partir de la fin de 2017. Mais nous pouvons toujours les utiliser pour voir si le Web a ralenti au cours des deux derniÚres années et demie.
Notez que contrairement Ă l'archive HTTP, CrUX examine l'ensemble du domaine, pas seulement les pages principales.
Nous considérerons le 75e centile comme des données, ce qui signifie que pour 75% des utilisateurs, les pages se chargent à cette vitesse ou plus rapidement.
(Je prends la moyenne, et non la médiane, sur plusieurs sites Web, ce qui n'est pas tout à fait correct.)
Temps de chargement des pages aux Ătats-Unis
Les donnĂ©es CrUX pour les Ătats-Unis ne montrent aucune dĂ©gradation de la vitesse de la page.
La mĂ©trique onLoad montre une lĂ©gĂšre amĂ©lioration, probablement due Ă une augmentation du dĂ©bit. Ou peut-ĂȘtre que plus d'action se produit maintenant aprĂšs le chargement initial de la page.
Les mĂ©triques de peinture semblent ĂȘtre assez stables. La plus grande peinture de contenu (temps de chargement du contenu principal) est une nouvelle mĂ©trique qui n'a Ă©tĂ© collectĂ©e que depuis la mi-2019.
Le reste du monde
La tendance Ă la baisse de la mĂ©trique onLoad aux Ătats-Unis est cohĂ©rente avec les donnĂ©es mondiales. Cependant, il existe des diffĂ©rences significatives dans les temps de chargement des pages entre les pays, par exemple, les temps de chargement en Inde sont presque le double de ceux de la CorĂ©e du Sud.
Nous pouvons utiliser les données CrUX pour mieux comprendre les données HTTP Archive. En janvier 2020, les archives HTTP ont signalé un temps de chargement médian (50e centile) basé sur des données synthétiques de 18,7 secondes.
En revanche, CrUX estime que les temps de chargement ne sont que de 5,8 secondes, ce qui correspond au 75e centile.
(Notez que les valeurs globales (Global) sont prises simplement comme une moyenne et ne sont pas pondérées par la population.)
Modélisation des temps de chargement des pages
Nous pouvons créer un modÚle théorique de la maniÚre dont les modifications apportées aux appareils, aux réseaux et aux sites Web affectent la vitesse globale.
Le modÚle ne sera pas parfait, mais j'espÚre qu'il nous donnera un aperçu.
Temps de téléchargement de la page théorique
Le poids de la page a augmenté au fil du temps, tout comme la bande passante. Le temps d'aller-retour du signal a également diminué.
Il faudrait 1,7 seconde pour télécharger un fichier de la taille du site Web mobile médian en 2013. Si notre vitesse de connexion n'a pas changé depuis, cela prendrait aujourd'hui 4,4 secondes. Mais avec la vitesse de connexion moyenne d'aujourd'hui, cela ne prend que 0,9 seconde.
En pratique, un site Web ne se composera pas d'une seule demande, mais d'autres facteurs, tels que la vitesse de traitement et la latence du serveur, affecteront la vitesse de chargement de la page. Le temps onLoad selon l'archive HTTP est 2 à 3 fois plus élevé que cette limite inférieure.
Mais nous pouvons toujours l'utiliser comme indicateur qu'une latence plus faible et une bande passante accrue en général ont aidé les sites Web à se charger plus rapidement.
(Je commence Ă partir de 2013, et non de 2011, car la mĂ©trique de poids de la page HTTP Archive n'a commencĂ© Ă ĂȘtre mesurĂ©e de maniĂšre cohĂ©rente qu'Ă partir de ce moment.)
CPU
Je ne comprends pas trĂšs bien comment aborder ce paramĂštre, mais je ferai quelques hypothĂšses.
Une personne qui a utilisé un Galaxy S4 en 2013 et utilise désormais un Galaxy S10 a cinq fois la puissance de traitement du processeur. Supposons que les navigateurs soient devenus quatre fois plus efficaces depuis lors. Si nous multiplions directement ces deux nombres, nous obtenons une amélioration de 20 fois.
Depuis 2013, le poids de JavaScript sur une page a Ă©tĂ© multipliĂ© par 3,7, passant de 107 Ko Ă 392 Ko. La minification et la compression se sont probablement amĂ©liorĂ©es depuis, de sorte que la mĂȘme quantitĂ© de code JavaScript tient dĂ©sormais dans moins d'octets. Arrondissons ce facteur Ă six. Imaginez que le poids de JavaScript sur une page soit proportionnel au temps d'exĂ©cution de JavaScript.
En conséquence, nous obtiendrons toujours une augmentation de vitesse de 3,3x.
Conclusion
Les sites Web exécutent plus de code aujourd'hui et sont plusieurs fois plus volumineux que les sites Web d'il y a dix ans. Cependant, je ne pense pas que le Web mobile soit devenu globalement plus lent pour les utilisateurs.
Dans le mĂȘme temps, de plus en plus de personnes utilisent dĂ©sormais le Web mobile . Cela dĂ©grade la vitesse globale perçue du Web.
La puissance de calcul des appareils mobiles rattrape la puissance des appareils de bureau, tout comme la bande passante des rĂ©seaux. Dans le mĂȘme temps, de nouveaux appareils moins chers au niveau du budget font leur apparition.
Ces donnĂ©es peuvent ĂȘtre visualisĂ©es sous deux angles. D'une part, le Web s'accĂ©lĂšre progressivement. En revanche, les progrĂšs des rĂ©seaux et des appareils reprĂ©sentent une occasion manquĂ©e de gains de productivitĂ© plus importants.
La publicité
VDSina propose des serveurs bon marché avec paiement quotidien, chaque serveur est connecté à un canal internet de 500 Mégabits et est protégé des attaques DDoS gratuitement!
