Web mobile : les erreurs les plus fré­quentes

La notion de « Mobile First » est aujourd’hui centrale pour la con­cep­tion de sites Web. En plus des tra­di­tion­nels or­di­na­teurs de bureau, les uti­li­sa­teurs utilisent de plus en plus les smart­phones ou tablettes pour surfer sur le Web depuis n’importe où. Pour garantir la réussite de votre projet Web, un site adapté pour le Web mobile devient donc obli­ga­toire. Toutefois, un site Internet mobile est loin d’être synonyme d’une bonne ex­pé­rience uti­li­sa­teur et d’une bonne op­ti­mi­sa­tion mobile pour les moteurs de recherche. Nous listons dans cet article les erreurs les plus courantes et vous apportons des conseils pour améliorer votre projet Internet.

Compte tenu de l’expansion du nombre d’in­ter­nautes mobiles, il est clair que les dé­ve­lop­peurs ne peuvent désormais plus ignorer la tendance du Web mobile et le défi que cela re­pré­sente. C’est aussi l’occasion d’attirer de nouveaux groupes cibles et de relier et guider les visiteurs mobiles vers votre propre site Internet. L’objectif doit donc être d’améliorer l’in­tui­ti­vité et de réaliser une op­ti­mi­sa­tion mobile pour les dif­fé­rents pé­ri­phé­riques : smart­phones, tablettes etc. La nouvelle approche du Web design tient justement compte de cette tendance. C’est pourquoi, les sites mobiles, le res­pon­sive Web design (ou con­cep­tion de sites web adap­ta­tifs) et les ap­pli­ca­tions sont aujourd’hui im­por­tants. Pour en savoir plus sur les dif­fé­rences entre ces trois options de présence Web mobile, vous pouvez lire notre article dédié. En outre l’op­ti­mi­sa­tion mobile est un facteur de clas­se­ment important pour les moteurs de recherche comme Google. Il existe cependant de nombreux pièges à éviter lors de la res­truc­tu­ra­tion de votre site Web.

La première erreur fon­da­men­tale de base peut survenir lors du choix de la variante de con­fi­gu­ra­tion. En effet il existe plusieurs façons de créer un site Web mobile : comme par exemple avec un site Web adaptatif (res­pon­sive Web design en anglais), un site Internet mobile distinct ou via un simple agen­ce­ment adaptatif. La solution la plus agréable est cer­tai­ne­ment le res­pon­sive Web design. En effet, par rapport aux sites mobiles séparés et aux dis­po­si­tions adap­ta­tives, un site Web adaptatif est préféré par Google pour un bon clas­se­ment. Un autre avantage est le fait que les dis­po­si­tifs in­di­vi­duels et les systèmes d’ex­ploi­ta­tion n’ont pas besoin d’être adaptés parce que justement les écrans s’ajustent au­to­ma­ti­que­ment. Ainsi, cela demande un effort de main­te­nance moindre pour les opé­ra­teurs Web et les visiteurs du site Web bé­né­fi­cient d’une même usabilité. Il est donc important de bien iden­ti­fier votre groupe cible et de répondre aux questions suivantes : quels sont les appareils et tailles d’écran per­ti­nents pour vos visiteurs et pour votre site Web ? Avec quelle variante de con­fi­gu­ra­tion pouvez-vous offrir la meilleure ex­pé­rience uti­li­sa­teur à vos visiteurs ? En effet, si dès le début vous choi­sis­sez la bonne variante de con­fi­gu­ra­tion, vous pouvez alors éviter de nom­breuses erreurs que nous allons aborder par la suite. L’uti­li­sa­tion du res­pon­sive Web design est donc un avantage, pour des aspects complexes mais aussi d’un point de vue SEO et de l’ergonomie Web. A noter, une re­con­ver­sion ul­té­rieure à cette variante est complexe et très couteuse. Cependant, il est important de préciser qu’un site Web adaptatif n’est pas toujours adapté pour chaque projet Web : des sites Internet complexes, qui par exemple possèdent une grande quantité de données, se chargent lentement sur des appareils mobiles avec une connexion médiocre ou via un pé­ri­phé­rique mobile ancien ou peu puissant.

Ceci nous mène vers la seconde source d’erreur courante, à savoir l’interface uti­li­sa­teur. Etant donné que les dis­po­si­tifs mobiles fonc­tion­nent ha­bi­tuel­le­ment avec un écran tactile, les mauvaises décisions au niveau de l’interface graphique peuvent conduire à des per­tur­ba­tions im­por­tantes. Cela inclut aussi l’uti­li­sa­tion d’une police trop petite, d’une zone d’affichage non définie, de liens et de boutons mal disposés (pas assez d’espace entre deux boutons) ou encore d’une mauvaise na­vi­ga­tion.

Pour qu’une page Web puisse s’afficher cor­rec­te­ment, il est essentiel de définir une zone d’affichage. Si vous ne le faites pas, la largeur par défaut de l’écran est utilisée au­to­ma­ti­que­ment, même sur les écrans plus petits. Cela force ainsi les uti­li­sa­teurs de votre site Web à zoomer et à devoir faire défiler le reste de la page ho­ri­zon­ta­le­ment, ce qui dans le Web mobile est par­ti­cu­liè­re­ment re­gret­table. La solution à ce problème est d’entrer une balise meta viewport dans l’en-tête de votre document ; elle sert en effet à contrôler la mise en page sur les na­vi­ga­teurs mobiles et va indiquer à ces deniers comment mesurer et mettre la page à l’échelle. Pour cela, Google re­com­mande la ligne suivante :

L’in­di­ca­tion « width=device-width » signale que la largeur de l’écran doit être adaptée à l’appareil (device). L’in­di­ca­tion « initial-scale=1 » est là pour assurer une relation 1:1 entre le CSS et les pixels in­dé­pen­dants du pé­ri­phé­rique et garantit le non chan­ge­ment de la mise à l’échelle quand l’appareil est notamment incliné ou retourné.

Il est très frustrant et énervant pour les uti­li­sa­teurs de votre projet Web de ne pas pouvoir lire cor­rec­te­ment les textes. Ainsi, pour rendre la police d’écriture lisible pour chaque pé­ri­phé­rique, il est conseillé d’utiliser des tailles de police relatives qui peuvent être di­men­sion­nées avec CSS. Comme police de référence, la re­com­man­da­tion de Google est de 16 pixels CSS. Les autres tailles sont réduites par rapport à la taille de base. Ceci est par exemple réalisé à l’aide de la classe CSS suivante :

Les 75 % de la taille de police de base cor­res­pon­dent donc à 12 pixels CSS. La classe CSS « large » cor­res­pond à 125 % de la taille de la police de base, soit 20 pixels CSS. Malgré la dé­fi­ni­tion des tailles de police relatives, il est conseillé de ne pas sur­char­ger la mise en page de votre site en utilisant inu­ti­le­ment de nom­breuses polices et de nom­breuses tailles dif­fé­rentes. Cela risque en effet de sur­char­ger le site, de le com­plexi­fier et ainsi d’amoindrir la li­si­bi­lité du site Internet mobile.

Si vous avez déjà ex­pé­ri­menté la fonction « toucher et glisser » (touch and swipe) sur un site Internet mobile avec un écran tactile, vous con­nais­sez alors par ex­pé­rience l’im­por­tance d’une véritable in­té­gra­tion des contrôles. Si les liens et les boutons sont trop proches, il est alors difficile de naviguer et cela re­pré­sente une faute de con­cep­tion grave au niveau du Web mobile. Il faut en effet penser que le doigt d’un adulte est na­tu­rel­le­ment plus large qu’un curseur de souris standard sur les or­di­na­teurs de bureau : en moyenne de 10 mm. Par con­sé­quent, les éléments cli­quables sur les sites optimisés Web mobile doivent être placés avec une distance suf­fi­sante les uns des autres et avoir une taille adéquate. S’ils sont trop proches les uns des autres, il existe alors un risque de cliquer sur un mauvais lien, ce qui énerve l’uti­li­sa­teur et apporte une mauvaise ex­pé­rience uti­li­sa­teur. Enfin, pour les boutons, Google re­com­mande une largeur minimale de 7 mm ou 48 pixels CSS.

Sur le Web mobile, de nom­breuses con­sul­ta­tions de pages se font à la volée. Les adjectifs « rapide » et « court » doivent être pris au sérieux lors de la con­cep­tion de votre site mobile. Par con­sé­quent, un site avec une op­ti­mi­sa­tion mobile doit avoir une fonction de recherche in­tel­li­gente et facile à trouver. Cette fonction devrait gé­né­ra­le­ment se trouver cen­tra­le­ment sur la page d’accueil et être visible en un coup d’œil. Les requêtes de recherche doivent également être com­plé­tées par la fonc­tion­na­lité d’auto-com­plé­tion pour faciliter et accélérer la tâche aux uti­li­sa­teurs utilisant un clavier d’écran tactile.

Il est ennuyeux et énervant de patienter sur une page blanche et vide et de devoir regarder la barre de char­ge­ment lors de la na­vi­ga­tion sur Internet. Les temps de char­ge­ment sont con­si­dé­rés comme des vé­ri­tables « con­ver­sion-killer » : selon l’étude anglaise de Kiss­me­trics, 40% des personnes aban­don­nent la con­sul­ta­tion d’un site Internet si cela nécessite plus de 3 secondes de char­ge­ment. Juste une seconde de retard peut entraîner une réduction des con­ver­sions de 7 pourcent. En effet, les uti­li­sa­teurs de­vien­nent de plus en plus im­pa­tients et exigeants. Un temps de char­ge­ment long n’est pas sim­ple­ment un problème pour les boutiques en ligne, mais pour n’importe quel site Internet que vous décidez de visiter et qui pourrait être in­ter­rompu quand vous perdez le signal par exemple dans le métro ou à la campagne. Les erreurs courantes con­cer­nant la per­for­mance sont notamment :

• Les images non com­pres­sées et /ou formats d’image trop vo­lu­mi­neux
• Trop d’images ou d’éléments mul­ti­mé­dias.
• Des codes HTML et CSS impurs
• Trop de Ja­vaS­cript
• Le code source non comprimé
• Trop de requêtes HTTP
• Re­di­rec­tions
• Manque de mise en cache du na­vi­ga­teur
• Un serveur lent

Quelques in­ter­ven­tions suffisent pour régler la plupart de ces erreurs. Il est possible par exemple d’utiliser l’outil Google PageSpeed Insights. Avec cet outil, il est en effet possible de vérifier la vitesse de char­ge­ment de votre site Web et d’obtenir en par ailleurs des in­for­ma­tions im­por­tantes pour l’op­ti­mi­sa­tion mobile de votre site. Vous pouvez par la suite prendre des mesures ciblées. Par exemple :

• Comprimer les images : dans notre article sur ce sujet nous avons déjà abordé l’im­por­tance de la com­pres­sion. Il est notamment possible d’utiliser des outils gratuits ou des ap­pli­ca­tions spéciales basées sur un na­vi­ga­teur. Vous pouvez adapter le format de l’image ap­pro­priée avec la balise <picture> et @media. Les formats de fichier re­com­man­dés sont : JPEG, GIF et PNG.

• Al­ter­na­ti­ve­ment il est possible de recourir à Pure CSS, IconFonts ou SVG à la place d’images.

• Pour nettoyer et com­pres­ser les codes HTML, CSS et Ja­vaS­cript, il existe aussi des outils spé­ci­fiques. Toutefois, la sup­pres­sion des espaces inutiles et le dé­pla­ce­ment des fichiers Ja­vaS­cript à la fin du corps peut déjà faire quelques mer­veilles. Nous vous proposons quelques outils et conseils pour CSS.

• L’uti­li­sa­tion de la mise en cache pour soulager les serveurs Web peut gran­de­ment améliorer le temps de char­ge­ment pour les uti­li­sa­teurs ré­cur­rents. Grâce aux ap­pli­ca­tions Web pro­gres­sives, la mise en cache hors ligne offre également de meil­leures per­for­mances.

• Réduire le nombre de requêtes HTTP en groupant les res­sources.

• Améliorer la per­for­mance du système de gestion de contenu (CMS).

• Si votre site reçoit de nom­breuses demandes de l’étranger, vous pouvez utiliser un réseau de diffusion de contenu (CDN).

• Ac­ce­le­ra­ted Mobile Pages (AMP) : cette tech­no­lo­gie open source peut également offrir de meil­leures per­for­mances.

• Si ces mesures ne sont pas suf­fi­santes, l’amé­lio­ra­tion de l’en­vi­ron­ne­ment d’hé­ber­ge­ment peut aider. Les sites Internet à fort trafic devraient avoir un espace Web et un trafic illimités. Une mise à niveau ma­té­rielle, comme la com­mu­ta­tion vers un stockage SSD plus rapide augmente également les per­for­mances.

Le but de Google est de rendre le contenu des sites Internet mobiles plus ac­ces­sible. Des pages in­ters­ti­tielles trop grandes comme dans l’exemple ci-dessus où le contenu recherché est to­ta­le­ment bloqué ne doit donc pas être utilisé.

Comme le Googlebot indexe le contenu d’un site Web, ce dernier ne devrait pas être bloqué par les robots.txt. Cela signifie que, comme tout uti­li­sa­teur normal, il doit pouvoir avoir accès à tous les fichiers CSS, Ja­vaS­cript et les images. Si au contraire il y a des li­mi­ta­tions via les fichiers robots.txt, du contenu important risque de ne pas être indexé, ce qui peut aboutir à un mauvais clas­se­ment.

Vous pouvez utiliser Google Search Console pour analyser votre site Internet en utilisant la fonction « Fetch as Google » pour voir comment le bot de Google analyse et indexe votre site Web. Vous pouvez aussi examiner le fichier robots.txt à l’aide de cet outil et voir ainsi quels éléments peuvent être bloqués.

Si vous optez pour la solution d’un site Internet mobile distinct au lieu du res­pon­sive web design (ou site res­pon­sive), il existe alors quelques pièges pour l’op­ti­mi­sa­tion mobile de votre site. Notamment les mauvaises re­di­rec­tions et les erreurs 404 qui ap­pa­rais­sent uni­que­ment sur les sites Web mobiles mais pas pour les uti­li­sa­teurs d’un or­di­na­teur de bureau (desktop).

Compte tenu du nombre d’uti­li­sa­teurs de l’Internet mobile, il serait contre-productif de créer un site Internet mobile spé­ci­fique, de le négliger et d’offrir une version allégée du contenu du site Web classique de bureau. C’est une idée fausse de croire que les pé­ri­phé­riques mobiles sont ex­clu­si­ve­ment utilisés pour les re­cherches courtes et uni­que­ment afin d’obtenir une in­for­ma­tion rapide : 61% des uti­li­sa­teurs du Web mobile utilisent chez eux un smart­phone ou une tablette, notamment sur le canapé. C’est en effet le résultat d’une étude anglo-saxonne de inMobi. Chez soi, l’or­di­na­teur de bureau est ha­bi­tuel­le­ment à portée de main, toutefois les in­ter­nautes préfèrent continuer à utiliser un appareil mobile. Il peut se révéler qu’un in­ter­naute ne trouve pas le même contenu et les mêmes in­for­ma­tions via une na­vi­ga­tion Web mobile que sur la page classique de bureau qui lui est familière. Ce constat est frustrant et demande un effort sup­plé­men­taire pour l’in­ter­naute. Il est donc souvent obligé d’afficher la version desktop du site Internet et doit s’adapter à une ma­ni­pu­la­tion com­pli­quée (zoom, liens trop petits, menu hover etc.). C’est encore pire quand l’in­ter­naute ne trouve pas de lien vers la version desktop sur le site Web mobile et va donc re­cher­cher le contenu sur un autre site Internet mieux adapté et optimisé pour les appareils mobiles. C’est pourquoi, un site Internet mobile doit posséder tout le contenu important et les mêmes fonctions que celles de la version de bureau.

Le site we­choo­se­the­moon.org est vraiment in­té­res­sant et offre aux visiteurs une belle valeur ajoutée pour découvrir ou re­dé­cou­vrir l’at­ter­ris­sage sur la lune de la mission Apollo11, per­met­tant de revivre de manière numérique cet in­croyable évènement his­to­rique. Le site a été lancé en 2009 pour le 40ème an­ni­ver­saire de la mission et il est sans surprise basé sur Flash. Ainsi, si vous visitez la page Web via un na­vi­ga­teur mobile ou si vous n’avez pas installé le lecteur Flash, il ne sera pas possible de profiter du site Web puisqu’il n’est con­sul­table qu’avec une ins­tal­la­tion de Flash Player 10. Cela peut donc entraîner une exclusion de certains visiteurs et na­tu­rel­le­ment générer des frus­tra­tions.

Il est donc gran­de­ment conseillé d’utiliser le standard HTML5 pour intégrer des vidéos et des ani­ma­tions. Même l’éditeur Adobe reconnaît ses avantages et conseille aux dé­ve­lop­peurs de créer désormais du contenu avec le standard HTML5. C’est à cause notamment des vul­né­ra­bi­li­tés du format Flash qu’il est conseillé d’utiliser des al­ter­na­tives plus récentes. Ainsi les visiteurs peuvent accéder au contenu souhaité sans aucune ins­tal­la­tion sup­plé­men­taire et cela depuis tous les appareils. Pour plus d’in­for­ma­tions sur l’in­té­gra­tion de vidéos via HTML, vous pouvez consulter ce tutoriel dans notre guide digital.

Les re­di­rec­tions qui fonc­tion­nent uni­que­ment pour certains dis­po­si­tifs ou systèmes d’ex­ploi­ta­tion mobiles restent cependant pro­blé­ma­tiques : par con­sé­quent, il est né­ces­saire de vérifier si vos re­di­rec­tions fonc­tion­nent pour les prin­ci­paux systèmes (Android, iOS, Windows) et de régler la con­fi­gu­ra­tion de votre serveur. Vous pouvez aussi utiliser l’outil Google Search Console pour obtenir des in­for­ma­tions sur des re­di­rec­tions dé­fec­tueuses. 

Les bonnes re­di­rec­tions sont également im­por­tantes si vous découvrez que les in­ter­nautes ob­tien­nent un message d’erreur 404 en utilisant des appareils mobiles, comme des tablettes ou smart­phones. Les uti­li­sa­teurs de bureau ne sont eux pas con­fron­tés à ce problème. Evi­dem­ment, si une version mobile du site est dis­po­nible, l’in­ter­naute mobile doit toujours être redirigé vers cette version mobile. Bien sûr, la version mobile du site ne doit reporter les erreurs. Il est pré­fé­rable de rediriger un visiteur vers une page Web non adaptée que de ne montrer aucun contenu. Cette solution tem­po­raire est néanmoins associée à des li­mi­ta­tions im­por­tantes au niveau de l’ex­pé­rience uti­li­sa­teur.