From baba5bef03330bb1df41d1a446ab979941df5bbe Mon Sep 17 00:00:00 2001 From: Boris SCHAPIRA Date: Sun, 3 May 2020 20:53:28 +0200 Subject: [PATCH 01/18] Fr Translation --- src/content/fr/2019/mobile-web.md | 287 ++++++++++++++++++++++++++++++ 1 file changed, 287 insertions(+) create mode 100644 src/content/fr/2019/mobile-web.md diff --git a/src/content/fr/2019/mobile-web.md b/src/content/fr/2019/mobile-web.md new file mode 100644 index 00000000000..015f9e59ab7 --- /dev/null +++ b/src/content/fr/2019/mobile-web.md @@ -0,0 +1,287 @@ +--- +part_number: II +chapter_number: 12 +title: Web Mobile +description: Chapitre sur les web mobile du Web Almanac 2019, couvrant le chargement des pages, du contenu textuel, du zoom et de la mise à l’échelle, des boutons et des liens, et de la facilité à remplir les formulaires. +authors: [obto] +reviewers: [AymenLoukil, hyperpress] +translators: [borisschapira] +discuss: 1767 +results: https://docs.google.com/spreadsheets/d/1dPBDeHigqx9FVaqzfq7CYTz4KjllkMTkfq4DG4utE_g/ +queries: 12_Mobile_Web +published: 2019-11-11T00:00:00.000Z +last_updated: 2019-11-23T00:00:00.000Z +--- + +## Introduction + +Remontons un instant dans le temps, jusqu’à l’année 2007. Le "web mobile" n’est pour l’instant que balbutiant, et pour de bonnes raisons. Pourquoi ? Les navigateurs mobiles ne prennent pas ou peu en charge le CSS, ce qui signifie que les sites ne ressemblent pas du tout à leur version sur ordinateur de bureau – certains navigateurs ne peuvent afficher que du texte. Les écrans sont incroyablement petits et ne peuvent afficher que quelques lignes de texte à la fois. Et en guise de souris, de minuscules touches fléchées utilisées pour "tabuler". Il va sans dire que naviguer sur le web avec un téléphone est un véritable sacerdoce. Mais tout est sur le point de changer. + +Au milieu de sa présentation, Steve Jobs prend l’iPhone qu’il vient juste de dévoiler, s’assoit et commence à surfer sur le web d’une manière dont nous n’avions jamais rêvé auparavant. Un grand écran et un navigateur complet affichant les sites web dans toute leur splendeur. Et surtout, en surfant sur le web à l’aide du dispositif de pointage le plus intuitif connu de l’homme : nos doigts. Plus besoin de tabulations avec de minuscules touches fléchées. + +Depuis 2007, le web mobile s’est développé à un rythme explosif. Aujourd’hui, 13 ans plus tard, le mobile représente [59 % de toutes les recherches](https://www.merkleinc.com/thought-leadership/digital-marketing-report) et 58,7 % de tout le trafic web, selon les données de [Akamai mPulse](https://developer.akamai.com/akamai-mpulse-real-user-monitoring-solution) en juillet 2019. Ce n’est plus un usage secondaire, mais la principale façon dont les gens vivent le web. Alors, étant donné l’importance du mobile, quel genre d’expérience offrons-nous à nos visiteurs et visiteuses ? Quels sont les points faibles ? C’est ce que nous allons découvrir. + +## L’expérience de chargement des pages + +La première partie de l’expérience du web mobile que nous avons analysée est celle que nous connaissons tous et toutes le mieux : _l’expérience de chargement des pages_. Mais avant de commencer à plonger dans nos découvertes, assurons-nous d’être en phase sur la définition du profil-type des utilisateurs et utilisatrices mobiles. Car cela vous aidera non seulement à reproduire ces résultats, mais aussi à mieux comprendre ces personnes. + +Commençons par le téléphone dont dispose ce profil-type. Le téléphone Android moyen [coûte ~250 dollars (environ 230 € hors taxe)](https://web.archive.org/web/20190921115844/https://www.idc.com/getdoc.jsp?containerId=prUS45115119), et l’un des [téléphones les plus populaires](https://web.archive.org/web/20190812221233/https://deviceatlas.com/blog/most-popular-android-smartphones) de cette gamme est le Samsung Galaxy S6. C’est donc probablement le type de téléphone utilisé, qui est en fait 4 fois plus lent qu’un iPhone 8. Ce profil-type n’a pas accès à une connexion 4G rapide, mais plutôt à une connexion 2G ([29 %](https://www.gsma.com/r/mobileeconomy/) du temps) ou 3G ([28 %](https://www.gsma.com/r/mobileeconomy/) du temps). En synthèse, voici ce que ça donne : + +
+ + + + + + + + + + + + + + + + + +
Type de connexion2G ou 3G
Latence300 - 400 ms
Bande passante (descendante)0.4 - 1.6 Mbps
ModèleGalaxy S6 — 4× plus lent qu’un iPhone 8 (score Octane V2)
+
Figure 1. Profil-type, cible mobile.
+
+ +J’imagine que certains d’entre vous sont surpris par ces résultats. Il se peut que les conditions soient bien pires que celles avec lesquelles vous avez testé votre site. Mais maintenant que nous sommes sur la même longueur d’onde en ce qui concerne le profil d’une personne sur mobile, commençons. + +### Des pages surchargées de JavaScript + +La quantité de code JavaScript sur le web mobile est alarmante. Selon le [rapport JavaScript](https://httparchive.org/reports/state-of-javascript?start=2016_05_15&end=2019_07_01&view=list#bytesJs) de HTTP Archive, en médiane, un site mobile nécessite que les téléphones téléchargent 375 Ko de JavaScript. En supposant un taux de compression de 70 %, cela signifie qu’en médiane, les téléphones doivent analyser, compiler et exécuter 1,25 Mo de JavaScript. + +Pourquoi est-ce un problème ? Parce que les sites qui chargent autant de JS prennent plus de [10 secondes](https://httparchive.org/reports/loading-speed?start=earliest&end=2019_07_01&view=list#ttci) pour devenir durablement interactifs. En d’autres termes, votre page peut sembler entièrement chargée, mais lorsqu’un utilisateur clique sur l’un de vos boutons ou menus, il peut ne rien se passer parce que le JavaScript n’a pas fini de s’exécuter. Dans le pire des scénarios, les utilisateurs se sentiront obligés de cliquer sur le bouton pendant plus de 10 secondes, en attendant le moment magique où quelque chose se passe enfin. Pensez à combien cela peut être déroutant et frustrant. + +
+ +
Figure 2. Exemple d’une expérience pénible où l’on attend que JS se charge.
+
+ +Allons plus loin et examinons une autre mesure qui se concentre davantage sur _comment_ chaque page utilise JavaScript. Par exemple, a-t-elle vraiment besoin d’autant de JavaScript pendant qu’elle se charge ? Nous appelons cette mesure le _JavaScript Bloat Score_ (en français, score de surcharge de JavaScript), basé sur le [web bloat score](https://www.webbloatscore.com/). L’idée derrière tout cela est la suivante : + +- JavaScript est souvent utilisé pour générer et modifier la page lors de son chargement ; +- Il est également livré sous forme de texte au navigateur. Il se compresse donc bien et devrait être livré plus rapidement qu’une simple capture d’écran de la page ; +- Ainsi, si la quantité totale de JavaScript qu’une page télécharge _seule_ (sans compter les images, CSS, etc.) est supérieure à une capture d’écran PNG du viewport, nous utilisons beaucoup trop de JavaScript. À ce stade, il serait plus rapide d’envoyer cette capture d’écran pour obtenir l’état initial de la page ! + +

Le *JavaScript Bloat Score* est défini comme suit : (taille totale du JavaScript) / (taille de la capture d’écran PNG du port d’affichage). Tout nombre supérieur à 1.0 signifie qu’il est plus rapide d’envoyer une capture d’écran.

+ +Quels en sont les résultats ? Sur les plus de 5 millions de sites web analysés, 75,52 % étaient surchargés de JavaScript. Nous avons encore un long chemin à parcourir. + +Notez que nous n’avons pas été en mesure de capturer et de mesurer les captures d’écran de plus de 5 millions de sites que nous avons analysés. Nous avons plutôt pris un échantillon aléatoire de 1000 sites pour trouver la taille médiane des captures d’écran (140 Ko), puis nous avons comparé la taille de téléchargement de JavaScript de chaque site à ce nombre. + +Pour une analyse plus approfondie des effets de JavaScript, consultez [« The Cost of JavaScript » (le coût de JavaScript) écrit en 2018](https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4) par Addy Osmani. + +### Utilisation de Service Workers + +Les navigateurs chargent généralement toutes les pages de la même manière. Ils donnent la priorité au téléchargement de certaines ressources par rapport à d’autres, suivent les mêmes règles de mise en cache, etc. Grâce aux [Service Workers](https://developers.google.com/web/fundamentals/primers/service-workers), nous avons maintenant un moyen de contrôler directement la façon dont nos ressources sont gérées par la couche réseau, ce qui permet souvent d’améliorer considérablement le temps de chargement des pages. + +Mais bien qu’ils soient disponibles depuis 2016 et mis en œuvre sur tous les principaux navigateurs, seuls 0,64 % des sites les utilisent ! + +### Déplacement du contenu pendant le chargement + +L’une des plus belles réussites du web est la façon dont les pages web se chargent progressivement. Les navigateurs téléchargent et affichent le contenu dès qu’ils le peuvent, afin que les utilisateurs puissent accéder à votre contenu le plus rapidement possible. Cependant, cela peut avoir un effet négatif si vous ne concevez pas votre site dans cette optique. Plus précisément, le contenu peut changer de position au fur et à mesure que les ressources se chargent, ce qui nuit à l’expérience utilisateur. + +
+ + Figure 3. Exemple de décalage du contenu qui distrait le lecteur. CLS total de 42,59 %. Image reproduite avec l’aimable autorisation de LookZook + + +
Figure 3. Exemple de décalage du contenu qui distrait le lecteur. CLS total de 42,59 %. Image reproduite avec l’aimable autorisation de LookZook
+
+ +Imaginez que vous êtes en train de lire un article quand, tout à coup, une image se charge et repousse le texte que vous lisez tout en bas de l’écran. Vous devez maintenant chercher où vous étiez ou simplement abandonner la lecture de l’article. Ou, pire encore, vous commencez à cliquer sur un lien juste avant qu’une annonce se charge au même endroit, ce qui se traduit par un clic accidentel sur l’annonce au lieu du lien. + +Alors, comment mesurer à quel point nos sites se transforment ? Dans le passé, c’était assez difficile (voire impossible), mais grâce à la nouvelle [API d’instabilité de la mise en page](https://web.dev/layout-instability-api), nous pouvons le faire en deux étapes : + +1. Via l’API Layout Instability (en français, « instabilité de la mise en page »), vous pouvez mesurer l’impact de chaque mouvement dans la page. Cette mesure vous est communiqué sous la forme d’un pourcentage de la quantité de contenu du viewport (la fenêtre de visualisation) qui a changé. + +2. Additionnez tous les changements que vous avez relevés. Le résultat est ce que nous appelons le score [Cumulative Layout Shift](https://web.dev/layout-instability-api#a-cumulative-layout-shift-score) (CLS). + +Comme chaque visiteur peut avoir un CLS différent, afin d’analyser cette mesure sur le web avec le [Chrome UX Report](./methodology#chrome-ux-report) (CrUX), nous combinons chaque expérience dans trois ensembles différents : + +- **Petit** CLS : regroupe les expériences ayant des CLS _en dessous de 5 %_. C’est-à-dire que la page est globalement stable ; ne varie pas beaucoup voire pas du tout. Pour mettre les choses en perspective, la page de la vidéo ci-dessus a un CLS de 42,59 %. +- **Grand** CLS : regroupe les expériences ayant un CLS de _100 % ou plus_. Il peut s’agir de nombreuses petites variations individuelles ou d’un nombre plus réduit de changements importants et significatifs. +- CLS **moyen** : tout ce qui se situe entre le petit et le grand. + +Que constatons-nous lorsque nous regardons le CLS sur le web ? + +1. Près de deux sites sur trois (65,32 %) ont des CLS moyens ou grands pour 50 % ou plus de toutes les expériences utilisateurs. + +2. 20,52 % des sites ont des CLS importants pour au moins la moitié de toutes les expériences des utilisateurs. Cela représente environ un site sur cinq. N’oubliez pas que la vidéo de la figure 3 n’a qu’un CLS de 42,59 %. Ces expériences sont donc encore pires ! + +Nous pensons que cette situation est due en grande partie au fait que les sites web ne fournissent pas une largeur et une hauteur explicites pour les ressources qui se chargent après que le texte a été affiché à l’écran, comme les publicités et les images. Avant que les navigateurs puissent afficher une ressource à l’écran, ils doivent savoir quelle place la ressource occupera. À moins qu’une taille explicite ne soit fournie via des attributs CSS ou HTML, les navigateurs n’ont aucun moyen de connaître la taille réelle de la ressource. Ils affichent donc celle-ci avec une largeur et une hauteur de 0 px jusqu’à ce qu’elle soit chargée. Lorsque la ressource est chargée et que les navigateurs savent enfin quelle est sa taille, ils déplacent le reste du contenu de la page, créant ainsi une instabilité dans la mise en page. + +### Demandes d’autorisation + +Ces dernières années, la démarcation entre les sites web et les applications "app store" n’a cessé de s’estomper. Même aujourd’hui, vous avez la possibilité de demander l’accès au microphone, à la caméra vidéo, à la géolocalisation, à la possibilité d’afficher des notifications, etc. + +Bien que cela ait ouvert encore plus de possibilités aux développeurs, le fait de demander inutilement ces autorisations peut inciter les utilisateurs à se méfier de votre page web, et peut susciter la méfiance. C’est pourquoi nous recommandons de toujours lier une demande de permission à une action de l’utilisateur, par exemple en appuyant sur le bouton "Trouver des cinémas près de chez moi". + +Actuellement, 1,52 % des sites demandent des autorisations sans que l’utilisateur n’ait à intervenir. Il est encourageant de voir un nombre aussi faible. Cependant, il est important de noter que nous n’avons pu analyser que les pages d’accueil. Ainsi, par exemple, les sites ne demandant des autorisations que sur leurs pages de contenu (par exemple, leurs articles de blog) n’ont pas été pris en compte. Voir notre page [Méthodologie](./methodology) pour plus d’informations. + +## Contenu textuel + +L’objectif premier d’une page web est de fournir un contenu que les utilisateurs souhaitent exploiter. Ce contenu peut être une vidéo YouTube ou un éventail d’images, mais souvent, il s’agit simplement du texte de la page. Il va sans dire qu’il est extrêmement important de s’assurer que notre contenu textuel est lisible pour nos visiteurs. Car si les visiteurs ne peuvent pas le lire, il n’y a plus rien à faire, et ils partiront. Il y a deux éléments clés à vérifier pour s’assurer que votre texte est lisible pour les lecteurs : le contraste des couleurs et la taille des polices. + +### Des couleurs contrastées + +Lorsque nous concevons nos sites, nous avons tendance à être dans des conditions plus favorables et à avoir de bien meilleurs yeux que bon nombre de nos visiteurs. Les visiteurs peuvent être daltoniens et incapables de distinguer la couleur du texte et du fond. [1 homme sur 12 et 1 femme sur 200](http://www.cvrl.org/people/stockman/pubs/1999%20Genetics%20chapter%20SSJN.pdf) d’origine européenne sont daltoniens. Ou peut-être que les visiteurs consultent la page au moment où le soleil crée des reflets sur leur écran, ce qui peut également nuire à la lisibilité. + +Pour nous aider à surmonter ces problèmes, il existe des [directives d’accessibilité](https://dequeuniversity.com/rules/axe/2.2/color-contrast) que nous pouvons suivre pour choisir nos couleurs de texte et de fond. Comment respectons-nous ces lignes directrices ? Seuls 22,04 % des sites donnent à l’ensemble de leur texte un contraste de couleur suffisant. Cette valeur est en fait une limite inférieure, car nous n’avons pu analyser que les textes avec un fond plein. Les images et les fonds dégradés n’ont pas pu être analysés. + +
+ + Figure 4. Exemple de ce à quoi ressemble un texte dont le contraste des couleurs est insuffisant. Avec l’aimable autorisation de LookZook + + +
Figure 4. Exemple de ce à quoi ressemble un texte dont le contraste des couleurs est insuffisant. Avec l’aimable autorisation de LookZook
+
+ +Pour des statistiques sur le daltonisme dans d’autres groupes démographiques, voir [ce document](https://web.archive.org/web/20180304115406/http://www.allpsych.uni-giessen.de/karl/colbook/sharpe.pdf). + +### Taille des polices + +La deuxième partie de la lisibilité consiste à s’assurer que le texte est suffisamment grand pour être lu facilement. C’est important pour tous les utilisateurs, mais surtout pour les personnes âgées. Les tailles de police inférieures à 12 px ont tendance à être plus difficiles à lire. + +Sur l’ensemble du web, nous avons constaté que 80,66 % des pages web répondent à ce critère de référence. + +## Zoom, mise à l’échelle et rotation des pages + +### Zoom et mise à l’échelle + +Il est incroyablement difficile de concevoir un site qui fonctionne parfaitement sur des dizaines de milliers de tailles d’écran et de dispositifs. Certains utilisateurs ont besoin d’une taille de police plus importante pour lire, zoomer sur les images de vos produits, ou ont besoin d’un bouton plus grand parce qu’il est trop petit et a échappé à votre équipe d’assurance qualité. C’est pour de telles raisons que les fonctions de zoom et de mise à l’échelle des appareils sont si importantes ; elles permettent aux utilisateurs de modifier nos pages pour qu’elles répondent à leurs besoins. + +Il existe de très rares cas où la désactivation est acceptable, par exemple lorsque la page en question est un jeu en ligne utilisant des commandes tactiles. Si cette option est laissée activée dans ce cas, les téléphones des joueurs feront un zoom avant et arrière chaque fois que le joueur tapera deux fois sur le jeu, ce qui rendra l’expérience inutilisable. + +Pour cette raison, les développeurs ont la possibilité de désactiver cette fonctionnalité en définissant l’une des deux propriétés suivantes dans la balise meta viewport : + +1. `user-scalable` défini à `0` ou `no` + +2. `maximum-scale` défini à `1`, `1.0`, etc. + +
+ + Figure 5. Pourcentage de sites web de bureau et mobiles qui activent ou désactivent la possibilité de zoomer / la mise à l’échelle. + + +
Figure 5. Pourcentage de sites web de bureau et mobiles qui activent ou désactivent la possibilité de zoomer / la mise à l’échelle.
+
+ +Cependant, les développeurs ont tellement abusé de cette fonctionnalité qu’aujourd’hui, près d’un site sur trois (32,21 %) la désactive, et Apple (à partir d’iOS 10) ne permet plus aux développeurs web de désactiver le zoom. Safari Mobile ignore simplement [la balise](https://archive.org/details/ios-10-beta-release-notes). Tous les sites, quoi qu’il en soit, peuvent être zoomés et mis à l’échelle sur les nouveaux appareils Apple, qui représentent plus de [11%](https://gs.statcounter.com/) de tout le trafic web dans le monde ! + +### Rotation des pages + +Certains appareils mobiles peuvent être tournés afin que votre site web soit affiché au format préféré des utilisateurs. Cependant, les utilisateurs ne gardent pas toujours la même orientation tout au long d’une session. Lorsqu’ils remplissent des formulaires, les utilisateurs peuvent passer en mode paysage pour utiliser le clavier plus grand. Ou bien, lorsqu’ils naviguent sur les produits, certains peuvent préférer les images de produits plus grandes que leur propose le mode paysage. En raison de ces types de cas d’utilisation, il est très important de ne pas priver l’utilisateur de cette capacité intégrée des appareils mobiles. Et la bonne nouvelle, c’est que nous n’avons trouvé pratiquement aucun site qui désactive cette fonction. Seuls 87 sites au total (soit 0,0016 %) désactivent cette fonction. C’est fantastique. + +## Boutons et liens + +### Cibles d’appui + +Nous sommes habitués à avoir des dispositifs de pointage précis, comme des souris, lorsque nous utilisons des ordinateurs de bureau, mais c’est une autre histoire sur mobile. Sur mobile, nous interagissons avec les sites grâce à ces outils volumineux et imprécis que nous appelons des doigts. En raison de leur imprécision, nous appuyons constamment sur des liens et des boutons sur lesquels nous ne voulions pas appuyer. + +Il peut être difficile de concevoir des cibles d’appui appropriées pour atténuer ce problème en raison de la grande variété de taille des doigts. Cependant, de nombreuses recherches ont été menées et il existe des [normes](https://developers.google.com/web/tools/lighthouse/audits/tap-targets) sûres concernant la taille des boutons et la distance qui doit les séparer. + +
+ + Figure 6. Normes de dimensionnement et d’espacement des cibles d’appui. Image reproduite avec l’aimable autorisation de LookZook. + + +
Figure 6. Normes de dimensionnement et d’espacement des cibles d’appui. Image reproduite avec l’aimable autorisation de LookZook.
+
+ +À l’heure actuelle, 34,43 % des sites ont des cibles d’appui suffisamment grandes. Nous avons donc encore beaucoup de chemin à parcourir avant que les erreurs liées aux "gros doigts" soient derrière nous. + +### Libellés des boutons + +Certains designers aiment utiliser des icônes à la place du texte ; elles peuvent donner à nos sites un aspect plus net et plus élégant. Mais si vous et tous les membres de votre équipe savez ce que ces icônes signifient, beaucoup de vos utilisateurs ne le sauront pas. C’est même le cas de la fameuse icône du hamburger ! Si vous ne nous croyez pas, faites des tests utilisateurs et voyez à quel point les utilisateurs peuvent être confus. Vous serez stupéfait. + +C’est pourquoi il est important d’éviter toute confusion et d’ajouter du texte complémentaire et des étiquettes à vos boutons. À l’heure actuelle, au moins 28,59 % des sites incluent un bouton avec une seule icône sans texte complémentaire. + +

Note : le nombre indiqué ci-dessus n’est qu’une limite inférieure. Au cours de notre analyse, nous n’avons inclus que les boutons utilisant des icônes de police sans texte complémentaire. Cependant, de nombreux boutons utilisent désormais des SVG au lieu d’icônes de police, aussi les inclurons-nous également dans les prochaines exécutions.

+ +## Champs de formulaire sémantique + +Qu’il s’agisse de s’inscrire à un nouveau service, d’acheter quelque chose en ligne ou même de recevoir des notifications de nouveaux messages sur un blog, les champs de formulaire sont une partie essentielle du web et sont utilisés quotidiennement. Malheureusement, ces champs sont tristement célèbres parce qu’ils sont très pénibles à remplir sur un téléphone portable. Heureusement, ces dernières années, les navigateurs ont donné aux développeurs de nouveaux outils pour faciliter le remplissage de ces champs que nous ne connaissons que trop bien. Voyons donc à quel point ils ont été utilisés. + +### Nouveaux types de saisie + +Dans le passé, `text` et `password` étaient parmi les seuls types de saisie (``) disponibles pour les développeurs, car ils répondaient à presque tous nos besoins sur ordinateurs de bureau. Ce n’est pas le cas pour les appareils mobiles. Les claviers mobiles sont incroyablement petits, et une tâche simple, comme la saisie d’une adresse électronique, peut obliger les utilisateurs à passer d’un clavier à l’autre : le clavier standard et le clavier à caractères spéciaux pour le symbole "@". La simple saisie d’un numéro de téléphone peut être difficile en utilisant les minuscules chiffres du clavier par défaut. + +De nombreux [nouveaux types de saisies](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#Form_%3Cinput%3E_types) ont été introduits depuis, permettant aux développeurs d’informer les navigateurs du type de données attendues et permettant aux navigateurs de fournir des claviers personnalisés spécifiquement pour ces types de saisie. Par exemple, le type `email` fournit aux utilisateurs un clavier alphanumérique comprenant le symbole "@", et le type `tel` affiche un clavier numérique. + +Lors de l’analyse des sites contenant une saisie d’email, 56,42 % utilisent `type="email"`. De même, pour les saisies de numéros de téléphone, `type="tel"` est utilisé 36,7 % du temps. Les autres nouveaux types de saisie ont un taux d’adoption encore plus faible. + +
+ + + + + + + + + + + + + + + + + +
TypeFréquence (pages)
phone1,917
name1,348
textbox833
+
Figure 7. Types de saisie invalides les plus couramment utilisés
+
+ +Assurez-vous de bien vous informer et de renseigner les autres sur la grande quantité de types de saisie disponibles et vérifiez que vous n’avez pas de fautes de frappe, à l’image de des plus courantes, reprises dans la figure 7 ci-dessus. + +### Activation de l’autocomplétion pour les saisies + +L’attribut [`autocomplete`](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete) de l’élément `` permet aux utilisateurs de remplir les champs du formulaire en un seul clic. Les utilisateurs remplissent des tonnes de formulaires, souvent avec exactement les mêmes informations à chaque fois. Conscients de ce fait, les navigateurs ont commencé à stocker ces informations de manière sécurisée afin de pouvoir les réutiliser. Tout ce que les développeurs doivent faire, c’est utiliser cet attribut `autocomplete` pour indiquer aux navigateurs quelle est l’information exacte à remplir, et le navigateur fait le reste. + +
+
29,62 %
+
Figure 8. Pourcentage des pages utilisant autocomplete.
+
+ +Actuellement, seules 29,62 % des pages comportant des champs de saisie utilisent cette fonction. + +### Saisie des champs de mot de passe + +Permettre aux utilisateurs de copier et de coller leurs mots de passe dans votre page leur permet d’utiliser un gestionnaire de mots de passe. Les gestionnaires de mots de passe aident les utilisateurs à générer (et à mémoriser) des mots de passe forts et à les remplir automatiquement sur les pages web. Seulement 0,02 % des pages web testées désactivent cette fonctionnalité. + +

Note : Bien que cela soit très encourageant, il s’agit peut-être d’une sous-estimation en raison de l’exigence de notre méthodologie de ne tester que les pages d’accueil. Les pages intérieures, comme les pages de connexion, ne sont pas testées.

+ +## Conclusion + +Pendant plus de 13 ans, nous avons traité le web mobile de façon accessoire, comme une vulgaire alternative aux sites pour ordinateurs de bureau. Mais il est temps que cela change. Le web mobile est maintenant _*le*_ web, et les sites pour ordinateurs de bureau tombent en désuétude. Il y a maintenant 4 milliards de smartphones actifs dans le monde, couvrant 70 % de tous les utilisateurs potentiels. Qu’en est-il des ordinateurs de bureau ? Ils sont actuellement 1,6 milliard et représentent de moins en moins d’utilisateurs du web chaque mois. + +Comment nous débrouillons-nous pour répondre aux besoins des utilisateurs de téléphones portables ? Selon nos recherches, même si 71 % des sites font des efforts pour adapter leur site au mobile, ils sont loin d’atteindre leur objectif. Les pages mettent une éternité à se charger et deviennent inutilisables en raison d’un abus de JavaScript, le texte est souvent impossible à lire, l’interaction avec les sites en cliquant sur des liens ou des boutons est source d’erreurs et d’exaspération, et des tonnes de fonctionnalités formidables inventées pour atténuer ces problèmes (Service Workers, saisie automatique, zoom, nouveaux formats d’image, etc) sont à peine utilisées. + +Le web mobile existe maintenant depuis assez longtemps pour qu’il y ait toute une génération d’enfants pour qui c’est le seul internet qu’ils aient jamais connu. Et quel genre d’expérience leur donnons-nous ? Nous les ramenons essentiellement à l’ère du modem (heureusement qu’AOL vend encore ces CD qui offrent 1000 heures d’accès gratuit à l’internet) ! + +
+ + Un CD d’essai gratuit de AOL (1000 heures) + + +
Figure 9. 1000 heures d’AOL gratuites, image issue de archive.org.
+
+ +

Notes : + +1. Nous avons considéré que les sites faisant un effort en matière de mobile sont ceux qui adaptent leur design à des écrans plus petits. Ou plutôt, ceux qui ont au moins un point de rupture CSS à 600px ou moins. + +2. Les utilisateurs potentiels, ou le marché total adressable, se composent des personnes âgées de 15 ans et plus : soit [5.7 milliards de personnes](https://www.prb.org/international/geography/world). + +3. [La recherche sur ordinateurs de bureau](https://www.merkleinc.com/thought-leadership/digital-marketing-report) and [leurs part de marché du web](https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet/worldwide/#monthly-201205-201909) sont en déclin depuis des années. + +4. Le nombre total de smartphones actifs a été trouvé en additionnant le nombre de téléphones Android et iPhones actifs (rendus publics par Apple et Google), et un peu de maths pour prendre en compte les téléphones chinois connectés à Internet. [Plus d’infos ici](https://www.ben-evans.com/benedictevans/2019/5/28/the-end-of-mobile). + +5. Le nombre de 1,6 milliards d’ordinateurs de bureau est calculé à partir de nombres rendus publics par [Microsoft](https://web.archive.org/web/20181030132235/https://news.microsoft.com/bythenumbers/en/windowsdevices) et [Apple](https://web.archive.org/web/20190628161024/https://appleinsider.com/articles/18/10/30/apple-passes-100m-active-mac-milestone-thanks-to-high-numbers-of-new-users). Il n’inclut pas les utilisateurs de PC linux. +

From a12d62ce4b7494e409607dda5d7dd34fb92c1e03 Mon Sep 17 00:00:00 2001 From: Boris SCHAPIRA Date: Tue, 19 May 2020 20:56:21 +0200 Subject: [PATCH 02/18] Video print fallbacks (cf. #837) --- src/content/fr/2019/mobile-web.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/content/fr/2019/mobile-web.md b/src/content/fr/2019/mobile-web.md index 015f9e59ab7..1fdbe8ed9f5 100644 --- a/src/content/fr/2019/mobile-web.md +++ b/src/content/fr/2019/mobile-web.md @@ -58,8 +58,12 @@ La quantité de code JavaScript sur le web mobile est alarmante. Selon le [rappo Pourquoi est-ce un problème ? Parce que les sites qui chargent autant de JS prennent plus de [10 secondes](https://httparchive.org/reports/loading-speed?start=earliest&end=2019_07_01&view=list#ttci) pour devenir durablement interactifs. En d’autres termes, votre page peut sembler entièrement chargée, mais lorsqu’un utilisateur clique sur l’un de vos boutons ou menus, il peut ne rien se passer parce que le JavaScript n’a pas fini de s’exécuter. Dans le pire des scénarios, les utilisateurs se sentiront obligés de cliquer sur le bouton pendant plus de 10 secondes, en attendant le moment magique où quelque chose se passe enfin. Pensez à combien cela peut être déroutant et frustrant.
- -
Figure 2. Exemple d’une expérience pénible où l’on attend que JS se charge.
+ + + Figure 2. Exemple d’une expérience pénible où l’on attend que JS se charge. + + +
Figure 2. Exemple d’une expérience pénible où l’on attend que JS se charge.
Allons plus loin et examinons une autre mesure qui se concentre davantage sur _comment_ chaque page utilise JavaScript. Par exemple, a-t-elle vraiment besoin d’autant de JavaScript pendant qu’elle se charge ? Nous appelons cette mesure le _JavaScript Bloat Score_ (en français, score de surcharge de JavaScript), basé sur le [web bloat score](https://www.webbloatscore.com/). L’idée derrière tout cela est la suivante : From 9a98a6b3be65653e58def8e40d4d263a8e313c17 Mon Sep 17 00:00:00 2001 From: Boris SCHAPIRA Date: Tue, 19 May 2020 22:37:37 +0200 Subject: [PATCH 03/18] Mobile Web FR added to Featured chapters --- src/templates/fr/2019/featured_chapters.html | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/templates/fr/2019/featured_chapters.html b/src/templates/fr/2019/featured_chapters.html index 5d04fcb066b..392db2b2784 100644 --- a/src/templates/fr/2019/featured_chapters.html +++ b/src/templates/fr/2019/featured_chapters.html @@ -1,4 +1,4 @@ -{%- set featured_chapter = ("accessibility","third-parties","seo","markup","cms", "caching","resource-hints") | random %} +{%- set featured_chapter = ("accessibility","third-parties","seo","markup","cms","caching","mobile-web","resource-hints") | random %} {# Below is the full set of chapters. If all are translated then replace above line with this one. Other than add chapters to above first line as they are translated (min of two chapters so repeat if only one chapter) @@ -49,9 +49,9 @@ {%- set featured_chapter_quote = "Progressive Web Apps (PWAs) are a new class of web applications, building on top of platform primitives like the Service Worker APIs. Service workers allow apps to support network-independent loading by acting as a network proxy, intercepting your web app's outgoing requests, and replying with programmatic or cached responses." %} {%- set featured_chapter_stats = {"stat1":"0.44%","label1":"Sites that register a service worker","stat2":"15%","label2":"Pageviews that use a Service Worker","stat3":"57%","label3":"PWAs that use the standalone display property"} %} {%- elif featured_chapter == "mobile-web" %} - {%- set featured_chapter_name = "Mobile Web" %} - {%- set featured_chapter_quote = "Since 2007, the mobile web has grown at an explosive rate. And now, 13 years later, mobile accounts for 59% of all searches and 58.7% of all web traffic, according to Akamai mPulse data in July 2019. It's no longer an afterthought, but the primary way people experience the web. So given how significant mobile is, what kind of experience are we providing our visitors? Where are we falling short? Let's find out." %} - {%- set featured_chapter_stats = {"stat1":"65%","label1":"Sites with medium or large content shifts during load","stat2":"32%","label2":"Sites that disable zooming","stat3":"34%","label3":"Sites with sufficiently sized tap targets"} %} + {%- set featured_chapter_name = "Web Mobile" %} + {%- set featured_chapter_quote = "Depuis 2007, le web mobile s’est développé à un rythme explosif. Aujourd’hui, 13 ans plus tard, le mobile représente 59 % de toutes les recherches et 58,7 % de tout le trafic web, selon les données de Akamai mPulse en juillet 2019. Ce n’est plus un usage secondaire, mais la principale façon dont les gens vivent le web. Alors, étant donné l’importance du mobile, quel genre d’expérience offrons-nous à nos visiteurs et visiteuses ? Quels sont les points faibles ? C’est ce que nous allons découvrir." %} + {%- set featured_chapter_stats = {"stat1":"65 %","label1":"des sites sont victimes de déplacements de contenu moyens ou importants pendant le chargement","stat2":"32 %","label2":"des sites désactive le zoom","stat3":"34 %","label3":"des sites ont des cibles d'appui de tailles suffisantes"} %} {%- elif featured_chapter == "ecommerce" %} {%- set featured_chapter_name = "Ecommerce" %} {%- set featured_chapter_quote = "Nearly 10% of the home pages in this study were found to be on an ecommerce platform. An ecommerce platform is a set of software or services that enables you to create and operate an online store, including Paid-for services such as Shopify, software platforms such as Magento Open Source, and Hosted platforms such as Magento Commerce." %} From 50162193f2bd4fec5f2fa2dccb9b522eff4bad83 Mon Sep 17 00:00:00 2001 From: Boris SCHAPIRA Date: Tue, 19 May 2020 22:37:52 +0200 Subject: [PATCH 04/18] My own readproofing --- src/content/fr/2019/mobile-web.md | 84 +++++++++++++++---------------- 1 file changed, 42 insertions(+), 42 deletions(-) diff --git a/src/content/fr/2019/mobile-web.md b/src/content/fr/2019/mobile-web.md index 1fdbe8ed9f5..7bd510d99af 100644 --- a/src/content/fr/2019/mobile-web.md +++ b/src/content/fr/2019/mobile-web.md @@ -17,15 +17,15 @@ last_updated: 2019-11-23T00:00:00.000Z Remontons un instant dans le temps, jusqu’à l’année 2007. Le "web mobile" n’est pour l’instant que balbutiant, et pour de bonnes raisons. Pourquoi ? Les navigateurs mobiles ne prennent pas ou peu en charge le CSS, ce qui signifie que les sites ne ressemblent pas du tout à leur version sur ordinateur de bureau – certains navigateurs ne peuvent afficher que du texte. Les écrans sont incroyablement petits et ne peuvent afficher que quelques lignes de texte à la fois. Et en guise de souris, de minuscules touches fléchées utilisées pour "tabuler". Il va sans dire que naviguer sur le web avec un téléphone est un véritable sacerdoce. Mais tout est sur le point de changer. -Au milieu de sa présentation, Steve Jobs prend l’iPhone qu’il vient juste de dévoiler, s’assoit et commence à surfer sur le web d’une manière dont nous n’avions jamais rêvé auparavant. Un grand écran et un navigateur complet affichant les sites web dans toute leur splendeur. Et surtout, en surfant sur le web à l’aide du dispositif de pointage le plus intuitif connu de l’homme : nos doigts. Plus besoin de tabulations avec de minuscules touches fléchées. +Au milieu de sa présentation, Steve Jobs prend l’iPhone qu’il vient juste de dévoiler, s’assoit et commence à surfer sur le web d’une manière dont nous n’avions jamais rêvé auparavant. Un grand écran et un navigateur complet affichant les sites web dans toute leur splendeur. Et surtout, en surfant sur le web à l’aide du dispositif de pointage le plus intuitif connu de l’Homme : ses doigts. Plus besoin de tabulations avec de minuscules touches fléchées. -Depuis 2007, le web mobile s’est développé à un rythme explosif. Aujourd’hui, 13 ans plus tard, le mobile représente [59 % de toutes les recherches](https://www.merkleinc.com/thought-leadership/digital-marketing-report) et 58,7 % de tout le trafic web, selon les données de [Akamai mPulse](https://developer.akamai.com/akamai-mpulse-real-user-monitoring-solution) en juillet 2019. Ce n’est plus un usage secondaire, mais la principale façon dont les gens vivent le web. Alors, étant donné l’importance du mobile, quel genre d’expérience offrons-nous à nos visiteurs et visiteuses ? Quels sont les points faibles ? C’est ce que nous allons découvrir. +Depuis 2007, le web mobile s’est développé à un rythme explosif. Aujourd’hui, 13 ans plus tard, le mobile représente [59 % de toutes les recherches](https://www.merkleinc.com/thought-leadership/digital-marketing-report) et 58,7 % de tout le trafic web, selon les données de [Akamai mPulse](https://developer.akamai.com/akamai-mpulse-real-user-monitoring-solution) de juillet 2019. Ce n’est plus un usage secondaire, mais la principale façon dont les gens vivent le web. Alors, étant donné l’importance du mobile, quel genre d’expérience offrons-nous à nos visiteurs et visiteuses ? Quels sont les points faibles ? C’est ce que nous allons découvrir. ## L’expérience de chargement des pages -La première partie de l’expérience du web mobile que nous avons analysée est celle que nous connaissons tous et toutes le mieux : _l’expérience de chargement des pages_. Mais avant de commencer à plonger dans nos découvertes, assurons-nous d’être en phase sur la définition du profil-type des utilisateurs et utilisatrices mobiles. Car cela vous aidera non seulement à reproduire ces résultats, mais aussi à mieux comprendre ces personnes. +La première partie de l’expérience du web mobile que nous avons analysée est celle que nous connaissons tous et toutes le mieux : _l’expérience de chargement des pages_. Mais avant de commencer à plonger dans nos découvertes, assurons-nous d’être en phase sur la définition du profil-type des personnes sur mobiles. Cela vous aidera non seulement à reproduire ces résultats, mais aussi à mieux comprendre ces personnes. -Commençons par le téléphone dont dispose ce profil-type. Le téléphone Android moyen [coûte ~250 dollars (environ 230 € hors taxe)](https://web.archive.org/web/20190921115844/https://www.idc.com/getdoc.jsp?containerId=prUS45115119), et l’un des [téléphones les plus populaires](https://web.archive.org/web/20190812221233/https://deviceatlas.com/blog/most-popular-android-smartphones) de cette gamme est le Samsung Galaxy S6. C’est donc probablement le type de téléphone utilisé, qui est en fait 4 fois plus lent qu’un iPhone 8. Ce profil-type n’a pas accès à une connexion 4G rapide, mais plutôt à une connexion 2G ([29 %](https://www.gsma.com/r/mobileeconomy/) du temps) ou 3G ([28 %](https://www.gsma.com/r/mobileeconomy/) du temps). En synthèse, voici ce que ça donne : +Commençons par le téléphone dont dispose ce profil-type. Le téléphone Android moyen [coûte ~250 dollars (environ 230 € hors taxe)](https://web.archive.org/web/20190921115844/https://www.idc.com/getdoc.jsp?containerId=prUS45115119), et l’un des [téléphones les plus populaires](https://web.archive.org/web/20190812221233/https://deviceatlas.com/blog/most-popular-android-smartphones) de cette gamme est le Samsung Galaxy S6. C’est donc probablement le type de téléphone utilisé, qui est concrètement 4 fois plus lent qu’un iPhone 8. Ce profil-type n’a pas accès à une connexion 4G rapide, mais plutôt à une connexion 2G ([29 %](https://www.gsma.com/r/mobileeconomy/) du temps) ou 3G ([28 %](https://www.gsma.com/r/mobileeconomy/) du temps). En synthèse, voici ce que donne ce profil-type :
@@ -35,11 +35,11 @@ Commençons par le téléphone dont dispose ce profil-type. Le téléphone Andro - + - + @@ -49,13 +49,13 @@ Commençons par le téléphone dont dispose ce profil-type. Le téléphone Andro
Figure 1. Profil-type, cible mobile.
-J’imagine que certains d’entre vous sont surpris par ces résultats. Il se peut que les conditions soient bien pires que celles avec lesquelles vous avez testé votre site. Mais maintenant que nous sommes sur la même longueur d’onde en ce qui concerne le profil d’une personne sur mobile, commençons. +J’imagine que des personnes seront surprises par ces résultats. Il se peut que les conditions soient bien pires que celles avec lesquelles vous avez testé votre site. Mais maintenant que nous sommes sur la même longueur d’onde en ce qui concerne le profil d’une personne sur mobile, commençons. ### Des pages surchargées de JavaScript -La quantité de code JavaScript sur le web mobile est alarmante. Selon le [rapport JavaScript](https://httparchive.org/reports/state-of-javascript?start=2016_05_15&end=2019_07_01&view=list#bytesJs) de HTTP Archive, en médiane, un site mobile nécessite que les téléphones téléchargent 375 Ko de JavaScript. En supposant un taux de compression de 70 %, cela signifie qu’en médiane, les téléphones doivent analyser, compiler et exécuter 1,25 Mo de JavaScript. +La quantité de code JavaScript sur le web mobile est alarmante. Selon le [rapport JavaScript](https://httparchive.org/reports/state-of-javascript?start=2016_05_15&end=2019_07_01&view=list#bytesJs) de HTTP Archive, en médiane, un site mobile demande aux téléphones de télécharger 375 Ko de JavaScript. En supposant un taux de compression de 70 %, cela signifie qu’en médiane, les téléphones doivent analyser, compiler et exécuter 1,25 Mo de JavaScript. -Pourquoi est-ce un problème ? Parce que les sites qui chargent autant de JS prennent plus de [10 secondes](https://httparchive.org/reports/loading-speed?start=earliest&end=2019_07_01&view=list#ttci) pour devenir durablement interactifs. En d’autres termes, votre page peut sembler entièrement chargée, mais lorsqu’un utilisateur clique sur l’un de vos boutons ou menus, il peut ne rien se passer parce que le JavaScript n’a pas fini de s’exécuter. Dans le pire des scénarios, les utilisateurs se sentiront obligés de cliquer sur le bouton pendant plus de 10 secondes, en attendant le moment magique où quelque chose se passe enfin. Pensez à combien cela peut être déroutant et frustrant. +Pourquoi est-ce un problème ? Parce que les sites qui chargent autant de JS peuvent prendre plus de [10 secondes](https://httparchive.org/reports/loading-speed?start=earliest&end=2019_07_01&view=list#ttci) pour devenir durablement interactifs. En d’autres termes, votre page peut sembler entièrement chargée, mais lorsqu’une personne clique sur l’un de vos boutons ou menus, il peut ne rien se passer parce que le JavaScript n’a pas fini de s’exécuter. Dans le pire des scénarios, les personnes concernées se sentiront obligées de cliquer sur le bouton pendant plus de 10 secondes, en attendant le moment magique où quelque chose se passe enfin. Pensez à combien cela peut être déroutant et frustrant.
@@ -69,14 +69,14 @@ Pourquoi est-ce un problème ? Parce que les sites qui chargent autant de J Allons plus loin et examinons une autre mesure qui se concentre davantage sur _comment_ chaque page utilise JavaScript. Par exemple, a-t-elle vraiment besoin d’autant de JavaScript pendant qu’elle se charge ? Nous appelons cette mesure le _JavaScript Bloat Score_ (en français, score de surcharge de JavaScript), basé sur le [web bloat score](https://www.webbloatscore.com/). L’idée derrière tout cela est la suivante : - JavaScript est souvent utilisé pour générer et modifier la page lors de son chargement ; -- Il est également livré sous forme de texte au navigateur. Il se compresse donc bien et devrait être livré plus rapidement qu’une simple capture d’écran de la page ; -- Ainsi, si la quantité totale de JavaScript qu’une page télécharge _seule_ (sans compter les images, CSS, etc.) est supérieure à une capture d’écran PNG du viewport, nous utilisons beaucoup trop de JavaScript. À ce stade, il serait plus rapide d’envoyer cette capture d’écran pour obtenir l’état initial de la page ! +- il est également livré sous forme de texte au navigateur. Il se compresse donc bien et devrait être livré plus rapidement qu’une simple capture d’écran de la page ; +- ainsi, si la quantité totale de JavaScript qu’une page télécharge (sans compter les images, CSS, etc.) est supérieure à une capture d’écran PNG du viewport, nous utilisons beaucoup trop de JavaScript. À ce stade, il serait plus rapide d’envoyer cette capture d’écran pour obtenir l’état initial de la page ! -

Le *JavaScript Bloat Score* est défini comme suit : (taille totale du JavaScript) / (taille de la capture d’écran PNG du port d’affichage). Tout nombre supérieur à 1.0 signifie qu’il est plus rapide d’envoyer une capture d’écran.

+

Le JavaScript Bloat Score est défini comme suit : (taille totale du JavaScript) / (taille de la capture d’écran PNG du port d’affichage). Tout nombre supérieur à 1 signifie qu’il est plus rapide d’envoyer une capture d’écran.

Quels en sont les résultats ? Sur les plus de 5 millions de sites web analysés, 75,52 % étaient surchargés de JavaScript. Nous avons encore un long chemin à parcourir. -Notez que nous n’avons pas été en mesure de capturer et de mesurer les captures d’écran de plus de 5 millions de sites que nous avons analysés. Nous avons plutôt pris un échantillon aléatoire de 1000 sites pour trouver la taille médiane des captures d’écran (140 Ko), puis nous avons comparé la taille de téléchargement de JavaScript de chaque site à ce nombre. +Notez que nous n’avons pas été en mesure de capturer et de mesurer les captures d’écran de plus de 5 millions de sites que nous avons analysés. Nous avons plutôt pris un échantillon aléatoire de 1000 sites pour trouver la taille médiane des captures d’écran (140 Ko), puis nous avons comparé la taille de téléchargement de JavaScript de chaque site à ce nombre. Pour une analyse plus approfondie des effets de JavaScript, consultez [« The Cost of JavaScript » (le coût de JavaScript) écrit en 2018](https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4) par Addy Osmani. @@ -84,11 +84,11 @@ Pour une analyse plus approfondie des effets de JavaScript, consultez [« T Les navigateurs chargent généralement toutes les pages de la même manière. Ils donnent la priorité au téléchargement de certaines ressources par rapport à d’autres, suivent les mêmes règles de mise en cache, etc. Grâce aux [Service Workers](https://developers.google.com/web/fundamentals/primers/service-workers), nous avons maintenant un moyen de contrôler directement la façon dont nos ressources sont gérées par la couche réseau, ce qui permet souvent d’améliorer considérablement le temps de chargement des pages. -Mais bien qu’ils soient disponibles depuis 2016 et mis en œuvre sur tous les principaux navigateurs, seuls 0,64 % des sites les utilisent ! +Mais bien qu’ils soient disponibles depuis 2016 et mis en œuvre sur tous les principaux navigateurs, seuls 0,64 % des sites les utilisent ! ### Déplacement du contenu pendant le chargement -L’une des plus belles réussites du web est la façon dont les pages web se chargent progressivement. Les navigateurs téléchargent et affichent le contenu dès qu’ils le peuvent, afin que les utilisateurs puissent accéder à votre contenu le plus rapidement possible. Cependant, cela peut avoir un effet négatif si vous ne concevez pas votre site dans cette optique. Plus précisément, le contenu peut changer de position au fur et à mesure que les ressources se chargent, ce qui nuit à l’expérience utilisateur. +L’une des plus belles réussites du web est la façon dont les pages web se chargent progressivement. Les navigateurs téléchargent et affichent le contenu dès qu’ils le peuvent, afin que les utilisateurs puissent y accéder le plus rapidement possible. Cependant, cela peut avoir un effet négatif si vous ne concevez pas votre site dans cette optique. Plus précisément, le contenu peut changer de position au fur et à mesure que les ressources se chargent, ce qui nuit à l’expérience utilisateur.
@@ -100,13 +100,13 @@ L’une des plus belles réussites du web est la façon dont les pages web se ch Imaginez que vous êtes en train de lire un article quand, tout à coup, une image se charge et repousse le texte que vous lisez tout en bas de l’écran. Vous devez maintenant chercher où vous étiez ou simplement abandonner la lecture de l’article. Ou, pire encore, vous commencez à cliquer sur un lien juste avant qu’une annonce se charge au même endroit, ce qui se traduit par un clic accidentel sur l’annonce au lieu du lien. -Alors, comment mesurer à quel point nos sites se transforment ? Dans le passé, c’était assez difficile (voire impossible), mais grâce à la nouvelle [API d’instabilité de la mise en page](https://web.dev/layout-instability-api), nous pouvons le faire en deux étapes : +Alors, comment mesurer à quel point nos sites se transforment ? Dans le passé, c’était assez difficile (voire impossible), mais grâce à la nouvelle [API Layout Instability](https://web.dev/layout-instability-api) (en français, « instabilité de la mise en page »), nous pouvons le faire en deux étapes : -1. Via l’API Layout Instability (en français, « instabilité de la mise en page »), vous pouvez mesurer l’impact de chaque mouvement dans la page. Cette mesure vous est communiqué sous la forme d’un pourcentage de la quantité de contenu du viewport (la fenêtre de visualisation) qui a changé. +1. via l’API Layout Instability, vous pouvez mesurer l’impact de chaque mouvement dans la page. Cette mesure vous est communiqué sous la forme d’un pourcentage de la quantité de contenu du viewport (la fenêtre de visualisation) qui a changé. -2. Additionnez tous les changements que vous avez relevés. Le résultat est ce que nous appelons le score [Cumulative Layout Shift](https://web.dev/layout-instability-api#a-cumulative-layout-shift-score) (CLS). +2. additionnez tous les changements que vous avez relevés. Le résultat est ce que nous appelons le score de [Cumulative Layout Shift](https://web.dev/layout-instability-api#a-cumulative-layout-shift-score) (CLS). -Comme chaque visiteur peut avoir un CLS différent, afin d’analyser cette mesure sur le web avec le [Chrome UX Report](./methodology#chrome-ux-report) (CrUX), nous combinons chaque expérience dans trois ensembles différents : +Comme chaque visiteur peut avoir un CLS différent, afin d’analyser cette mesure sur le web avec le [Chrome UX Report](./methodology#chrome-ux-report) (CrUX), nous rangeons chaque expérience dans l'un de ces trois ensembles distincts : - **Petit** CLS : regroupe les expériences ayant des CLS _en dessous de 5 %_. C’est-à-dire que la page est globalement stable ; ne varie pas beaucoup voire pas du tout. Pour mettre les choses en perspective, la page de la vidéo ci-dessus a un CLS de 42,59 %. - **Grand** CLS : regroupe les expériences ayant un CLS de _100 % ou plus_. Il peut s’agir de nombreuses petites variations individuelles ou d’un nombre plus réduit de changements importants et significatifs. @@ -118,23 +118,23 @@ Que constatons-nous lorsque nous regardons le CLS sur le web ? 2. 20,52 % des sites ont des CLS importants pour au moins la moitié de toutes les expériences des utilisateurs. Cela représente environ un site sur cinq. N’oubliez pas que la vidéo de la figure 3 n’a qu’un CLS de 42,59 %. Ces expériences sont donc encore pires ! -Nous pensons que cette situation est due en grande partie au fait que les sites web ne fournissent pas une largeur et une hauteur explicites pour les ressources qui se chargent après que le texte a été affiché à l’écran, comme les publicités et les images. Avant que les navigateurs puissent afficher une ressource à l’écran, ils doivent savoir quelle place la ressource occupera. À moins qu’une taille explicite ne soit fournie via des attributs CSS ou HTML, les navigateurs n’ont aucun moyen de connaître la taille réelle de la ressource. Ils affichent donc celle-ci avec une largeur et une hauteur de 0 px jusqu’à ce qu’elle soit chargée. Lorsque la ressource est chargée et que les navigateurs savent enfin quelle est sa taille, ils déplacent le reste du contenu de la page, créant ainsi une instabilité dans la mise en page. +Nous pensons que cette situation est due en grande partie au fait que les sites web ne fournissent pas une largeur et une hauteur explicites pour les ressources qui se chargent après que le texte a été affiché à l’écran, comme les publicités et les images. Avant que les navigateurs puissent afficher une ressource à l’écran, ils doivent savoir quelle surface la ressource occupera. À moins qu’une taille explicite ne soit fournie via des attributs CSS ou HTML, les navigateurs n’ont aucun moyen de connaître la taille réelle de la ressource. Ils affichent donc celle-ci avec une largeur et une hauteur de 0 px jusqu’à ce qu’elle soit chargée. Lorsque la ressource est chargée et que les navigateurs savent enfin quelle est sa taille, ils déplacent le reste du contenu de la page, créant ainsi une instabilité dans la mise en page. ### Demandes d’autorisation -Ces dernières années, la démarcation entre les sites web et les applications "app store" n’a cessé de s’estomper. Même aujourd’hui, vous avez la possibilité de demander l’accès au microphone, à la caméra vidéo, à la géolocalisation, à la possibilité d’afficher des notifications, etc. +Ces dernières années, la démarcation entre les sites web et les applications "app store" n’a cessé de s’estomper. Au point qu'aujourd’hui, vous avez la possibilité de demander l’accès au microphone, à la caméra vidéo, à la géolocalisation, à la possibilité d’afficher des notifications, etc. -Bien que cela ait ouvert encore plus de possibilités aux développeurs, le fait de demander inutilement ces autorisations peut inciter les utilisateurs à se méfier de votre page web, et peut susciter la méfiance. C’est pourquoi nous recommandons de toujours lier une demande de permission à une action de l’utilisateur, par exemple en appuyant sur le bouton "Trouver des cinémas près de chez moi". +Bien que cela ait ouvert encore plus de possibilités aux équipes de développement, le fait de demander inutilement ces autorisations peut inciter les utilisateurs et utilisatrices à se méfier de votre page web. C’est pourquoi nous recommandons de toujours lier une demande de permission à une action de la personne utilisant le site, par exemple en appuyant sur le bouton "Trouver des cinémas près de chez moi". -Actuellement, 1,52 % des sites demandent des autorisations sans que l’utilisateur n’ait à intervenir. Il est encourageant de voir un nombre aussi faible. Cependant, il est important de noter que nous n’avons pu analyser que les pages d’accueil. Ainsi, par exemple, les sites ne demandant des autorisations que sur leurs pages de contenu (par exemple, leurs articles de blog) n’ont pas été pris en compte. Voir notre page [Méthodologie](./methodology) pour plus d’informations. +Actuellement, 1,52 % des sites demandent des autorisations sans aucune intervention. Il est encourageant de voir un nombre aussi faible. Cependant, il est important de noter que nous n’avons pu analyser que les pages d’accueil. Ainsi, par exemple, les sites ne demandant des autorisations que sur leurs pages de contenu (par exemple, leurs articles de blog) n’ont pas été pris en compte. Voir notre page [Méthodologie](./methodology) pour plus d’informations. ## Contenu textuel -L’objectif premier d’une page web est de fournir un contenu que les utilisateurs souhaitent exploiter. Ce contenu peut être une vidéo YouTube ou un éventail d’images, mais souvent, il s’agit simplement du texte de la page. Il va sans dire qu’il est extrêmement important de s’assurer que notre contenu textuel est lisible pour nos visiteurs. Car si les visiteurs ne peuvent pas le lire, il n’y a plus rien à faire, et ils partiront. Il y a deux éléments clés à vérifier pour s’assurer que votre texte est lisible pour les lecteurs : le contraste des couleurs et la taille des polices. +L’objectif premier d’une page web est de fournir un contenu exploitable par les utilisateurs et utilisatrices. Ce contenu peut être une vidéo YouTube ou un éventail d’images mais, le plus souvent, il s’agit simplement du texte de la page. Il va sans dire qu’il est extrêmement important de s’assurer que notre contenu textuel est lisible pour nos visiteurs. Car si les visiteurs ne peuvent pas le lire, il n’y a plus rien à faire, et ils partiront. Il y a deux éléments clés à vérifier pour s’assurer que votre texte est lisible : le contraste des couleurs et la taille des polices. ### Des couleurs contrastées -Lorsque nous concevons nos sites, nous avons tendance à être dans des conditions plus favorables et à avoir de bien meilleurs yeux que bon nombre de nos visiteurs. Les visiteurs peuvent être daltoniens et incapables de distinguer la couleur du texte et du fond. [1 homme sur 12 et 1 femme sur 200](http://www.cvrl.org/people/stockman/pubs/1999%20Genetics%20chapter%20SSJN.pdf) d’origine européenne sont daltoniens. Ou peut-être que les visiteurs consultent la page au moment où le soleil crée des reflets sur leur écran, ce qui peut également nuire à la lisibilité. +Lorsque nous concevons nos sites, nous avons tendance à être dans des conditions plus favorables et à avoir de bien meilleurs yeux que bon nombre de nos visiteurs. Les visiteurs peuvent être daltoniens et incapables de distinguer la couleur du texte et du fond. [1 femme sur 200 et 1 homme sur 12](http://www.cvrl.org/people/stockman/pubs/1999%20Genetics%20chapter%20SSJN.pdf) d’origine européenne sont daltoniens. Pensez aussi que des personnes peuvent consulter la page au moment où le soleil crée des reflets sur leur écran, ce qui peut également nuire à la lisibilité. Pour nous aider à surmonter ces problèmes, il existe des [directives d’accessibilité](https://dequeuniversity.com/rules/axe/2.2/color-contrast) que nous pouvons suivre pour choisir nos couleurs de texte et de fond. Comment respectons-nous ces lignes directrices ? Seuls 22,04 % des sites donnent à l’ensemble de leur texte un contraste de couleur suffisant. Cette valeur est en fait une limite inférieure, car nous n’avons pu analyser que les textes avec un fond plein. Les images et les fonds dégradés n’ont pas pu être analysés. @@ -150,7 +150,7 @@ Pour des statistiques sur le daltonisme dans d’autres groupes démographiques, ### Taille des polices -La deuxième partie de la lisibilité consiste à s’assurer que le texte est suffisamment grand pour être lu facilement. C’est important pour tous les utilisateurs, mais surtout pour les personnes âgées. Les tailles de police inférieures à 12 px ont tendance à être plus difficiles à lire. +La deuxième partie de la lisibilité consiste à s’assurer que le texte est suffisamment grand pour être lu facilement. C’est important pour tous les types d'utilisateurs, mais surtout pour les personnes âgées. Les tailles de police inférieures à 12 px ont tendance à être plus difficiles à lire. Sur l’ensemble du web, nous avons constaté que 80,66 % des pages web répondent à ce critère de référence. @@ -158,11 +158,11 @@ Sur l’ensemble du web, nous avons constaté que 80,66 % des pages web ré ### Zoom et mise à l’échelle -Il est incroyablement difficile de concevoir un site qui fonctionne parfaitement sur des dizaines de milliers de tailles d’écran et de dispositifs. Certains utilisateurs ont besoin d’une taille de police plus importante pour lire, zoomer sur les images de vos produits, ou ont besoin d’un bouton plus grand parce qu’il est trop petit et a échappé à votre équipe d’assurance qualité. C’est pour de telles raisons que les fonctions de zoom et de mise à l’échelle des appareils sont si importantes ; elles permettent aux utilisateurs de modifier nos pages pour qu’elles répondent à leurs besoins. +Il est incroyablement difficile de concevoir un site qui fonctionne parfaitement sur des dizaines de milliers de tailles d’écran et de dispositifs. Certaines personnes ont besoin d’une taille de police plus importante pour lire, zoomer sur les images de vos produits, ou ont besoin d’un bouton plus grand parce qu’il est trop petit et a échappé à votre équipe d’assurance qualité. C’est pour de telles raisons que les fonctions de zoom et de mise à l’échelle des appareils sont si importantes ; elles permettent aux gens de modifier nos pages pour qu’elles répondent à leurs besoins. Il existe de très rares cas où la désactivation est acceptable, par exemple lorsque la page en question est un jeu en ligne utilisant des commandes tactiles. Si cette option est laissée activée dans ce cas, les téléphones des joueurs feront un zoom avant et arrière chaque fois que le joueur tapera deux fois sur le jeu, ce qui rendra l’expérience inutilisable. -Pour cette raison, les développeurs ont la possibilité de désactiver cette fonctionnalité en définissant l’une des deux propriétés suivantes dans la balise meta viewport : +Pour cette raison, les équipes de développement ont la possibilité de désactiver cette fonctionnalité en définissant l’une des deux propriétés suivantes dans la balise meta viewport : 1. `user-scalable` défini à `0` ou `no` @@ -172,15 +172,15 @@ Pour cette raison, les développeurs ont la possibilité de désactiver cette fo Figure 5. Pourcentage de sites web de bureau et mobiles qui activent ou désactivent la possibilité de zoomer / la mise à l’échelle. - +
Figure 5. Pourcentage de sites web de bureau et mobiles qui activent ou désactivent la possibilité de zoomer / la mise à l’échelle.
-Cependant, les développeurs ont tellement abusé de cette fonctionnalité qu’aujourd’hui, près d’un site sur trois (32,21 %) la désactive, et Apple (à partir d’iOS 10) ne permet plus aux développeurs web de désactiver le zoom. Safari Mobile ignore simplement [la balise](https://archive.org/details/ios-10-beta-release-notes). Tous les sites, quoi qu’il en soit, peuvent être zoomés et mis à l’échelle sur les nouveaux appareils Apple, qui représentent plus de [11%](https://gs.statcounter.com/) de tout le trafic web dans le monde ! +Cependant, les équipes de développement ont tellement abusé de cette fonctionnalité qu’aujourd’hui, près d’un site sur trois (32,21 %) la désactive, et Apple (à partir d’iOS 10) ne permet plus aux équipes de développement web de désactiver le zoom. Safari Mobile ignore simplement [la balise](https://archive.org/details/ios-10-beta-release-notes). Tous les sites, quoi qu’il en soit, peuvent être zoomés et mis à l’échelle sur les nouveaux appareils Apple, qui représentent plus de [11%](https://gs.statcounter.com/) de tout le trafic web dans le monde ! ### Rotation des pages -Certains appareils mobiles peuvent être tournés afin que votre site web soit affiché au format préféré des utilisateurs. Cependant, les utilisateurs ne gardent pas toujours la même orientation tout au long d’une session. Lorsqu’ils remplissent des formulaires, les utilisateurs peuvent passer en mode paysage pour utiliser le clavier plus grand. Ou bien, lorsqu’ils naviguent sur les produits, certains peuvent préférer les images de produits plus grandes que leur propose le mode paysage. En raison de ces types de cas d’utilisation, il est très important de ne pas priver l’utilisateur de cette capacité intégrée des appareils mobiles. Et la bonne nouvelle, c’est que nous n’avons trouvé pratiquement aucun site qui désactive cette fonction. Seuls 87 sites au total (soit 0,0016 %) désactivent cette fonction. C’est fantastique. +Certains appareils mobiles peuvent être tournés afin que votre site web soit affiché au format préféré des utilisateurs et utilisatrices. Cependant, les gens ne gardent pas toujours la même orientation tout au long d’une session. Lorsqu’ils remplissent des formulaires, ils peuvent passer en mode paysage pour utiliser le clavier plus grand. Ou bien, lorsqu’ils naviguent sur les produits, certains peuvent préférer les images de produits plus grandes que leur propose le mode paysage. En raison de ces types de cas d’utilisation, il est très important de ne pas les priver de cette capacité intégrée des appareils mobiles. Et la bonne nouvelle, c’est que nous n’avons trouvé pratiquement aucun site qui désactive cette fonction. Seuls 87 sites au total (soit 0,0016 %) désactivent cette fonction. C’est fantastique. ## Boutons et liens @@ -202,7 +202,7 @@ Il peut être difficile de concevoir des cibles d’appui appropriées pour att ### Libellés des boutons -Certains designers aiment utiliser des icônes à la place du texte ; elles peuvent donner à nos sites un aspect plus net et plus élégant. Mais si vous et tous les membres de votre équipe savez ce que ces icônes signifient, beaucoup de vos utilisateurs ne le sauront pas. C’est même le cas de la fameuse icône du hamburger ! Si vous ne nous croyez pas, faites des tests utilisateurs et voyez à quel point les utilisateurs peuvent être confus. Vous serez stupéfait. +Certains designers aiment utiliser des icônes à la place du texte ; elles peuvent donner à nos sites un aspect plus net et plus élégant. Mais si vous et tous les membres de votre équipe savez ce que ces icônes signifient, beaucoup de vos visiteurs et visiteuses ne le sauront pas. C’est même le cas de la fameuse icône « hamburger » ! Si vous ne nous croyez pas, faites des tests utilisateurs et voyez à quel point ils peuvent être confus. Vous serez stupéfait·e. C’est pourquoi il est important d’éviter toute confusion et d’ajouter du texte complémentaire et des étiquettes à vos boutons. À l’heure actuelle, au moins 28,59 % des sites incluent un bouton avec une seule icône sans texte complémentaire. @@ -210,13 +210,13 @@ C’est pourquoi il est important d’éviter toute confusion et d’ajouter du ## Champs de formulaire sémantique -Qu’il s’agisse de s’inscrire à un nouveau service, d’acheter quelque chose en ligne ou même de recevoir des notifications de nouveaux messages sur un blog, les champs de formulaire sont une partie essentielle du web et sont utilisés quotidiennement. Malheureusement, ces champs sont tristement célèbres parce qu’ils sont très pénibles à remplir sur un téléphone portable. Heureusement, ces dernières années, les navigateurs ont donné aux développeurs de nouveaux outils pour faciliter le remplissage de ces champs que nous ne connaissons que trop bien. Voyons donc à quel point ils ont été utilisés. +Qu’il s’agisse de s’inscrire à un nouveau service, d’acheter quelque chose en ligne ou même de recevoir des notifications de nouveaux messages sur un blog, les champs de formulaire sont une partie essentielle du web et sont utilisés quotidiennement. Malheureusement, ces champs sont tristement célèbres parce qu’ils sont très pénibles à remplir sur un téléphone portable. Heureusement, ces dernières années, les navigateurs ont donné aux équipes de développement de nouveaux outils pour faciliter le remplissage de ces champs que nous ne connaissons que trop bien. Voyons donc à quel point ils ont été utilisés. ### Nouveaux types de saisie -Dans le passé, `text` et `password` étaient parmi les seuls types de saisie (``) disponibles pour les développeurs, car ils répondaient à presque tous nos besoins sur ordinateurs de bureau. Ce n’est pas le cas pour les appareils mobiles. Les claviers mobiles sont incroyablement petits, et une tâche simple, comme la saisie d’une adresse électronique, peut obliger les utilisateurs à passer d’un clavier à l’autre : le clavier standard et le clavier à caractères spéciaux pour le symbole "@". La simple saisie d’un numéro de téléphone peut être difficile en utilisant les minuscules chiffres du clavier par défaut. +Dans le passé, `text` et `password` étaient parmi les seuls types de saisie (``) disponibles pour les équipes de développement, car ils répondaient à presque tous nos besoins sur ordinateurs de bureau. Ce n’est pas le cas pour les appareils mobiles. Les claviers mobiles sont incroyablement petits, et une tâche simple, comme la saisie d’une adresse électronique, peut obliger les utilisateurs à passer d’un clavier à l’autre : le clavier standard et le clavier à caractères spéciaux pour le symbole "@". La simple saisie d’un numéro de téléphone peut être difficile en utilisant les minuscules chiffres du clavier par défaut. -De nombreux [nouveaux types de saisies](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#Form_%3Cinput%3E_types) ont été introduits depuis, permettant aux développeurs d’informer les navigateurs du type de données attendues et permettant aux navigateurs de fournir des claviers personnalisés spécifiquement pour ces types de saisie. Par exemple, le type `email` fournit aux utilisateurs un clavier alphanumérique comprenant le symbole "@", et le type `tel` affiche un clavier numérique. +De nombreux [nouveaux types de saisies](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#Form_%3Cinput%3E_types) ont été introduits depuis, permettant aux équipes de développement d’informer les navigateurs du type de données attendu et permettant aux navigateurs de fournir des claviers personnalisés spécifiquement pour ces types de saisie. Par exemple, le type `email` permet au navigateur de fournir un clavier alphanumérique comprenant le symbole "@", et le type `tel`, un clavier numérique. Lors de l’analyse des sites contenant une saisie d’email, 56,42 % utilisent `type="email"`. De même, pour les saisies de numéros de téléphone, `type="tel"` est utilisé 36,7 % du temps. Les autres nouveaux types de saisie ont un taux d’adoption encore plus faible. @@ -246,7 +246,7 @@ Assurez-vous de bien vous informer et de renseigner les autres sur la grande qua ### Activation de l’autocomplétion pour les saisies -L’attribut [`autocomplete`](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete) de l’élément `` permet aux utilisateurs de remplir les champs du formulaire en un seul clic. Les utilisateurs remplissent des tonnes de formulaires, souvent avec exactement les mêmes informations à chaque fois. Conscients de ce fait, les navigateurs ont commencé à stocker ces informations de manière sécurisée afin de pouvoir les réutiliser. Tout ce que les développeurs doivent faire, c’est utiliser cet attribut `autocomplete` pour indiquer aux navigateurs quelle est l’information exacte à remplir, et le navigateur fait le reste. +L’attribut [`autocomplete`](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete) de l’élément `` permet aux gens de remplir les champs du formulaire en un seul clic. Ils remplissent des tonnes de formulaires, souvent avec exactement les mêmes informations à chaque fois. Conscients de ce fait, les navigateurs ont commencé à stocker ces informations de manière sécurisée afin de pouvoir les réutiliser. Tout ce que les équipes de développement doivent faire, c’est utiliser cet attribut `autocomplete` pour indiquer aux navigateurs quelle est l’information exacte à remplir, et le navigateur fait le reste.
29,62 %
@@ -273,19 +273,19 @@ Le web mobile existe maintenant depuis assez longtemps pour qu’il y ait toute Un CD d’essai gratuit de AOL (1000 heures) - +
Figure 9. 1000 heures d’AOL gratuites, image issue de archive.org.

Notes : -1. Nous avons considéré que les sites faisant un effort en matière de mobile sont ceux qui adaptent leur design à des écrans plus petits. Ou plutôt, ceux qui ont au moins un point de rupture CSS à 600px ou moins. +1. Nous avons considéré que les sites faisant un effort en matière de mobile sont ceux qui adaptent leur design à des écrans plus petits. Ou plutôt, ceux qui ont au moins un point de rupture CSS à 600 px ou moins. -2. Les utilisateurs potentiels, ou le marché total adressable, se composent des personnes âgées de 15 ans et plus : soit [5.7 milliards de personnes](https://www.prb.org/international/geography/world). +2. Les utilisateurs et utilisatrices potentielles, ou le marché total adressable, se composent des personnes âgées de 15 ans et plus : soit [5,7 milliards de personnes](https://www.prb.org/international/geography/world). -3. [La recherche sur ordinateurs de bureau](https://www.merkleinc.com/thought-leadership/digital-marketing-report) and [leurs part de marché du web](https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet/worldwide/#monthly-201205-201909) sont en déclin depuis des années. +3. [Les part de marché du web sur ordinateurs de bureau](https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet/worldwide/#monthly-201205-201909) sont en déclin depuis des années, tout comme [la recherche sur ces matériels](https://www.merkleinc.com/thought-leadership/digital-marketing-report) -4. Le nombre total de smartphones actifs a été trouvé en additionnant le nombre de téléphones Android et iPhones actifs (rendus publics par Apple et Google), et un peu de maths pour prendre en compte les téléphones chinois connectés à Internet. [Plus d’infos ici](https://www.ben-evans.com/benedictevans/2019/5/28/the-end-of-mobile). +4. Le nombre total de smartphones actifs a été trouvé en additionnant le nombre de téléphones Android et iPhone actifs (rendus publics par Apple et Google), et un peu de maths pour prendre en compte les téléphones chinois connectés à Internet. [Plus d’infos ici](https://www.ben-evans.com/benedictevans/2019/5/28/the-end-of-mobile). -5. Le nombre de 1,6 milliards d’ordinateurs de bureau est calculé à partir de nombres rendus publics par [Microsoft](https://web.archive.org/web/20181030132235/https://news.microsoft.com/bythenumbers/en/windowsdevices) et [Apple](https://web.archive.org/web/20190628161024/https://appleinsider.com/articles/18/10/30/apple-passes-100m-active-mac-milestone-thanks-to-high-numbers-of-new-users). Il n’inclut pas les utilisateurs de PC linux. +5. Le nombre de 1,6 milliards d’ordinateurs de bureau est calculé à partir de nombres rendus publics par [Microsoft](https://web.archive.org/web/20181030132235/https://news.microsoft.com/bythenumbers/en/windowsdevices) et [Apple](https://web.archive.org/web/20190628161024/https://appleinsider.com/articles/18/10/30/apple-passes-100m-active-mac-milestone-thanks-to-high-numbers-of-new-users). Il n’inclut pas les ordinateurs Linux.

From 9fdb62c08f5f7e07523386a20f97a376d60fb8b0 Mon Sep 17 00:00:00 2001 From: Boris SCHAPIRA Date: Wed, 20 May 2020 14:40:02 +0200 Subject: [PATCH 05/18] Using French chevrons --- src/content/fr/2019/mobile-web.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/content/fr/2019/mobile-web.md b/src/content/fr/2019/mobile-web.md index 7bd510d99af..bb515a87375 100644 --- a/src/content/fr/2019/mobile-web.md +++ b/src/content/fr/2019/mobile-web.md @@ -15,7 +15,7 @@ last_updated: 2019-11-23T00:00:00.000Z ## Introduction -Remontons un instant dans le temps, jusqu’à l’année 2007. Le "web mobile" n’est pour l’instant que balbutiant, et pour de bonnes raisons. Pourquoi ? Les navigateurs mobiles ne prennent pas ou peu en charge le CSS, ce qui signifie que les sites ne ressemblent pas du tout à leur version sur ordinateur de bureau – certains navigateurs ne peuvent afficher que du texte. Les écrans sont incroyablement petits et ne peuvent afficher que quelques lignes de texte à la fois. Et en guise de souris, de minuscules touches fléchées utilisées pour "tabuler". Il va sans dire que naviguer sur le web avec un téléphone est un véritable sacerdoce. Mais tout est sur le point de changer. +Remontons un instant dans le temps, jusqu’à l’année 2007. Le « web mobile » n’est pour l’instant que balbutiant, et pour de bonnes raisons. Pourquoi ? Les navigateurs mobiles ne prennent pas ou peu en charge le CSS, ce qui signifie que les sites ne ressemblent pas du tout à leur version sur ordinateur de bureau – certains navigateurs ne peuvent afficher que du texte. Les écrans sont incroyablement petits et ne peuvent afficher que quelques lignes de texte à la fois. Et en guise de souris, de minuscules touches fléchées utilisées pour « tabuler ». Il va sans dire que naviguer sur le web avec un téléphone est un véritable sacerdoce. Mais tout est sur le point de changer. Au milieu de sa présentation, Steve Jobs prend l’iPhone qu’il vient juste de dévoiler, s’assoit et commence à surfer sur le web d’une manière dont nous n’avions jamais rêvé auparavant. Un grand écran et un navigateur complet affichant les sites web dans toute leur splendeur. Et surtout, en surfant sur le web à l’aide du dispositif de pointage le plus intuitif connu de l’Homme : ses doigts. Plus besoin de tabulations avec de minuscules touches fléchées. @@ -122,9 +122,9 @@ Nous pensons que cette situation est due en grande partie au fait que les sites ### Demandes d’autorisation -Ces dernières années, la démarcation entre les sites web et les applications "app store" n’a cessé de s’estomper. Au point qu'aujourd’hui, vous avez la possibilité de demander l’accès au microphone, à la caméra vidéo, à la géolocalisation, à la possibilité d’afficher des notifications, etc. +Ces dernières années, la démarcation entre les sites web et les applications « App Store » n’a cessé de s’estomper. Au point qu'aujourd’hui, vous avez la possibilité de demander l’accès au microphone, à la caméra vidéo, à la géolocalisation, à la possibilité d’afficher des notifications, etc. -Bien que cela ait ouvert encore plus de possibilités aux équipes de développement, le fait de demander inutilement ces autorisations peut inciter les utilisateurs et utilisatrices à se méfier de votre page web. C’est pourquoi nous recommandons de toujours lier une demande de permission à une action de la personne utilisant le site, par exemple en appuyant sur le bouton "Trouver des cinémas près de chez moi". +Bien que cela ait ouvert encore plus de possibilités aux équipes de développement, le fait de demander inutilement ces autorisations peut inciter les utilisateurs et utilisatrices à se méfier de votre page web. C’est pourquoi nous recommandons de toujours lier une demande de permission à une action de la personne utilisant le site, par exemple en appuyant sur le bouton « Trouver des cinémas près de chez moi ». Actuellement, 1,52 % des sites demandent des autorisations sans aucune intervention. Il est encourageant de voir un nombre aussi faible. Cependant, il est important de noter que nous n’avons pu analyser que les pages d’accueil. Ainsi, par exemple, les sites ne demandant des autorisations que sur leurs pages de contenu (par exemple, leurs articles de blog) n’ont pas été pris en compte. Voir notre page [Méthodologie](./methodology) pour plus d’informations. @@ -172,7 +172,7 @@ Pour cette raison, les équipes de développement ont la possibilité de désact Figure 5. Pourcentage de sites web de bureau et mobiles qui activent ou désactivent la possibilité de zoomer / la mise à l’échelle. - +
Figure 5. Pourcentage de sites web de bureau et mobiles qui activent ou désactivent la possibilité de zoomer / la mise à l’échelle.
@@ -198,7 +198,7 @@ Il peut être difficile de concevoir des cibles d’appui appropriées pour att
Figure 6. Normes de dimensionnement et d’espacement des cibles d’appui. Image reproduite avec l’aimable autorisation de LookZook.
-À l’heure actuelle, 34,43 % des sites ont des cibles d’appui suffisamment grandes. Nous avons donc encore beaucoup de chemin à parcourir avant que les erreurs liées aux "gros doigts" soient derrière nous. +À l’heure actuelle, 34,43 % des sites ont des cibles d’appui suffisamment grandes. Nous avons donc encore beaucoup de chemin à parcourir avant que les erreurs liées aux « gros doigts » soient derrière nous. ### Libellés des boutons @@ -216,7 +216,7 @@ Qu’il s’agisse de s’inscrire à un nouveau service, d’acheter quelque ch Dans le passé, `text` et `password` étaient parmi les seuls types de saisie (``) disponibles pour les équipes de développement, car ils répondaient à presque tous nos besoins sur ordinateurs de bureau. Ce n’est pas le cas pour les appareils mobiles. Les claviers mobiles sont incroyablement petits, et une tâche simple, comme la saisie d’une adresse électronique, peut obliger les utilisateurs à passer d’un clavier à l’autre : le clavier standard et le clavier à caractères spéciaux pour le symbole "@". La simple saisie d’un numéro de téléphone peut être difficile en utilisant les minuscules chiffres du clavier par défaut. -De nombreux [nouveaux types de saisies](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#Form_%3Cinput%3E_types) ont été introduits depuis, permettant aux équipes de développement d’informer les navigateurs du type de données attendu et permettant aux navigateurs de fournir des claviers personnalisés spécifiquement pour ces types de saisie. Par exemple, le type `email` permet au navigateur de fournir un clavier alphanumérique comprenant le symbole "@", et le type `tel`, un clavier numérique. +De nombreux [nouveaux types de saisies](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#Form_%3Cinput%3E_types) ont été introduits depuis, permettant aux équipes de développement d’informer les navigateurs du type de données attendu et permettant aux navigateurs de fournir des claviers personnalisés spécifiquement pour ces types de saisie. Par exemple, le type `email` permet au navigateur de fournir un clavier alphanumérique comprenant le symbole `@`, et le type `tel`, un clavier numérique. Lors de l’analyse des sites contenant une saisie d’email, 56,42 % utilisent `type="email"`. De même, pour les saisies de numéros de téléphone, `type="tel"` est utilisé 36,7 % du temps. Les autres nouveaux types de saisie ont un taux d’adoption encore plus faible. From 07d6137309a26d989d169721e6b5acde4a9eabbd Mon Sep 17 00:00:00 2001 From: Boris SCHAPIRA Date: Wed, 20 May 2020 14:41:02 +0200 Subject: [PATCH 06/18] `lang="en"` on "Javascript bloat score" --- src/content/fr/2019/mobile-web.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/fr/2019/mobile-web.md b/src/content/fr/2019/mobile-web.md index bb515a87375..bd0231025de 100644 --- a/src/content/fr/2019/mobile-web.md +++ b/src/content/fr/2019/mobile-web.md @@ -66,7 +66,7 @@ Pourquoi est-ce un problème ? Parce que les sites qui chargent autant de J
Figure 2. Exemple d’une expérience pénible où l’on attend que JS se charge.
-Allons plus loin et examinons une autre mesure qui se concentre davantage sur _comment_ chaque page utilise JavaScript. Par exemple, a-t-elle vraiment besoin d’autant de JavaScript pendant qu’elle se charge ? Nous appelons cette mesure le _JavaScript Bloat Score_ (en français, score de surcharge de JavaScript), basé sur le [web bloat score](https://www.webbloatscore.com/). L’idée derrière tout cela est la suivante : +Allons plus loin et examinons une autre mesure qui se concentre davantage sur _comment_ chaque page utilise JavaScript. Par exemple, a-t-elle vraiment besoin d’autant de JavaScript pendant qu’elle se charge ? Nous appelons cette mesure le JavaScript Bloat Score (en français, score de surcharge de JavaScript), basé sur le [web bloat score](https://www.webbloatscore.com/). L’idée derrière tout cela est la suivante : - JavaScript est souvent utilisé pour générer et modifier la page lors de son chargement ; - il est également livré sous forme de texte au navigateur. Il se compresse donc bien et devrait être livré plus rapidement qu’une simple capture d’écran de la page ; From 9720a7f30b019df1cf1de0b7003725f4c7cbc092 Mon Sep 17 00:00:00 2001 From: Boris SCHAPIRA Date: Wed, 20 May 2020 14:42:00 +0200 Subject: [PATCH 07/18] Missing non-break spaces --- src/content/fr/2019/mobile-web.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/content/fr/2019/mobile-web.md b/src/content/fr/2019/mobile-web.md index bd0231025de..eba3ee65209 100644 --- a/src/content/fr/2019/mobile-web.md +++ b/src/content/fr/2019/mobile-web.md @@ -74,7 +74,7 @@ Allons plus loin et examinons une autre mesure qui se concentre davantage sur _c

Le JavaScript Bloat Score est défini comme suit : (taille totale du JavaScript) / (taille de la capture d’écran PNG du port d’affichage). Tout nombre supérieur à 1 signifie qu’il est plus rapide d’envoyer une capture d’écran.

-Quels en sont les résultats ? Sur les plus de 5 millions de sites web analysés, 75,52 % étaient surchargés de JavaScript. Nous avons encore un long chemin à parcourir. +Quels en sont les résultats ? Sur les plus de 5 millions de sites web analysés, 75,52 % étaient surchargés de JavaScript. Nous avons encore un long chemin à parcourir. Notez que nous n’avons pas été en mesure de capturer et de mesurer les captures d’écran de plus de 5 millions de sites que nous avons analysés. Nous avons plutôt pris un échantillon aléatoire de 1000 sites pour trouver la taille médiane des captures d’écran (140 Ko), puis nous avons comparé la taille de téléchargement de JavaScript de chaque site à ce nombre. @@ -180,7 +180,7 @@ Cependant, les équipes de développement ont tellement abusé de cette fonction ### Rotation des pages -Certains appareils mobiles peuvent être tournés afin que votre site web soit affiché au format préféré des utilisateurs et utilisatrices. Cependant, les gens ne gardent pas toujours la même orientation tout au long d’une session. Lorsqu’ils remplissent des formulaires, ils peuvent passer en mode paysage pour utiliser le clavier plus grand. Ou bien, lorsqu’ils naviguent sur les produits, certains peuvent préférer les images de produits plus grandes que leur propose le mode paysage. En raison de ces types de cas d’utilisation, il est très important de ne pas les priver de cette capacité intégrée des appareils mobiles. Et la bonne nouvelle, c’est que nous n’avons trouvé pratiquement aucun site qui désactive cette fonction. Seuls 87 sites au total (soit 0,0016 %) désactivent cette fonction. C’est fantastique. +Certains appareils mobiles peuvent être tournés afin que votre site web soit affiché au format préféré des utilisateurs et utilisatrices. Cependant, les gens ne gardent pas toujours la même orientation tout au long d’une session. Lorsqu’ils remplissent des formulaires, ils peuvent passer en mode paysage pour utiliser le clavier plus grand. Ou bien, lorsqu’ils naviguent sur les produits, certains peuvent préférer les images de produits plus grandes que leur propose le mode paysage. En raison de ces types de cas d’utilisation, il est très important de ne pas les priver de cette capacité intégrée des appareils mobiles. Et la bonne nouvelle, c’est que nous n’avons trouvé pratiquement aucun site qui désactive cette fonction. Seuls 87 sites au total (soit 0,0016 %) désactivent cette fonction. C’est fantastique. ## Boutons et liens @@ -253,7 +253,7 @@ L’attribut [`autocomplete`](https://developer.mozilla.org/en-US/docs/Web/HTML/
Figure 8. Pourcentage des pages utilisant autocomplete.
-Actuellement, seules 29,62 % des pages comportant des champs de saisie utilisent cette fonction. +Actuellement, seules 29,62 % des pages comportant des champs de saisie utilisent cette fonction. ### Saisie des champs de mot de passe From 099f0a0e8fc7d5719925a6071f86eaf8ac6a9e1e Mon Sep 17 00:00:00 2001 From: Boris SCHAPIRA Date: Wed, 20 May 2020 14:48:23 +0200 Subject: [PATCH 08/18] `lang="en"` on Layout Instability API --- src/content/fr/2019/mobile-web.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/fr/2019/mobile-web.md b/src/content/fr/2019/mobile-web.md index eba3ee65209..ca64e9a0fe5 100644 --- a/src/content/fr/2019/mobile-web.md +++ b/src/content/fr/2019/mobile-web.md @@ -100,7 +100,7 @@ L’une des plus belles réussites du web est la façon dont les pages web se ch Imaginez que vous êtes en train de lire un article quand, tout à coup, une image se charge et repousse le texte que vous lisez tout en bas de l’écran. Vous devez maintenant chercher où vous étiez ou simplement abandonner la lecture de l’article. Ou, pire encore, vous commencez à cliquer sur un lien juste avant qu’une annonce se charge au même endroit, ce qui se traduit par un clic accidentel sur l’annonce au lieu du lien. -Alors, comment mesurer à quel point nos sites se transforment ? Dans le passé, c’était assez difficile (voire impossible), mais grâce à la nouvelle [API Layout Instability](https://web.dev/layout-instability-api) (en français, « instabilité de la mise en page »), nous pouvons le faire en deux étapes : +Alors, comment mesurer à quel point nos sites se transforment ? Dans le passé, c’était assez difficile (voire impossible), mais grâce à la nouvelle Layout Instability API (en français, « API relatives à l’instabilité de la mise en page »), nous pouvons le faire en deux étapes : 1. via l’API Layout Instability, vous pouvez mesurer l’impact de chaque mouvement dans la page. Cette mesure vous est communiqué sous la forme d’un pourcentage de la quantité de contenu du viewport (la fenêtre de visualisation) qui a changé. From b58daf436388f4fc0006bc55f19f38a1dffc0f83 Mon Sep 17 00:00:00 2001 From: Boris SCHAPIRA Date: Wed, 20 May 2020 14:49:05 +0200 Subject: [PATCH 09/18] Missing apostrophe --- src/content/fr/2019/mobile-web.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/fr/2019/mobile-web.md b/src/content/fr/2019/mobile-web.md index ca64e9a0fe5..a5a4f1502c1 100644 --- a/src/content/fr/2019/mobile-web.md +++ b/src/content/fr/2019/mobile-web.md @@ -106,7 +106,7 @@ Alors, comment mesurer à quel point nos sites se transforment ? Dans le pa 2. additionnez tous les changements que vous avez relevés. Le résultat est ce que nous appelons le score de [Cumulative Layout Shift](https://web.dev/layout-instability-api#a-cumulative-layout-shift-score) (CLS). -Comme chaque visiteur peut avoir un CLS différent, afin d’analyser cette mesure sur le web avec le [Chrome UX Report](./methodology#chrome-ux-report) (CrUX), nous rangeons chaque expérience dans l'un de ces trois ensembles distincts : +Comme chaque visiteur peut avoir un CLS différent, afin d’analyser cette mesure sur le web avec le [Chrome UX Report](./methodology#chrome-ux-report) (CrUX), nous rangeons chaque expérience dans l’un de ces trois ensembles distincts : - **Petit** CLS : regroupe les expériences ayant des CLS _en dessous de 5 %_. C’est-à-dire que la page est globalement stable ; ne varie pas beaucoup voire pas du tout. Pour mettre les choses en perspective, la page de la vidéo ci-dessus a un CLS de 42,59 %. - **Grand** CLS : regroupe les expériences ayant un CLS de _100 % ou plus_. Il peut s’agir de nombreuses petites variations individuelles ou d’un nombre plus réduit de changements importants et significatifs. From ce333f2dee35aa85a560b2f1bbf3a0c2d23b5fc9 Mon Sep 17 00:00:00 2001 From: Boris SCHAPIRA Date: Wed, 20 May 2020 14:50:36 +0200 Subject: [PATCH 10/18] Using `` around hexa-defined colors --- src/content/fr/2019/mobile-web.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/fr/2019/mobile-web.md b/src/content/fr/2019/mobile-web.md index a5a4f1502c1..518e6f442d3 100644 --- a/src/content/fr/2019/mobile-web.md +++ b/src/content/fr/2019/mobile-web.md @@ -142,7 +142,7 @@ Pour nous aider à surmonter ces problèmes, il existe des [directives d’acces Figure 4. Exemple de ce à quoi ressemble un texte dont le contraste des couleurs est insuffisant. Avec l’aimable autorisation de LookZook - +
Figure 4. Exemple de ce à quoi ressemble un texte dont le contraste des couleurs est insuffisant. Avec l’aimable autorisation de LookZook
From c7ba35ad8b3deb5fa3a654dd0b135bcbb218276b Mon Sep 17 00:00:00 2001 From: Boris SCHAPIRA Date: Wed, 20 May 2020 14:52:53 +0200 Subject: [PATCH 11/18] Missing space --- src/content/fr/2019/mobile-web.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/fr/2019/mobile-web.md b/src/content/fr/2019/mobile-web.md index 518e6f442d3..390f0a578c6 100644 --- a/src/content/fr/2019/mobile-web.md +++ b/src/content/fr/2019/mobile-web.md @@ -176,7 +176,7 @@ Pour cette raison, les équipes de développement ont la possibilité de désact
Figure 5. Pourcentage de sites web de bureau et mobiles qui activent ou désactivent la possibilité de zoomer / la mise à l’échelle.
-Cependant, les équipes de développement ont tellement abusé de cette fonctionnalité qu’aujourd’hui, près d’un site sur trois (32,21 %) la désactive, et Apple (à partir d’iOS 10) ne permet plus aux équipes de développement web de désactiver le zoom. Safari Mobile ignore simplement [la balise](https://archive.org/details/ios-10-beta-release-notes). Tous les sites, quoi qu’il en soit, peuvent être zoomés et mis à l’échelle sur les nouveaux appareils Apple, qui représentent plus de [11%](https://gs.statcounter.com/) de tout le trafic web dans le monde ! +Cependant, les équipes de développement ont tellement abusé de cette fonctionnalité qu’aujourd’hui, près d’un site sur trois (32,21 %) la désactive, et Apple (à partir d’iOS 10) ne permet plus aux équipes de développement web de désactiver le zoom. Safari Mobile ignore simplement [la balise](https://archive.org/details/ios-10-beta-release-notes). Tous les sites, quoi qu’il en soit, peuvent être zoomés et mis à l’échelle sur les nouveaux appareils Apple, qui représentent plus de [11 %](https://gs.statcounter.com/) de tout le trafic web dans le monde ! ### Rotation des pages From fe9f8c1506023b1c86b17ba4da11bfec02dde658 Mon Sep 17 00:00:00 2001 From: Boris Schapira Date: Wed, 20 May 2020 15:14:43 +0200 Subject: [PATCH 12/18] Update src/content/fr/2019/mobile-web.md Co-authored-by: Barry Pollard --- src/content/fr/2019/mobile-web.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/fr/2019/mobile-web.md b/src/content/fr/2019/mobile-web.md index 390f0a578c6..4e99add3989 100644 --- a/src/content/fr/2019/mobile-web.md +++ b/src/content/fr/2019/mobile-web.md @@ -263,7 +263,7 @@ Permettre aux utilisateurs de copier et de coller leurs mots de passe dans votre ## Conclusion -Pendant plus de 13 ans, nous avons traité le web mobile de façon accessoire, comme une vulgaire alternative aux sites pour ordinateurs de bureau. Mais il est temps que cela change. Le web mobile est maintenant _*le*_ web, et les sites pour ordinateurs de bureau tombent en désuétude. Il y a maintenant 4 milliards de smartphones actifs dans le monde, couvrant 70 % de tous les utilisateurs potentiels. Qu’en est-il des ordinateurs de bureau ? Ils sont actuellement 1,6 milliard et représentent de moins en moins d’utilisateurs du web chaque mois. +Pendant plus de 13 ans, nous avons traité le web *mobile* de façon accessoire, comme une vulgaire alternative aux sites pour ordinateurs de bureau. Mais il est temps que cela change. Le web mobile est maintenant *le* web, et les sites pour ordinateurs de bureau tombent en désuétude. Il y a maintenant 4 milliards de smartphones actifs dans le monde, couvrant 70 % de tous les utilisateurs potentiels. Qu’en est-il des ordinateurs de bureau ? Ils sont actuellement 1,6 milliard et représentent de moins en moins d’utilisateurs du web chaque mois. Comment nous débrouillons-nous pour répondre aux besoins des utilisateurs de téléphones portables ? Selon nos recherches, même si 71 % des sites font des efforts pour adapter leur site au mobile, ils sont loin d’atteindre leur objectif. Les pages mettent une éternité à se charger et deviennent inutilisables en raison d’un abus de JavaScript, le texte est souvent impossible à lire, l’interaction avec les sites en cliquant sur des liens ou des boutons est source d’erreurs et d’exaspération, et des tonnes de fonctionnalités formidables inventées pour atténuer ces problèmes (Service Workers, saisie automatique, zoom, nouveaux formats d’image, etc) sont à peine utilisées. From 8c4da930bf3fa2eefc4e36cfeda3b811e33724c5 Mon Sep 17 00:00:00 2001 From: Boris SCHAPIRA Date: Wed, 20 May 2020 14:54:16 +0200 Subject: [PATCH 13/18] Fix repetition --- src/content/fr/2019/mobile-web.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/fr/2019/mobile-web.md b/src/content/fr/2019/mobile-web.md index 4e99add3989..b4b903eada1 100644 --- a/src/content/fr/2019/mobile-web.md +++ b/src/content/fr/2019/mobile-web.md @@ -242,7 +242,7 @@ Lors de l’analyse des sites contenant une saisie d’email, 56,42 % utili
Figure 7. Types de saisie invalides les plus couramment utilisés
-Assurez-vous de bien vous informer et de renseigner les autres sur la grande quantité de types de saisie disponibles et vérifiez que vous n’avez pas de fautes de frappe, à l’image de des plus courantes, reprises dans la figure 7 ci-dessus. +Assurez-vous de bien vous informer et de renseigner les autres sur la grande quantité de types de saisie disponibles et vérifiez que vous n’avez pas de fautes de frappe, à l’image des plus courantes, reprises dans la figure 7 ci-dessus. ### Activation de l’autocomplétion pour les saisies From 41b2160f124a9af84ab8528c85a94f773e2ea9ac Mon Sep 17 00:00:00 2001 From: Boris SCHAPIRA Date: Wed, 20 May 2020 15:31:42 +0200 Subject: [PATCH 14/18] `lang="en"` on The Cost of JavaScript --- src/content/fr/2019/mobile-web.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/fr/2019/mobile-web.md b/src/content/fr/2019/mobile-web.md index b4b903eada1..4e245298ebb 100644 --- a/src/content/fr/2019/mobile-web.md +++ b/src/content/fr/2019/mobile-web.md @@ -78,7 +78,7 @@ Quels en sont les résultats ? Sur les plus de 5 millions de sites web anal Notez que nous n’avons pas été en mesure de capturer et de mesurer les captures d’écran de plus de 5 millions de sites que nous avons analysés. Nous avons plutôt pris un échantillon aléatoire de 1000 sites pour trouver la taille médiane des captures d’écran (140 Ko), puis nous avons comparé la taille de téléchargement de JavaScript de chaque site à ce nombre. -Pour une analyse plus approfondie des effets de JavaScript, consultez [« The Cost of JavaScript » (le coût de JavaScript) écrit en 2018](https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4) par Addy Osmani. +Pour une analyse plus approfondie des effets de JavaScript, consultez [« The Cost of JavaScript » (le coût de JavaScript) écrit en 2018](https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4) par Addy Osmani. ### Utilisation de Service Workers From 51f4dd7eb0a784ecf746b685fec27c371d80f50c Mon Sep 17 00:00:00 2001 From: Boris SCHAPIRA Date: Wed, 20 May 2020 15:32:34 +0200 Subject: [PATCH 15/18] ":" instead of ";" --- src/content/fr/2019/mobile-web.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/fr/2019/mobile-web.md b/src/content/fr/2019/mobile-web.md index 4e245298ebb..8a6bdf3a264 100644 --- a/src/content/fr/2019/mobile-web.md +++ b/src/content/fr/2019/mobile-web.md @@ -158,7 +158,7 @@ Sur l’ensemble du web, nous avons constaté que 80,66 % des pages web ré ### Zoom et mise à l’échelle -Il est incroyablement difficile de concevoir un site qui fonctionne parfaitement sur des dizaines de milliers de tailles d’écran et de dispositifs. Certaines personnes ont besoin d’une taille de police plus importante pour lire, zoomer sur les images de vos produits, ou ont besoin d’un bouton plus grand parce qu’il est trop petit et a échappé à votre équipe d’assurance qualité. C’est pour de telles raisons que les fonctions de zoom et de mise à l’échelle des appareils sont si importantes ; elles permettent aux gens de modifier nos pages pour qu’elles répondent à leurs besoins. +Il est incroyablement difficile de concevoir un site qui fonctionne parfaitement sur des dizaines de milliers de tailles d’écran et de dispositifs. Certaines personnes ont besoin d’une taille de police plus importante pour lire, zoomer sur les images de vos produits, ou ont besoin d’un bouton plus grand parce qu’il est trop petit et a échappé à votre équipe d’assurance qualité. C’est pour de telles raisons que les fonctions de zoom et de mise à l’échelle des appareils sont si importantes : elles permettent aux gens de modifier nos pages pour qu’elles répondent à leurs besoins. Il existe de très rares cas où la désactivation est acceptable, par exemple lorsque la page en question est un jeu en ligne utilisant des commandes tactiles. Si cette option est laissée activée dans ce cas, les téléphones des joueurs feront un zoom avant et arrière chaque fois que le joueur tapera deux fois sur le jeu, ce qui rendra l’expérience inutilisable. From 8423cb15601d30d345fb81c9d63e5f341c21fe72 Mon Sep 17 00:00:00 2001 From: Boris SCHAPIRA Date: Wed, 20 May 2020 15:34:02 +0200 Subject: [PATCH 16/18] `lang="en"` sur Layout Instability --- src/content/fr/2019/mobile-web.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/fr/2019/mobile-web.md b/src/content/fr/2019/mobile-web.md index 8a6bdf3a264..dbeb2ea506d 100644 --- a/src/content/fr/2019/mobile-web.md +++ b/src/content/fr/2019/mobile-web.md @@ -102,7 +102,7 @@ Imaginez que vous êtes en train de lire un article quand, tout à coup, une ima Alors, comment mesurer à quel point nos sites se transforment ? Dans le passé, c’était assez difficile (voire impossible), mais grâce à la nouvelle Layout Instability API (en français, « API relatives à l’instabilité de la mise en page »), nous pouvons le faire en deux étapes : -1. via l’API Layout Instability, vous pouvez mesurer l’impact de chaque mouvement dans la page. Cette mesure vous est communiqué sous la forme d’un pourcentage de la quantité de contenu du viewport (la fenêtre de visualisation) qui a changé. +1. via l’API Layout Instability, vous pouvez mesurer l’impact de chaque mouvement dans la page. Cette mesure vous est communiqué sous la forme d’un pourcentage de la quantité de contenu du viewport (la fenêtre de visualisation) qui a changé. 2. additionnez tous les changements que vous avez relevés. Le résultat est ce que nous appelons le score de [Cumulative Layout Shift](https://web.dev/layout-instability-api#a-cumulative-layout-shift-score) (CLS). From eb56ff6cf5468a21a12495da09f3f6adbdf11e97 Mon Sep 17 00:00:00 2001 From: Boris SCHAPIRA Date: Wed, 20 May 2020 15:34:41 +0200 Subject: [PATCH 17/18] "@" --- src/content/fr/2019/mobile-web.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/fr/2019/mobile-web.md b/src/content/fr/2019/mobile-web.md index dbeb2ea506d..702a0cf0f94 100644 --- a/src/content/fr/2019/mobile-web.md +++ b/src/content/fr/2019/mobile-web.md @@ -214,7 +214,7 @@ Qu’il s’agisse de s’inscrire à un nouveau service, d’acheter quelque ch ### Nouveaux types de saisie -Dans le passé, `text` et `password` étaient parmi les seuls types de saisie (``) disponibles pour les équipes de développement, car ils répondaient à presque tous nos besoins sur ordinateurs de bureau. Ce n’est pas le cas pour les appareils mobiles. Les claviers mobiles sont incroyablement petits, et une tâche simple, comme la saisie d’une adresse électronique, peut obliger les utilisateurs à passer d’un clavier à l’autre : le clavier standard et le clavier à caractères spéciaux pour le symbole "@". La simple saisie d’un numéro de téléphone peut être difficile en utilisant les minuscules chiffres du clavier par défaut. +Dans le passé, `text` et `password` étaient parmi les seuls types de saisie (``) disponibles pour les équipes de développement, car ils répondaient à presque tous nos besoins sur ordinateurs de bureau. Ce n’est pas le cas pour les appareils mobiles. Les claviers mobiles sont incroyablement petits, et une tâche simple, comme la saisie d’une adresse électronique, peut obliger les utilisateurs à passer d’un clavier à l’autre : le clavier standard et le clavier à caractères spéciaux pour le symbole `@`. La simple saisie d’un numéro de téléphone peut être difficile en utilisant les minuscules chiffres du clavier par défaut. De nombreux [nouveaux types de saisies](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#Form_%3Cinput%3E_types) ont été introduits depuis, permettant aux équipes de développement d’informer les navigateurs du type de données attendu et permettant aux navigateurs de fournir des claviers personnalisés spécifiquement pour ces types de saisie. Par exemple, le type `email` permet au navigateur de fournir un clavier alphanumérique comprenant le symbole `@`, et le type `tel`, un clavier numérique. From 9eb27ae539dd4a90db90d16c0cedfd8aed6536b1 Mon Sep 17 00:00:00 2001 From: Boris SCHAPIRA Date: Wed, 20 May 2020 15:35:22 +0200 Subject: [PATCH 18/18] Better description --- src/content/fr/2019/mobile-web.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/fr/2019/mobile-web.md b/src/content/fr/2019/mobile-web.md index 702a0cf0f94..801dc018f23 100644 --- a/src/content/fr/2019/mobile-web.md +++ b/src/content/fr/2019/mobile-web.md @@ -2,7 +2,7 @@ part_number: II chapter_number: 12 title: Web Mobile -description: Chapitre sur les web mobile du Web Almanac 2019, couvrant le chargement des pages, du contenu textuel, du zoom et de la mise à l’échelle, des boutons et des liens, et de la facilité à remplir les formulaires. +description: Chapitre sur les web mobile du Web Almanac 2019, couvrant le chargement des pages, du contenu textuel, du zoom et de la mise à l’échelle, des boutons et des liens, ainsi que de la facilité à remplir les formulaires. authors: [obto] reviewers: [AymenLoukil, hyperpress] translators: [borisschapira]
Latence300 - 400 ms300 - 400 ms
Bande passante (descendante)0.4 - 1.6 Mbps0.4 - 1,6 Mbps
Modèle