L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2025 !
J'ai utilisé le Web pendant une journée avec un budget de 50 Mo
Cet article fait partie d'une série dans laquelle je tente d'utiliser le Web sous différentes contraintes, ce qui représente un compte tenu de la démographie de l'utilisateur. J'espère mettre en évidence les difficultés rencontrées par de vraies personnes, qui sont évitables si nous concevons et développons nos ressources de manière à répondre à leurs besoins.
La dernière fois, j'ai navigué sur le Web pendant une journée avec Internet Explorer. 8 . Cette fois, j'ai navigué sur Internet pendant un jour avec un budget de 50 Mo.
Pourquoi 50 Mo
Nous sommes nombreux à avoir la chance de pouvoir utiliser des forfaits mobiles qui permettent plusieurs giga-octets de transfert de données par mois. En cas d'échec, nous sommes généralement en mesure de nous connecter à des réseaux WiFi domestiques ou publics disposant de connexions haut débit rapides et de données effectivement illimitées.
Mais il existe des régions du monde où le coût des données mobiles est prohibitif et où il existe peu ou pas aucune infrastructure à large bande.
Les gens achètent souvent des paquets de données de quelques dizaines de mégaoctets à la fois, ce qui fait d'un gigaoctet un volume de données relativement important et donc coûteux.
– Dan Howdle, analyste des télécommunications grand public chez Cable.co .uk
À quel prix parlons-nous?
Le coût des données mobiles
Une étude réalisée en 2018 par cable.co.uk a révélé que le Zimbabwe était le pays le plus cher du monde les données mobiles, où 1 Go coûtent en moyenne 75,20 USD, allant de 12,50 USD à 138,46 USD. La fourchette de prix énorme est due au fait que de plus petites quantités de données sont très chères ce qui est d'autant plus avantageux que le plan de données auquel vous vous engagez est proportionnellement moins coûteux. Vous pouvez lire la méthodologie de l'étude pour plus d'informations.
Le Zimbabwe n'est en aucun cas un cas isolé. La Guinée équatoriale, Sainte-Hélène et les îles Falkland viennent ensuite, avec 1 Go de données coûtant respectivement 65,83 USD, 55,47 USD et 47,39 USD. Ces pays combinent généralement une infrastructure technique médiocre et une adoption limitée, ce qui signifie que les données sont coûteuses à fournir et n’ont pas l’économie d’échelle permettant de réduire les coûts.
Les données coûtent également cher dans certaines parties de l’Europe. Un gigaoctet de données en Grèce vous coûtera 32,71 $; en Suisse, 20,22 $. À titre de comparaison, le même montant de données coûte 6,66 USD au Royaume-Uni et 12,37 USD aux États-Unis. À l’opposé, l’Inde est l’endroit le moins cher au monde pour les données, avec un coût moyen de 0,26 dollar. Le Kirghizistan, le Kazakhstan et l'Ukraine suivent à 0,27 USD, 0,49 USD et 0,51 USD par Go respectivement.
La vitesse des réseaux de téléphonie mobile varie également considérablement d'un pays à l'autre. Il est peut-être surprenant de constater que les utilisateurs de bénéficient de vitesses plus rapides sur un réseau mobile que le Wi-Fi dans au moins 30 pays, dont l'Australie et la France. La Corée du Sud a la vitesse de téléchargement mobile la plus rapide avec une moyenne de 52,4 Mbps, mais l'Irak a la vitesse de téléchargement la plus lente, avec une moyenne de 1,6 Mbps et une moyenne de 0,7 Mbps. Les États-Unis se classent au 40ème rang mondial pour les vitesses de téléchargement mobile, à environ 34 Mbps, et risquent de prendre davantage de retard alors que le monde se dirige vers la 5G.
En ce qui concerne le type de connexion de réseau mobile, 84,7% Au Royaume-Uni, le nombre de connexions utilisateur est en 4G, contre 93% aux États-Unis et 97,5% en Corée du Sud. Cela se compare à moins de 50% en Ouzbékistan et à moins de 60% en Algérie, en Équateur, au Népal et en Irak.
Le coût des données à large bande
Parallèlement, une étude du coût du large bande en 2018 Montre qu'une connexion à large bande au Niger coûte 263 $ 'par mégabit par mois'. Cet indicateur est un peu difficile à comprendre, alors voici un exemple: si le coût moyen des forfaits haut débit dans un pays est de 22 $ et que la vitesse de téléchargement moyenne offerte par les forfaits est de 10 Mbps, le coût «par mégabit par mois» be $ 2.20.
C'est une métrique intéressante, qui reconnaît que la vitesse du haut débit est un facteur aussi important que le plafond de données. Un coût de 263 dollars suggère une combinaison de haut débit extrêmement lent et extrêmement coûteux. À titre de référence, le chiffre indiqué est de 1,19 USD au Royaume-Uni et de 1,26 USD aux États-Unis.
Ce qui est peut-être plus facile à comprendre, c’est le coût moyen d’un forfait large bande. Il convient de noter que cette étude recherchait les offres de large bande les moins chères, ignorant si ces offres avaient ou non un plafond de données, fournit donc un chiffre approximatif utile plutôt que le coût des données en tant que tel.
En ce qui concerne le coût de l'offre, la Mauritanie a la bande large la plus chère du monde, avec une moyenne de 768,16 $ (une fourchette de 307,26 $ à 1 368,72 $). Ce coût énorme inclut la construction de lignes physiques menant à la propriété, car il en existe déjà peu en Mauritanie. À 0,7 Mbps, la Mauritanie possède également l’un des réseaux haut débit les plus lents au monde.
Taïwan dispose du plus haut débit au monde à une vitesse moyenne de 85 Mbps. Le Yémen a le plus lent, à 0,38 Mbps. Mais même les pays dotés d’une infrastructure à large bande bien établie ont ce qu’on appelle des «non-spots». Le Royaume-Uni se classe au 34e rang sur 207 pays pour la vitesse du haut débit, mais en juillet 2019, il existait encore au Royaume-Uni une école sans haut débit .
Le coût moyen d'un forfait haut débit au Royaume-Uni est de 39,58 $ US. , et aux États-Unis est 67,69 $. La moyenne la moins chère dans le monde est celle de l'Ukraine, à seulement 5 dollars, bien que le large bande le moins cher ait été trouvé au Kirghizistan (1,27 dollar – contre une moyenne nationale de 108,22 dollars).
Le Zimbabwe était le pays le plus coûteux en données mobiles. les statistiques ne sont pas bien meilleures pour le haut débit, avec un coût moyen de 128,71 $ et un coût «par mégabit par mois» de 6,89 $.
Coût absolu par rapport au coût en termes réels
Tous les coûts décrits jusqu'à présent sont les coûts absolus en USD, basés sur les taux de change en vigueur au moment de l’étude. Ces coûts n’ont pas été comptabilisés dans le coût de la vie ce qui signifie que, dans de nombreux pays, le coût est en réalité bien plus élevé en termes réels.
Je vais limiter ma navigation actuelle à 50 Mo. Le Zimbabwe coûterait environ 3,67 dollars sur un tarif de données mobiles. Cela peut sembler peu, mais les enseignants du Zimbabwe étaient en grève cette année parce que leurs salaires étaient tombés à seulement 2,50 dollars par jour .
À titre de comparaison, 3,67 dollars équivaut à la moitié du salaire minimum de à 7,25 dollars US. les USA . En tant que Zimbabwéen, je devrais travailler environ un jour et demi pour gagner l’argent nécessaire pour acheter ces données de 50 Mo, contre seulement une demi-heure aux États-Unis. Il n’est pas facile de comparer le coût de la vie d’un pays à l’autre, mais pour le seul salaire, le coût de 3,67 dollars de 50 Mo de données au Zimbabwe donnerait 52 dollars à un américain au salaire minimum.
Mise en place de l’expérience
J’ai lancé Chrome et ouvrit les outils de développement, où je limitais le réseau à une connexion 3G lente. Je voulais simuler une connexion lente, comme celle des utilisateurs d’Ouzbékistan, pour voir le type d’expérience que les sites Web me procureraient. J'ai également étranglé mon processeur pour simuler le fait d'être sur un périphérique bas de gamme.
J'ai installé ModHeader et paramétré l'en-tête "Save-Data" pour que les sites Web sachent que je souhaite réduire au minimum l'utilisation de mes données. C’est également l’en-tête défini par Chrome pour le "Mode Lite" d’Android, que je traiterai plus en détail plus tard.
J’ai téléchargé TripMode ; une application pour Mac qui vous permet de contrôler quelles applications de votre Mac peuvent accéder à Internet. L’accès Internet de toute autre application est automatiquement bloqué.
Jusqu'où puis-je prédire que mon budget de 50 Mo me mènera? Le poids moyen d’une page Web étant d’environ 1,7 Mo cela donne à penser que j’ai environ 29 pages dans mon budget, mais probablement un peu plus que cela si je peux rester sur les mêmes sites. et mettre à profit la mise en cache du navigateur.
Tout au long de l’expérience, je vous suggérerai des astuces pour améliorer les performances de la première peinture contenant le contenu et du temps de chargement perçu. Certaines de ces astuces peuvent ne pas affecter directement la quantité de données transférées mais impliquent généralement le report du téléchargement de ressources moins importantes, ce qui signifie que, dans le cas de connexions lentes, les ressources ne sont jamais téléchargées et les données sauvegardées. [19659006] L’expérience Sans plus tarder, j’ai chargé google.com en utilisant 402 Ko de mon budget et en dépensant 0,03 USD (environ 1% de mon budget au Zimbabwe). Globalement, ce n'est pas une mauvaise taille de page, mais je me demandais d'où venaient ces 24 requêtes réseau et si la page pouvait être allégée. Il n'existe pas de feuilles de style externes dans le balisage de page: toutes les feuilles de style CSS sont en ligne. This is good for performance, car il évite au navigateur de faire une requête réseau supplémentaire pour extraire une feuille de style externe, de sorte que les styles puissent être analysés et appliqués immédiatement pour la première peinture contenant du contenu. Il faut faire un compromis ici, car les feuilles de style externes peuvent être mises en cache, mais pas les en-têtes (à moins que vous ne deveniez malin avec JavaScript ). Le conseil général est pour vos styles critiques (tout au-dessus du pli ) doit être en ligne et le reste de votre style doit être externe et chargé de manière asynchrone. Le chargement asynchrone de CSS peut être réalisé dans une ligne remarquablement intelligente de HTML : Les outils de développement montrent une version simplifiée du DOM. Si vous voulez voir ce qui a été réellement téléchargé dans le navigateur, ouvrez l'onglet Sources et trouvez le document. Vous pouvez voir qu'il y a BEAUCOUP de JavaScript en ligne ici. Il est à noter qu’elle a été oubliée plutôt que simplement minifiée. La minification supprime les espaces et les caractères inutiles, mais l ’uglification réduit en réalité le code. Le signe indicateur est que le code contient des noms de variables courts générés par la machine plutôt que du code source non modifié. C'est bien car cela signifie que le script est plus petit et plus rapide à télécharger. Néanmoins, les scripts en ligne semblent représenter environ 120 Ko de la ressource de page de 210 Ko (environ la moitié de la taille compressée de 60 Ko). En outre, il y a cinq fichiers JavaScript externes représentant 291 Ko sur les 402 Ko téléchargés: Cela signifie que JavaScript représente environ 80% du poids total de la page. Ce n'est pas un JavaScript inutile; Google doit en avoir pour afficher des suggestions au fur et à mesure de la frappe. Mais je soupçonne qu’il s’agit en grande partie de code de suivi et de configuration de la publicité. À titre de comparaison, j’ai désactivé JavaScript et rechargé la page: La version de la recherche Google désactivée pour le JS ne fait que 102 Ko, contre 402 Ko. Bien que Google ne puisse pas fournir de suggestion automatique dans ces conditions, le site est toujours fonctionnel et je viens de réduire mon utilisation des données à un quart de ce qu’elle était. Si j’étais vraiment obligé de limiter l’utilisation de mes données à long terme, l’une des premières choses que je ferais est de désactiver JavaScript. Ce n'est pas aussi grave que cela puisse paraître . Inlining, uglifying and minifying assets est bien beau, mais la meilleure performance provient de ne pas envoyer le Les actifs en premier lieu Il ya beaucoup à faire pour décompresser ici, alors commençons à craquer. Je n’ai que 50 Mo pour jouer, je vais donc tirer le maximum de chaque page de cette page. Installez-vous pour un bref tutoriel sur Chrome Devtools. 402 Ko transférés, mais 1,1 Mo de ressources: qu'est-ce que cela signifie réellement? Cela signifie que 402 Ko de contenu ont été réellement téléchargés, mais sous sa forme compressée (à l'aide d'une compression). algorithme tel que gzip ou brotli ). Le navigateur devait alors faire quelques efforts pour le décompresser en quelque chose de significatif. La taille totale des données non compressées est de 1,1 Mo. Ce décompactage n’est pas gratuit – il ya quelques millisecondes de temps système pour la décompression des ressources . Toutefois, il s’agit là d’un surcoût négligeable par rapport à l’envoi de 1,1 Mo. En règle générale, compressez toujours vos ressources à l’aide de gzip. Mais n'utilisez pas la compression sur vos images et autres fichiers binaires – vous devez les optimiser au préalable à la source. La compression pourrait en fait finir par les agrandir . Et, si vous le pouvez, évitez de compresser des fichiers de 1500 octets ou moins . La plus petite taille de paquet TCP est de 1500 octets. Ainsi, en compressant, par exemple, 800 octets, vous ne sauvegardez rien, car il est toujours transmis dans le même paquet d’octets. Là encore, le coût est négligeable, mais entraîne une perte de temps de compression sur le serveur et de décompression sur le client. Maintenant, revenez à l’onglet Réseau de Chrome: passons à ces priorités. Notez que les ressources sont prioritaires entre «priorité la plus élevée» et «priorité la plus basse» – c’est la meilleure estimation du navigateur en ce qui concerne les ressources les plus importantes à télécharger. Plus la priorité est élevée, plus le navigateur essaiera de télécharger rapidement l'actif. Le navigateur va deviner quelles sont les ressources les plus prioritaires, mais vous pouvez fournit un indice de ressource à l'aide de la balise Parlons de la mise en cache. Je vais maintenir ALT et cliquer avec le bouton droit de la souris pour changer les en-têtes de colonne afin de déverrouiller des informations plus juteuses. Nous allons vérifier Cache-Control. Cache-Control indique si une ressource peut ou non être mise en cache, combien de temps elle peut être mise en cache et quelles règles elle devrait suivre autour de revalidant . Il est essentiel de définir des valeurs de cache appropriées pour limiter le coût des données des visites répétées. Notez que la valeur de contrôle du cache commence par une directive de La valeur Pour expliquer la directive public / privé, nous devons expliquer les deux éléments principaux. les caches qui existent hors du serveur. Tout d’abord, il ya le cache du navigateur traditionnel, où la ressource est stockée sur la machine de l’utilisateur (le «client»). Et puis il y a le cache CDN, qui se trouve entre le client et le serveur; les ressources sont mises en cache au niveau du CDN pour empêcher le CDN de demander la ressource au serveur d'origine à plusieurs reprises Une directive Une des choses qui a attiré mon attention est que le logo de Google a un contrôle de cache de "privé". Les autres images de la page ont une mémoire cache publique et je ne sais pas pourquoi le logo serait traité différemment. Si vous avez des idées, faites-le moi savoir dans les commentaires! J'ai rafraîchi la page et la plupart des ressources ont été servies à partir de la mémoire cache, à l'exception de la page elle-même, qui, comme vous l'avez déjà vu, est C'est à ce moment-là que j'ai cliqué accidentellement sur l'URL 'Explication' des outils de développement, ce qui m'a amené à référence d'analyse de réseau me coûtant environ 5 Mo de mon budget. Oops. 4,2 Mo de cette nouvelle page de 5 Mo étaient réduites à des images; spécifiquement SVG. Le plus lourd de ces fichiers était de 186 Ko, ce qui n’est pas particulièrement volumineux – il y en avait tellement, et ils ont tous été téléchargés en même temps. Ce chargement de pages de 5 Mo représentait 10% de mon budget actuel. Jusqu'ici, j'ai utilisé 5,5 Mo, y compris le rechargement sans JavaScript de la page d'accueil de Google, et dépensé 0,40 USD. Je n'avais même pas l'intention d'ouvrir cette page.![402 Ko transférés, 1,1 Mo de ressources, 24 demandes [19659041] 402 Ko transférés, 1,1 Mo de ressources, 24 demandes. (<a href=](https://i0.wp.com/cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/71c8184e-85af-41d6-9253-1a2d74cdb5ec/02-i-used-the-web-for-a-day-on-a-50-mb-budget.png?ssl=1)
Grand aperçu ) Google Page d'accueil – DOM
de style . ( Image agrandie ) Conseil de performance n ° 1: CSS critique en ligne
Astuce de performance n ° 2: Minify And Uglify Your Assets
Conseil de performance n ° 3: Less Is More
Analyse de l’information sur les ressources
Conseil de performance n ° 4: Compression des ressources à base de texte
Conseil de performance n ° 5: donner des astuces sur les ressources au navigateur
invitant le navigateur à télécharger l'actif le plus rapidement possible. C’est une bonne idée de précharger les polices, les logos et tout ce qui se trouve au-dessus du pli.
Conseil de performance n ° 6: Définition des en-têtes de contrôle du cache sur tous les actifs pouvant être mis en cache
. ] public ou private suivi d'une valeur d'expiration (par exemple, max-age = 31536000 ). Que signifie la directive et pourquoi la valeur max-age étrangement spécifique?
31536000 est le nombre de secondes qu'il y a dans une année et correspond à la valeur maximale théorique autorisée par la spécification de contrôle de cache. Il est courant de voir cette valeur appliquée à tous les actifs statiques et signifie en réalité que «cette ressource ne va pas changer». En pratique, aucun navigateur ne va mettre en cache pendant une année complète mais il mettra en cache l’actif aussi longtemps que cela aura du sens.
Cache-Control de public permet à la ressource d'être mise en cache dans le client et le CDN. Une valeur de private signifie que seul le client peut la mettre en cache. le CDN n'est pas censé le faire. Cette dernière valeur est généralement utilisée pour les pages ou les ressources existant derrière l'authentification, où il est préférable d'être mises en cache sur le client, mais nous ne souhaitons pas divulguer d'informations privées en les mettant en cache dans le CDN et en les transmettant à d'autres utilisateurs. [19659094] Capture d'écran du paramètre de contrôle du cache du logo Google: private, max-age = 31536000 « /> private, max -age = 0 ce qui signifie qu'il ne peut pas être mis en cache. Ceci est normal pour les pages Web dynamiques où il est important que l'utilisateur obtienne toujours la page la plus récente lors de l'actualisation. Google Dev Docs
Conseil de performance n ° 7: chargez paresseusement vos images
D'habitude, si je cliquais accidentellement sur un lien, Je voudrais appuyer sur le bouton de retour dans mon navigateur. Le téléchargement de ces images ne m'apporterait aucun avantage: quel gaspillage de 4,2 Mo!
Hormis la vidéo, où vous savez généralement dans quoi vous vous entraînez, les images sont de loin le principal responsable de l'utilisation des données sur la toile. Une étude des 500 meilleurs sites Web au monde a révélé que les images représentent jusqu'à 53% du poids moyen des pages. "Cela signifie qu'ils ont un impact important sur les temps de chargement des pages et par conséquent sur les performances globales."
Au lieu de télécharger toutes les images lors du chargement de la page, il est recommandé de charger les images paresseux de manière à ce que seuls les utilisateurs avec la page payer le coût de les télécharger. Les utilisateurs qui choisissent de ne pas défiler sous le pli ne gaspillent donc pas de bande passante inutile en téléchargeant des images qu'ils ne verront jamais.
Il existe un excellent guide css-tricks.com pour déployer le chargement paresseux d'images . ] Qui offre un bon équilibre entre ceux sur les bonnes connexions, ceux sur les mauvaises connexions et ceux avec JavaScript désactivé.
Si cette page avait implémenté le chargement différé comme indiqué dans le guide ci-dessus, chacun des 38 SVG aurait été représenté par un Image d'espace réservé de 1 Ko par défaut, et chargée uniquement dans la vue sur le défilement.
Conseil de performance n ° 8: Utiliser le bon format pour vos images
Je pensais que Google avait manqué un tour en n'utilisant pas WebP qui est un format d'image 26% plus petit que les PNG (sans perte de qualité) et 25 à 34% plus petit que les JPEG (et de qualité comparable). Je pensais pouvoir convertir SVG en WebP.
La conversion en WebP a fait passer l'un des SVG de 186 Ko à seulement 65 Ko, mais en réalité, en regardant les images côte à côte, le WebP est sorti. grainy:
J'ai ensuite essayé de convertir l'un des fichiers PNG en WebP, censé être sans perte et devrait être plus petit. Cependant, la sortie WebP était * plus lourde * (127 Ko, à partir de 109 Ko)!
Cela m'a surpris. WebP n'est pas nécessairement la solution miracle que nous pensons, et même Google a négligé de l'utiliser sur cette page.
Mon conseil serait donc: dans la mesure du possible, essayez différents formats d'image, image par image. Le format qui conserve la meilleure qualité pour la plus petite taille n'est peut-être pas celui que vous attendez.
Revenons maintenant au DOM. Je suis tombé sur ceci:
Notez le mot clé async du script d'analyse de Google?
Bien qu’il s’agisse d’une des premières choses à la tête du document, cette priorité n’a pas la priorité, car nous avons explicitement choisi de ne pas être une demande de blocage en utilisant le mot clé async .
Une demande de blocage en est une qui arrête le rendu de la page. Un appel bloque par défaut, arrêtant l'analyse du code HTML jusqu'à ce que le script soit téléchargé, compilé et exécuté. C'est pourquoi nous avons traditionnellement placé des appels à la fin du document.
Conseil de performance n ° 9: Évitez d'écrire des appels de script de blocage
En ajoutant l'attribut async à notre balise , nous demandons au navigateur de ne pas arrêter le rendu de la page mais de télécharger le script en arrière-plan. Si le code HTML est toujours en cours d'analyse au moment du téléchargement du script, celui-ci est suspendu pendant l'exécution du script, puis repris. C'est nettement mieux que de bloquer le rendu dès que l'on rencontre .
Il existe également un attribut defer qui est légèrement différent. indique au navigateur de rendre la page pendant le chargement du script en arrière-plan, et même si le code HTML est toujours en cours d'analyse au moment du téléchargement du script, il doit attendre que la page soit rendue avant de pouvoir être exécutée. Cela rend le script complètement non bloquant. Lisez « Chargez efficacement du JavaScript avec différé et asynchrone » pour plus d'informations.
En tout cas, suffisamment de dissection dans Google. Il est temps d’essayer un autre site. Il me reste encore près de 45 Mo de mon budget!
Amazon
L'optimisation des images fournies par, par loin, la réduction de données la plus significative. Vous pouvez faire valoir le cas que JavaScript est un plus gros problème pour les performances globales, mais pas pour la réduction des données. Optimiser ou supprimer des images est le moyen le plus sûr d’assurer une expérience beaucoup plus légère, et c’est la principale optimisation sur laquelle Data Saver se base. - Tim Kadlec, Donner un sens aux pages chromées LitePour être juste envers Amazon, si Je redimensionne le navigateur à une taille mobile et actualise la page, le site est optimisé pour les mobiles et le poids total de la page n'est que de 2,1 Mo.
Conseil de performance n ° 10: ne faites pas d'hypothèses sur les connexions de données
Il est difficile de détecter si quelqu'un se trouve sur un ordinateur de bureau est connecté sur une connexion haut débit ou est connecté via un dongle ou un mobile limité en données. Beaucoup de gens travaillent dans le train comme ça ou vivent dans une région où l'infrastructure haut débit est médiocre mais où le signal mobile est puissant. Dans le cas d'Amazon, il est possible de faire de grosses économies de données sur le site de bureau et nous ne devrions pas faire preuve de négligence simplement parce que la taille de l'écran laisse penser que je ne suis pas sur un appareil mobile. Oui, nous devrions nous attendre à une page plus grande. charger si notre fenêtre d'affichage est de la "taille du bureau", car les images seront plus grandes et mieux optimisées pour l'écran que celles mobiles. Mais la page ne devrait pas être beaucoup plus grande. De plus, j’envoyais l’en-tête Save-Data avec ma demande. Cet en-tête indique explicitement une préférence pour une utilisation réduite des données et j'espère que de plus en plus de sites Web commenceront à en tenir compte à l'avenir.
La charge initiale de «bureau» peut avoir été de 6 Mo, mais après s'être reposée et le visionnant pendant une minute, il atteignait 8,6 Mo alors que les ressources moins prioritaires et le suivi des événements entraient en action. Le poids de cette page comprend près de 1,7 Mo de JavaScript minifié. Je ne veux même pas commencer à regarder .Conseil de performance n ° 11: Utiliser des travailleurs Web pour votre JavaScript
Ce qui serait pire - 1,7 Mo de JavaScript ou 1,7 Mo d'images ? La réponse est JavaScript: les deux ressources ne sont pas équivalentes en termes de performances.Une image JPEG doit être décodée, pixellisée et peinte à l'écran. Un ensemble JavaScript doit être téléchargé, puis analysé, compilé, exécuté. Un moteur doit effectuer un certain nombre d'autres étapes. Sachez que ces coûts ne sont pas tout à fait équivalents. - Addy Osmani, Le coût de JavaScript en 2018Si vous devez expédier autant de JavaScript, essayez de le mettre dans un employé Web. . Cela évite la majeure partie de JavaScript au thread principal, qui est maintenant libéré pour pouvoir repeindre l'interface utilisateur, ce qui permet à votre page Web de rester réactive sur les périphériques de faible puissance. Mon budget représente maintenant environ 15,5 Mo. dépensé 1,14 $ de mon budget de données du Zimbabwe. J'aurais dû travailler une demi-journée en tant qu'enseignant pour gagner l'argent nécessaire pour aller aussi loin.
Performance Tip #12: Use Service Workers To Provide Offline Support
Wouldn’t it be great if I only had to load a website once over network, and now get all the information I need even if I’m offline? A great example would be a website that shows the weather forecast for the week. I should only need to download that page once. If I turn off my mobile data and subsequently go back to the page at some point, it should be able to serve the last known content to me. If I connect to the internet again and load the page, I would get a more up to date forecast, but static assets such as CSS and images should still be served locally from the service worker. This is possible by setting up a service worker with a good caching strategy so that cached pages can be re-accessed offline. The lodash documentation website is a nice example of a service worker in the wild:
Gamespot
I picked this one because it felt noticeably sluggish on my mobile in the past and I wanted to dig into the reasons why. Sure enough, loading the homepage consumes 8.5 MB of data.
Performance Tip #13: Don’t Preload Video
As a rule, unless your site’s primary mode of communication is video, don’t preload it. If you’re YouTube or Netflix, it’s reasonable to assume that someone coming to your page will want the video to auto-load and auto-play. There is an expectation that the video will chew through some data, but that it’s a fair exchange for the content. But if you’re a site whose primary medium is text and image — and you just happen to offer additional video content — then don’t preload the video. Think of news articles with embedded videos. Many users only want to skim the article headline before moving on to their next thing. Others will read the article but ignore any embeds. And others will diligently click and watch each embedded video. We shouldn’t hog the bandwidth of every user on the assumption that they’re going to want to watch these videos. To reiterate: users don’t like autoplaying video. As developers we only do it because our managers tell us to, and they only tell us to do it because all the coolest apps are doing it, and the coolest apps are only doing it because video ads generate 20 to 50 times more revenue than traditional ads. Google Chrome has started blocking autoplay videos for some sitesbased on personal preferences, so even if you develop your site to autoplay video, there’s no guarantee that’s the experience your users are getting. If we agree that it’s a good idea to make video an opt-in experience (click to play), we can take it a step further and make it click to load too. That means mocking a video placeholder image with a play button over it, and only downloading the video when you click the play button. People on fast connections should notice no difference in buffer speed, and people on slow connections will appreciate how fast the rest of your site loaded because it didn’t have to preload a large video file. Anyway, back to Gamespot, where I was indeed forced to preload a large video file I ended up not watching. I then clicked through to a game review page that weighed another 8.5 MB, this time with 5.4 MB of video, before I even started scrolling down the page. What was really galling was when I looked at what the video actually was. It was an advert for a Samsung TV! This advert cost me $0.40 of my Zimbabwe wages. Not only was it pre-loaded, but it also didn’t end up playing anywhere as far as I’m aware, so I never actually saw it.
Performance Tip #14: Optimize For First Page Load
What’s striking is that I used 50 MB of data and in most cases, I only visited one or two pages on any given site. If you think about it, this is true of most user journeys today. Think about the last time you Googled something. You no doubt clicked on the first search result. If you got your answer, you closed the tab, or else you hit the back button and moved onto the next search result. With the exception of a few so-called ‘destination sites’ such as Facebook or YouTube, where users habitually go as a starting point for other activities, the majority of user journeys are ephemeral. We stumble across random sites to get the answers to our questions, never to return to those sites again. Web development practices are heavily skewed towards optimising for repeat visitors. “Cache these assets — they’ll come in handy later”. “Pre-load this onward journey, in case the user clicks to read more”. “Subscribe to our mailing list”. Instead, I believe we should optimize heavily for one-off visitors. Call it a controversial opinion, but maybe caching isn’t really all that important. How important can a cached resource that never gets surfaced again be? And perhaps users aren’t actually going to subscribe to your mailing list after reading just the one article, so downloading the JavaScript and CSS for the mail subscription modal is both a waste of data and an annoying user experience.The Decline Of Proxy Browsers
I had hoped to try out Opera Mini as part of this experiment. Opera Mini is a mobile web browser which proxies web pages through Opera’s compression servers. It accounts for 1.42% of global traffic as of June 2019, according to caniuse.com. Opera Mini claims to save up to 90% of data by doing some pretty intensive transcoding. HTML is parsed, images are compressed, styling is applied, and a certain amount of JavaScript is executed on Opera’s servers. The server doesn’t respond with HTML as you might expect — it actually transcodes the data into Opera Binary Markup Language (OBML), which is progressively loaded by Opera Mini on the device. It renders what is essentially an interactive ‘snapshot’ of the web page — think of it as a PDF with hyperlinks inside it. Read Tiffany Brown’s excellent article, “Opera Mini and JavaScript” for a technical deep-dive. It would have been a perfect way to eek my 50 MB budget as far as possible. Unfortunately, Opera Mini is no longer available on iOS in the UK. Attempting to visit it in the app store throws an error:
Conclusion
Reducing the data footprint of your website goes hand in hand with improving frontend performance. It is the single most reliable thing you can do to speed up your site. In addition to the cost of data, there are lots of good reasons to focus on performance, as described in a GOV.UK blog post on the subject:- 53% of users will abandon a mobile site if it takes more than 3 seconds to load.
- People have to concentrate 50% more when trying to complete a simple task on a website using a slow connection.
- More performant web pages are better for the battery life of the user’s device, and typically require less power on the server to deliver. A performant site is good for the environment.
(yk,ra)Source link