Refonte du système de navigation à sept niveaux de SGS : une étude de cas

SGS (anciennement Société Générale de Surveillance ) est une organisation de services mondiale et un fournisseur de services d'inspection, de vérification, d'essais et de certification dans 14 secteurs. Le site Web de SGS (ainsi que 60 sites Web localisés) promeut principalement les services de base de l'organisation et donne accès à une multitude de services utiles, de contenu supplémentaire et d'outils. Notre objectif était de faire passer sgs.com d'un site uniquement pour ordinateur à un site réactif.

Cela présentait un ensemble unique de défis, en particulier autour du système de navigation hérité, qui dans les zones comptait jusqu'à sept niveaux de profondeur (divisé en deux parties) et qui se composait de quelque 12 000 éléments navigables individuels .

Lectures complémentaires sur SmashingMag : Lien

• Concevoir des études de cas : présenter un processus de conception centré sur l'humain
• S'adapter à une conception réactive
• Étude de cas d'unification de la conception de produits
• 75 études de cas instructives - Voici comment nous l'avons construit

Notre réaction naturelle en voyant et en utilisant le système de navigation de SGS pour la première fois a été que l'architecture de l'information (IA) devait certainement être simplifiée en raison du volume considérable de liens et de contenu navigables. Cependant, étant donné que la navigation avait déjà été optimisée pour les moteurs de recherche et l'IA avant ce projet et étant donné que SGS offre une large sélection de services dans de nombreux secteurs (ce qui se reflète dans le volume de contenu), il était évident que la refactorisation de l'IA ne serait pas faire partie de la solution.

En termes simples, la structure de l'arborescence de navigation devait rester intacte. Même ainsi, cela ne nous a pas empêché de faire quelques ajustements mineurs à l'IA. Par exemple, « News, Media & Resources » et « SGS Offices & Labs » ont été déplacés au niveau supérieur, pour une plus grande visibilité. Avec le premier, il était important de refléter plus clairement que SGS publie régulièrement des nouvelles et organise des événements. Avec ce dernier, il était essentiel qu'il soit facilement accessible, ainsi que la page de contact, de n'importe où dans la structure du site Web. Par conséquent, la question clé était de savoir comment un tel mastodonte d'un système de navigation pouvait être conçu pour passer facilement d'une fenêtre à l'autre tout en restant utilisable ?

Établir des politiques de projet

Une relation client-designer saine est essentielle à la réussite de chaque projet. Définir des attentes claires et fournir des conseils efficaces garantit non seulement que les principales parties prenantes restent concentrées tout au long, mais également que la confiance se développe entre toutes les parties au fur et à mesure que le projet progresse. Ce fut définitivement le cas avec ce projet; la collaboration entre toutes les parties et l'appréciation mutuelle des rôles et de l'expertise de chacun étaient vraiment remarquables.

Cependant, pour nous assurer que toutes les parties restent concentrées, nous avons établi lors de la réunion de lancement un certain nombre de lignes directrices et d'exigences importantes dans lesquelles nous pouvions également exercer notre créativité (sur lesquelles nous avons insisté pour certaines, d'autres sur lesquelles le client a insisté) :

• Parité de contenu . Le contenu doit être accessible sur tous les appareils et plates-formes et ne doit en aucun cas être masqué sur mobile.
• Performances . Le site Web doit être au moins 20 % plus rapide que les sites Web concurrents. Cela s'est avéré particulièrement utile pour décider de la quantité d'informations à mettre sur chaque page.
• Accessibilité . Le site Web doit respecter les directives d'accessibilité WCAG 2.0 niveau AA. Nous avons réussi à atteindre cet objectif, mis à part un problème de contraste de couleur limite, dû à l'image de marque de l'entreprise.
• Convivialité . L'équipe interne a dû valider en profondeur les concepts et effectuer des tests d'utilisabilité en personne et à distance.
• Commerce ininterrompu . La refonte ne devrait en aucun cas perturber les activités de l'entreprise. De toute évidence, la tâche n'était pas d'optimiser les services de l'entreprise, mais plutôt d'optimiser le site Web en tenant compte des processus d'affaires établis. Par exemple, nous avions la liberté d'optimiser les formulaires Web, mais la structure des données dans le CRM devait rester intacte.

Les trois grands défis

Une fois les directives clés établies et sachant que la refonte de la navigation ne nécessiterait pas une refonte importante de l'IA, nous avons subdivisé la refonte en trois ensembles d'activités clés mais interdépendantes :

• Placement de la mise en page . Cela a été géré principalement par l'équipe interne, nous suggérant des améliorations et veillant à ce que les décisions n'aient pas d'implications radicales sur d'autres aspects de la nouvelle conception réactive.
• Interaction et convivialité . Ceux-ci ont été travaillés en collaboration avec l'équipe de conception de SGS. Les idées ont été échangées par e-mail et lors d'ateliers sur site et ont été régulièrement validées par rapport aux utilisateurs, aux parties prenantes et aux exigences générales de l'entreprise.
• Performances . Cela a été traité uniquement par nous, car il s'agissait davantage d'un défi technique et ne nécessitait aucune prise de décision stratégique autre que pour nous de rendre le nouveau site Web réactif rapide.

Emplacement de la mise en page

La navigation est un élément fondamental de la mise en page, quelle que soit la taille ou la complexité du site Web. Bien qu'un modèle hors écran puisse sembler attrayant lorsque vous avez affaire à un système de navigation à si grande échelle, n'oubliez pas qu'il peut y avoir des problèmes lorsque la navigation n'est pas visible pour l'utilisateur.

L'équipe de conception de SGS avait initialement testé une variété de concepts, car ils devaient non seulement évaluer l'interaction de navigation, mais aussi créer le bon équilibre avec le reste de la page et éviter l'encombrement.

Décider du concept

Compte tenu de la complexité du site, il était primordial que la navigation reste toujours visible et informe l'utilisateur de sa position dans l'arborescence. Plutôt que de diviser la navigation en deux parties dans l'interface utilisateur, nous voulions que le nouveau système de navigation soit transparent (du niveau supérieur jusqu'aux niveaux inférieurs). Par conséquent, il devait permettre à l'utilisateur de naviguer facilement de haut en bas dans l'arborescence de navigation, ainsi que latéralement dans les sections principales.

Pour tester et valider l'ensemble de ces combinaisons, nous avons développé un prototype pour chacun des huit concepts de navigation initiaux. Les prototypes ont confirmé ce que l'équipe interne soupçonnait déjà : l'option la plus viable en termes de convivialité, de maintenance, d'expérience multi-écrans, d'encombrement visuel et d'attrait était que la navigation soit placée dans la barre latérale sur les grands écrans et apparaisse comme un menu déroulant sur les petits écrans. Essentiellement, le module de navigation serait fonctionnellement et visuellement autonome, quelle que soit la taille de l'écran.

Bien que nous nous concentrions sur des décisions d'interaction spécifiques dans une minute, il convient de souligner que les prototypes interactifs ne doivent pas nécessairement être abandonnés une fois qu'un concept de prototype a été testé et validé.

Prototypage intelligent

Nous développons toujours des prototypes directement en HTML, CSS et JavaScript en utilisant un balisage sémantique, accessible et robuste, car nous sommes alors souvent en mesure de réutiliser les prototypes initiaux plus tard dans le processus de conception. Cela signifie que notre prototype initial pour le nouveau système de navigation est devenu la pierre angulaire de l'éventuel prototype de site Web complet, qui comprenait tous les modèles et modules de page.

Lors de la livraison du prototype complet, nous nous sommes également assurés que le guide de style était généré automatiquement pour l'équipe SGS. En amenant l'équipe de conception de SGS à penser en termes de conception et de développement de modules, plutôt que de pages complètes, le guide de style généré nécessiterait peu de maintenance continue. Le guide de style lui-même fait référence à tous les modules distinctifs utilisés, chaque module contenant une description précise, un exemple de code et un lien généré automatiquement vers le modèle de page où il est utilisé. Notre technologie de choix pour automatiser les tâches et les fonctionnalités est PHP, mais l'automatisation peut être réalisée à l'aide de n'importe quel langage côté serveur, tant que la sortie est du HTML sémantique. (Nous avons développé un cadre de système de fichiers spécifique pour nos prototypes, mais c'est un sujet pour une autre occasion.) Plus loin dans cet article, nous expliquerons comment les scripts côté serveur nous ont aidés à maintenir et à tester plusieurs versions de la navigation.

Même s'il est essentiel de commencer par un HTML sémantique, accessible et robuste, le principe du "contenu d'abord, navigation en second" est tout aussi important car il vous aide à tenir compte d'éventuelles exceptions futures. Il y avait une exception à la règle "le contenu d'abord, la navigation en second" dans ce projet : la page d'accueil. Nous avons découvert, sur la base d'analyses, que la navigation était considérée comme l'élément le plus important de la page d'accueil, ce qui signifiait qu'elle devait précéder tout contenu principal de la page.

Interaction et convivialité

Une fois la décision prise de concevoir et de développer un module de navigation autonome et indépendant de la taille de l'écran, il était temps de se concentrer sur les interactions de navigation. Considérant que nous avions adopté une approche mobile pour la conception de la navigation, le module de navigation lui-même fonctionnerait non seulement naturellement comme prévu dans de petites fenêtres, mais s'adapterait également facilement pour fonctionner dans de grandes fenêtres.

Trois versions interactives

En raison de la taille de la navigation et du nombre potentiel de niveaux imbriqués, nous avons dû éliminer certains des modèles de navigation mobile les plus courants en tant qu'options - par exemple, sélectionnez les listes déroulantes et le modèle priorité +. Nous nous sommes concentrés sur le prototypage de trois versions interactives de la navigation : un curseur, un accordéon, et un accordéon et un curseur. Chacun a ses avantages et ses inconvénients, ce qui a naturellement influencé notre décision.

Accordéon

L'accordéon est probablement le motif le plus courant sur mobile. Il divulgue progressivement, révélant des informations plus détaillées au fur et à mesure que l'utilisateur progresse dans le sujet ou l'action. Cela garantit également que l'utilisateur ne soit pas submergé, c'est pourquoi nous voulions l'utiliser comme solution de base.

Voici les avantages de l'accordéon :

• Les utilisateurs le connaissent.
• Les utilisateurs peuvent développer l'intégralité de l'arborescence de navigation pour prévisualiser plusieurs options (sept niveaux de navigation peuvent être un peu écrasants, après tout).
• Il fonctionne sans JavaScript, en utilisant la pseudo-classe :target .
• Le développer est facile.

Et les inconvénients de l'accordéon :

• Les ancêtres étendus d'une catégorie de niveau profond éloigneraient trop la portée actuelle du haut de l'écran, nécessitant ainsi beaucoup de défilement.
• Sept niveaux de navigation nécessitent sept degrés du repère visuel choisi, qu'il s'agisse de sept nuances d'une couleur de base (gris), de sept niveaux de hiérarchie typographique ou de sept niveaux d'indentation.

Glissière

C'était initialement notre solution préférée, mais il manque un élément important : permettre une navigation vraiment latérale dans les sections principales. Ce ne serait pas un tel problème si l'utilisateur commençait toujours à naviguer à partir de la page d'accueil, car il se familiariserait de plus en plus avec les sections principales. Cependant, pour les utilisateurs qui atterrissent sur une page profonde dans l'arborescence de navigation, cela aurait certainement été un problème d'utilisabilité. Par exemple, les utilisateurs qui atterrissent au troisième, quatrième ou cinquième niveau devraient parcourir l'arborescence pour atteindre la page de contact. Traverser sept niveaux n'est pas amusant, peu importe la motivation de l'utilisateur.

Avantages du slider :

• La hiérarchie est claire.
• L'animation est fluide.
• Il suit les conventions mobiles.
• Il est relativement facile à développer.

Inconvénients du curseur :

• La navigation latérale n'est pas possible.
• L'animation n'est pas performante.

Hybride (accordéon et slider)

Nous voulions vraiment conserver l'attractivité du slider, tout en permettant une navigation latérale. Par conséquent, nous avons développé une solution hybride combinant les meilleurs éléments des deux modèles de navigation. Incidemment, c'était aussi la solution que nous avions choisie.

Avantages de l'hybride :

• La navigation latérale est possible.
• L'animation est fluide.
• La hiérarchie est claire.

Inconvénients hybrides :

• Cela demande un apprentissage initial.
• Il est complexe à développer, avec de nombreuses pièces mobiles à prendre en compte.
• Il a quelques problèmes de performances.

Comme mentionné, l'utilisateur doit pouvoir naviguer de haut en bas dans l'arborescence de navigation, toujours conscient d'où il vient et où la navigation le mènera ensuite. Cependant, ce n'est que l'interaction de base - nous avons dû résoudre un certain nombre de problèmes supplémentaires afin de développer un système de navigation utilisable.

Huit types distincts de liens

Outre le fait que les éléments de navigation actuels et ancêtres sont distincts dans leur conception (ce qui est maintenant, heureusement, une pratique bien établie), nous avons encore amélioré la navigation et la convivialité générale en aidant l'utilisateur à comprendre où il se trouve et ce qu'il explore. Aider l'utilisateur à comprendre la page actuelle et ses parents, ainsi que toute relation pertinente avec les enfants, était loin d'être suffisant. D'autres actions importantes étaient nécessaires :

• pouvoir accéder directement à la page parent ;
• pouvoir prévisualiser les niveaux parent et enfant, tout en restant à l'URL d'origine ;
• comprendre rapidement leur position de navigation actuelle, tout en étant capable d'explorer la navigation.
• comprendre rapidement leur position actuelle sur la page.

Remarque : nous avons utilisé des fils d'Ariane pour nous assurer que la position actuelle de la page est toujours claire pour l'utilisateur. Parce que nous voulions éviter complètement de sauter des niveaux, les informations dans le fil d'Ariane et la navigation devaient correspondre une à une, même avec des pseudo-niveaux (c'est-à-dire des niveaux qui n'ont pas de page réelle).

Les exigences de l'utilisateur ci-dessus ont abouti à cinq types d'éléments de navigation sémantiquement différents, avec des liens d'assistance supplémentaires qui permettraient à l'utilisateur de parcourir l'arborescence de haut en bas sans avoir à quitter la page en cours. Vous pouvez imaginer la complexité et les interdépendances qui accompagnent tant de pièces mobiles.

Détails des animations

Tous les éléments de la navigation sont animés à l'aide de CSS, chaque animation ayant deux parties distinctes :

• niveaux animés horizontalement,
• enveloppes animées verticalement.

Tout d'abord, les différents niveaux d'arborescence dans le curseur sont basculés en changeant la classe de l'encapsuleur maître. Par exemple, le wrapper de navigation fermé a une classe de .depth-0 . Lorsqu'un élément de niveau supérieur est développé, la classe devient .depth-1 . Lorsqu'un élément de second niveau à partir de cet élément de niveau supérieur est sélectionné, la classe devient .depth-2 , et ainsi de suite. Cela se traduit par un ensemble assez simple de règles CSS qui s'appliquent à un seul élément - la liste la plus ordonnée dans un curseur :

 .depth-1 .l-0.nav-open > ol { left: 0; } .depth-2 .l-0.nav-open > ol { left: -100%; } .depth-3 .l-0.nav-open > ol { left: -200%; }

Dans l'exemple ci-dessus, .l-0 correspond à un élément de liste de niveau zéro et .nav-open est basculé chaque fois que l'accordéon est défini sur open . Cela signifie que la liste ordonnée d'un enfant direct dans un élément de liste en accordéon open est absolument décalée vers la position négative à gauche.

Deuxièmement, étant donné que chaque niveau contient un nombre variable d'éléments de liste, la transition entre deux niveaux adjacents doit être fluide.

Pour ce faire, nous nous sommes assurés qu'il y a toujours suffisamment d'espace vertical pour que l'animation horizontale se déroule sans heurts. La hauteur est calculée et appliquée à la volée en récupérant le déport vertical de l'élément sur le point d'entrer dans l'écran. Cela signifie que nous devions tenir compte d'un total de quatre scénarios possibles, mais n'avions vraiment besoin d'en résoudre que deux, chacun avec un ordre d'exécution légèrement différent :

• Élément de la liste courte à un élément de la liste plus longue . L'animation horizontale et verticale démarre en même temps.
• Élément de liste longue vers un élément de liste plus court . Une fois que la navigation cesse de glisser horizontalement, l'animation verticale démarre.

Les deux animations sont lancées en même temps, mais la seconde animation est lancée après un délai de 300 millisecondes, ce qui correspond exactement à la durée de la première animation (spécifiée en CSS à l'aide de la propriété transition-duration ). La raison en est des performances d'animation sous-optimales sur des appareils moins performants lorsque plusieurs couches se chevauchent avant de disparaître "derrière le rideau". Le code simplifié ressemble à ceci :

 if (newHeight < oldHeight) { heightTimeout = 300; } else { heightTimeout = 0; } setTimeout(function() { $('.l-0.nav-open').css('height', newHeight); }, heightTimeout);

Autres améliorations

Déjà confrontés à un ensemble complexe d'interdépendances, nous avons réalisé en testant la navigation qu'il y avait place à amélioration.

Premièrement, étant donné que les polices Web se chargent parfois un peu plus tard que le reste de la page, certaines chaînes de texte de la navigation censées figurer sur une ligne se développeraient sur une deuxième ligne avant le chargement complet de la police Web. Par exemple, le lien de la section de niveau supérieur "Actualités, médias et ressources" tombe sur deux lignes lorsqu'il est rendu dans la police de secours.

Parce que tout devait être vraiment compact (puisque nous devions utiliser le positionnement absolu pour l'animation de glissement), la seule solution était de réinitialiser la hauteur de l'élément affecté après le chargement de la police Web. Cela a été fait à l'aide de Web Font Loader, développé par Bram Stein pour Adobe Typekit et Google Fonts.

 WebFont.load({ custom: { families: ['FONT_NAME_1', 'FONT_NAME_2'] }, active: function() { // recalculate things here }, timeout: 5000 });

Remarque : Avez-vous remarqué que nous avons utilisé un délai d'attente de 5 secondes ? Lors de nos tests, nous avons trouvé que c'était le point idéal qui le faisait fonctionner sur notre connexion de base "bonne 2G" (450 Ko par seconde) !

Deuxièmement, parce que nous avons décidé de charger conditionnellement les nœuds de navigation afin d'améliorer les performances de chargement initiales (plus à ce sujet dans la section suivante), nous voulions que l'utilisateur soit tenu au courant du nombre d'éléments de navigation disponibles, en cas de retard. au chargement d'une branche de l'arbre de navigation. Pour ce faire, nous avons répété une image d'arrière-plan d'espace réservé qui ressemble à une chaîne de texte.

Enfin, nous avons ajouté le code d'espace réservé dans le DOM avec JavaScript avant de demander la branche de navigation. Cela permet de garder le DOM aussi propre que possible.

 element.append('<ol class="nav-loading"><li class="nav-placeholder"></li></ol>'); $.get('NAVIGATION_BRANCH_URL', function(data){ // replace the loader with the branch element.find('ol').replaceWith(data); });

Performance

Si vous vous souvenez, l'un de nos principaux objectifs dans le projet était que le site Web fonctionne au moins 20 % mieux que les sites Web des concurrents. Non seulement nous avons atteint cet objectif, mais ce faisant, nous avons aidé SGS à réduire considérablement le poids global des pages et les temps de chargement. Jetez un œil aux statistiques avant et après suivantes :

Saviez-vous que 12 000 liens équivalent à 3 Mo de HTML ?

C'est correct! Lorsque nous avons rendu l'arbre de navigation complet pour la première fois dans notre prototype, il s'élevait à 3 Mo de HTML nu. Pas d'en-tête, pas de pied de page et pas de contenu - juste l'arborescence de navigation composée de 12 000 liens individuels.

Avant la refonte, chaque page contenait l'arborescence de navigation principale, et chaque page de l'industrie comprenait également une arborescence de navigation spécifique à l'industrie, implémentée en tant que module séparé. Cependant, la conception optimisée pour le bureau a rendu la navigation de base ou spécifique à l'industrie non seulement difficile à utiliser sur de petites fenêtres, mais également difficile à maintenir. C'est pourquoi l'un des principaux objectifs de la refonte était de consolider l'arborescence en un module unique et facile à entretenir.

Explorer les options pour améliorer les performances

Pour tester minutieusement chacune des trois versions interactives de la navigation, ainsi que pour évaluer leurs performances, un environnement de test flexible était essentiel. Cela nous permettrait d'apporter des modifications rapidement, ainsi que de maintenir des versions concurrentes afin que nous puissions facilement les comparer les unes aux autres.

Compte tenu de la taille de l'arborescence de navigation complète (jusqu'à sept niveaux de profondeur et 12 000 liens navigables), il était important de pouvoir tester des parties de l'arborescence de navigation ainsi que l'arborescence complète elle-même. Les développeurs internes de SGS ont pu exporter l'arborescence de navigation complète sous forme de fichier CSV à partir de leur système de gestion de contenu, ce qui nous a permis de créer une fonction PHP facilement configurable pour générer l'arborescence complète ou une partie de celle-ci, selon ce dont nous avions besoin. tester.

Notre fonction PHP a également simplifié la maintenance HTML de la structure de l'arborescence de navigation, car le balisage des liens et les noms de classe susmentionnés pouvaient être facilement modifiés en un seul endroit. Utiliser un langage côté serveur pour éviter d'avoir à répéter du code peut sembler évident, mais la création de ce type d'environnement n'était pas seulement un ajout bienvenu, mais était en fait essentielle à la mission, car c'était la condition préalable à l'expérimentation et aux tests agiles.

Chargement conditionnel des liens

Nous avons mentionné que nous devions charger conditionnellement les nœuds de navigation pour améliorer les performances de chargement initiales. La question à laquelle il fallait alors répondre était la suivante : quelle quantité de l'arborescence de navigation doit être chargée initialement et quelle quantité doit être chargée plus tard, et quand ? Après avoir testé et comparé les poids et les tailles des différentes branches de l'arborescence de navigation, ainsi que l'étude du comportement des utilisateurs sur le site Web en direct existant, quelques conclusions intéressantes ont émergé.

Premièrement, les visiteurs qui s'intéressaient à un seul type d'industrie visitaient rarement d'autres industries. Une fois qu'il a parcouru sa catégorie d'industrie sélectionnée, chaque visiteur n'explore généralement que quelques autres pages.

Deuxièmement (et comme nous l'avions initialement pensé), les branches spécifiques à l'industrie ont causé la majorité des frais généraux de performance. Lorsque nous avons complètement supprimé les branches de l'industrie, le HTML a été réduit à 70 Ko, ce qui est bien mieux que 3 Mo ! Pourtant, cela signifiait que chacune des 14 branches de l'industrie pesait entre 300 et 500 Ko. Lorsque nous avons fragmenté davantage chaque branche de service, nous avons constaté que chaque niveau suivant pèserait environ 24 Ko en moyenne.

Alors que nous étions conscients que le HTML pouvait être encore réduit en optimisant les noms de classe et en ajoutant des nœuds DOM via JavaScript (plus à ce sujet dans une minute), nous devions encore déterminer s'il était préférable de lancer une seule requête HTTP à environ 300 pour 500 Ko ou pour initier une requête HTTP d'environ 24 Ko à chaque niveau. Initialement, il semblait que l'envoi d'une requête de 24 Ko à chaque fois que l'utilisateur progressait plus bas dans l'arborescence de navigation serait plus bénéfique. Cependant, cela aurait entraîné l'envoi de plusieurs requêtes HTTP sur le réseau, ce qui était loin d'être idéal, étant donné que la latence du réseau est souvent l'un des plus gros goulots d'étranglement pour les performances du site Web. Cela n'avait pas non plus de sens de prédire le chargement des branches de l'industrie, sauf lorsque l'utilisateur a montré son intention en survolant un lien de l'industrie.

En raison de la complexité de la navigation et de la quantité de liens, la disposition suivante offrait de loin le meilleur compromis :

• Chargez les trois premiers niveaux par défaut en HTML.
• Chargez la navigation de l'industrie avec JavaScript lorsque l'intention est affichée, détectée à l'aide de l'événement mouseover .
• Branches chargées en cache pour accélérer le chargement lors de chargements de pages consécutifs.

La logique des pages plus profondes était quelque peu différente, car la navigation doit être accessible sans JavaScript activé. Par conséquent, si un utilisateur (ou même un robot de moteur de recherche) atterrit sur une page profonde, ce qui suit se produirait :

1. Rendre les trois premiers niveaux et la branche ancêtre de la page actuelle et les frères de page en HTML, permettant ainsi à l'utilisateur d'accéder facilement aux pages parent, ancêtre et frère, tout en pouvant également accéder à d'autres parties du site Web suivant la même logique.
2. Chargez la branche actuelle avec JavaScript et remplacez la branche ancêtre de la page actuelle initialement chargée.

Optimisation HTML

Si vous voulez vraiment optimiser votre HTML, tous les éléments non essentiels doivent être déchargés vers CSS et JavaScript. Nous avons rigoureusement tout élagué sauf la liste ordonnée, ses éléments de liste et leurs liens respectifs. Tous les liens non essentiels (c'est-à-dire les aides à la navigation) ont également été supprimés du HTML et sont réinsérés dans le DOM à l'aide de JavaScript (car ils sont de toute façon inefficaces sans JavaScript). Ces liens non essentiels permettent à l'utilisateur de faire plusieurs choses :

• ouvrir le niveau suivant (en interne, nous avons appelé ces "expandeurs");
• monter d'un niveau (nous avons nommé ces "soutiens" — preuve d'un manque d'imagination).

Alors que le DOM résultant était encore immense, les aides à la navigation n'avaient plus besoin d'être transférées individuellement sur le réseau.

Enfin, la dernière pièce d'optimisation que nous avons entreprise était de réduire le nombre de classes, ainsi que de raccourcir la longueur des noms de classe ; par exemple, .very-long-class-name est devenu .vlcn . Bien que ce dernier ait généré les gains les plus importants, une telle optimisation est difficile à justifier car elle ne réduit généralement pas de manière significative la taille du fichier HTML et, plus important encore, elle réduit la clarté du code, rendant ainsi la maintenance plus difficile. Cependant, supprimer ne serait-ce qu'un seul octet de chacun des 12 000 éléments de la liste en faisait un exercice valable et un compromis acceptable.

Le résultat? Environ 40 Ko de HTML initial (8 à 9 Ko lorsqu'il est compressé et transféré sur le réseau) et 200 à 300 Ko de HTML pour chaque industrie (15 à 25 Ko lorsqu'il est compressé et transféré).

Conclusion : les gains marginaux comptent

Nous aimons utiliser une analogie avec le monde du sport : améliorer chaque petite chose de 1 % améliore considérablement les performances. Cela s'applique à ce que nous avons fait dans le projet SGS et à sa navigation complexe. En nous concentrant sur les détails les plus fins, en améliorant chaque détail d'un tout petit peu, nous avons considérablement réduit la complexité de la navigation et amélioré les temps de chargement, tout en gardant la navigation attrayante et engageante pour les utilisateurs. Ce qui aurait pu être un cauchemar et un dur à cuire s'est transformé en une solution techniquement et interactivement pertinente, suffisamment flexible pour s'adapter à d'autres améliorations.

Surtout, le processus de conception consistant à créer continuellement des prototypes, à rechercher des options et à affiner les meilleures solutions s'est avéré extrêmement efficace - à tel point qu'il a fourni de solides arguments à l'équipe interne pour qu'elle applique les mêmes principes fondamentaux lors du développement d'autres produits. dans l'organisation, sans compter que cela aidera l'équipe à continuer à peaufiner et à optimiser le nouveau système de navigation. Aucun projet Web n'est jamais vraiment complet. il y a toujours quelques choses de plus sur la liste de choses à faire. C'est parfaitement bien, tant que nous continuons à tester, à affiner et à offrir la meilleure expérience aux utilisateurs.