Centre des communautés
Centre des communautés

À mesure que le web (et les services et sites qui le soutiennent) se développe et change, les parties techniques de sites comme Fandom doivent s'adapter aux habitudes de nos utilisateurs et rester modernes. Pour les services d'information comme les wikis, il existe une infinité de sources où les fans peuvent trouver des réponses sur presque tous les sujets.

Alors que nous aimerions imaginer que les fans se rendent directement sur l'une ou l'autre des communautés Fandom en tapant une adresse web bien précise, la réalité est que plus de 80 % des internautes qui visitent le site de Fandom le font par le biais des résultats des moteurs de recherche[1]. Dans la plupart des pays du monde, Google fournit une plateforme presque exclusive pour toutes les recherches[2]. En outre : la plupart des recherches menant aux wikis de Fandom ne sont pas « X Wiki », mais sont plus souvent des recherches de titres de pages et de sujets spécifiques. Cela représente un changement dans les habitudes des utilisateurs qui ont évolué avec le web et l'impact puissant des moteurs de recherche.

Google modifie fréquemment les algorithmes qui alimentent son service de recherche et signale parfois à l'ensemble du web ses projets. Trois de ces changements[3][4][5] qu'ils ont annoncés devraient avoir un impact significatif sur Fandom en particulier, en raison de la nature même du développement et de l'édition des wikis. Ces changements, s'ils ne sont pas pris en compte, réduiront la visibilité à la fois des wikis en eux-mêmes et de la plateforme Fandom dans son ensemble. C'est pourquoi ce guide abordera la manière dont les wikis sont perçus d'un point de vue technique (et humain) et ce que les communautés peuvent faire pour apporter les ajustements nécessaires.

Mesures[]

De nombreux facteurs définissent la performance d'un wiki et chaque étape du processus a des mesures différentes.

Performance de MediaWiki[]

Avant qu'une page wikitexte ne soit mise en ligne, elle doit être convertie en HTML. Le processus d'analyse et de « rendering » (processus de restitution) a lieu dans le logiciel du serveur MediaWiki, où il est traduit couche par couche dans le langage de base des pages web. La vitesse à laquelle celles-ci sont traitées et servies est généralement inférieure à deux secondes, et peut être plus rapide la deuxième fois que la même page inchangée est servie via un processus appelé « mise en cache ».

La performance des pages MediaWiki est mesurée en temps & en ressources mémoire nécessaires pour afficher la page et aussi la complexité du HTML résultant est (du fait que les navigateurs doivent interpréter le code HTML de manière à ce qu'il soit visuellement compréhensible pour pour un humain). Les pages qui affichent des informations issues d'autres éléments du serveur (un processus appelé « transclusion ») prennent plus de temps et consomment plus de ressources. L'utilisation de modèles est une forme de transclusion, de sorte que la complexité et la profondeur de l'imbrication des modèles affectent les performances. Selon la manière dont ils sont écrits, cela peut également s'appliquer aux extensions qui déplacent le contenu d'une page à l'autre (comme DynamicPageList).

Organigramme montrant le processus de rendu de MediaWiki

Core Web Vitals[]

Récemment, Google s'est intéressé à trois indicateurs de performance clés qui ont un impact sur le classement. Dans l'ensemble, ces Core Web Vitals sont :

  • Largest Contentful Paint (Plus grande zone de contenu), ou LCP, qui mesure la performance de chargement, ou la vitesse à laquelle la plus grande zone de contenu de la page est visible pour le lecteur.
  • First Input Delay (Délai de première saisie), ou FID, qui mesure l'interactivité, ou la vitesse à laquelle les liens ou les éléments de formulaire sont accessibles pour la saisie ou pour cliquer dessus.
  • Cumulative Layout Shift (Décalage cumulatif de la mise en page), ou CLS, qui mesure la stabilité visuelle, c'est-à-dire la quantité de mouvements effectués par les premiers éléments visibles à l'écran avant de pouvoir interagir avec eux.

Une grande partie de ce qui est mesuré par les Core Web Vitals dépend de la distribution des pages de wiki par Fandom, bien qu'il y ait des actions de contributeurs et des communautés qui peuvent être prises pour améliorer les « vitals » d'un wiki. Bien qu'il soit important de les relever pour les pages de bureau, la plupart des préoccupations de Google à cet égard se concentrent sur les affichages mobiles (déconnectés ou anonymes). Ainsi, Google prend en compte les wikis individuellement lors de la prise en compte du classement, mais Google considère également l'ensemble de Fandom comme un seul bloc dans certaines situations. Les Core Web Vitals ont un effet plus important sur la plateforme dans son ensemble (et peuvent donc mettre en avant des wikis plus petits qui ne sont pas aussi fréquemment recherchés), mais il est toujours important que chaque wiki en soit conscient et puisse éventuellement apporter des modifications.

Contenu compréhensible[]

Plus que de simples mesures, le fait que les pages de votre wiki soient bien exposées et faciles à découvrir est un facteur important de performance.

Blind men and elephant4.jpg

Des parties importantes de l'algorithme de Google concernent le « Passage Ranking » et l'« indexation totale des pages ». Google touche toutes les pages qu'il peut trouver via des liens dans les pages et des cartes subtiles et en fait des copies dans sa base de données, qu'il traite ensuite pour trouver des informations. Ces informations comprennent les phrases lues par Google (à partir de l'index qu'il a créé) et la « compréhension » de leur contexte — par exemple, si une page dit (dans une phrase complète) que « X est la mère de Y » et qu'une autre page dit que « Z est le père de X », Google a effectivement un modèle dans son « esprit » que « Z est le grand-père de Y » sans que cela soit explicitement écrit. Ce processus de sémantique aide Google à répondre aux questions des utilisateurs qui cherchent des informations. Alors que l'exploration archaïque des moteurs de recherche dépendait des mots clés d'une page, le classement des passages consiste à utiliser le langage naturel et les données exposées (comme les tableaux et les infoboxes) pour élaborer des modèles afin que Google sache où envoyer les chercheurs. Dans un sens, cela ressemble beaucoup à la vieille parabole de « Les aveugles et l'éléphant »[6], où des éléments d'information disparates sont utilisés pour élaborer une image complète. C'est pourquoi le fait d'avoir plus de contexte et de narration (même si cela produit des pages plus longues) aide à construire un concept complet que Google peut référencer. Ce n'est pas une coïncidence si cette méthode est également meilleure pour les humains qui comprennent les sujets des wikis, car de nombreuses méthodes de Google sont conçues pour imiter la façon dont les humains pensent — si Google comprend ce que dit une page, il prédit que cette page sera la meilleure ressource pour les humains pour comprendre cette page (et d'autres sur le même wiki) et classera ces pages à un rang supérieur.

Ces pages complètes peuvent être mesurées par leur degré de remplissage. Il est plus utile d'avoir des pages éparses avec un contenu de référence minimal pour les sites web axés sur les bases de données que pour les wikis Fandom, où les internautes sont plus intéressés par la voix et la sagesse de la communauté que par de simples faits. L'expertise d'une communauté de quand il faut séparer les sujets distincts des articles plus longs ou quand il faut fusionner de petits articles connexes est une mesure importante qui n'est pas facilement quantifiable.

Expérience utilisateur[]

Les lecteurs ne resteront pas s'ils sont chassés. Des pages trop denses en informations ou difficiles à exploiter pousseront les internautes à chercher ailleurs tout aussi sûrement qu'ils le feraient si les pages étaient mal écrites ou de mauvaise qualité.

Google mesure systématiquement l'expérience de l'utilisateur, et ce de plusieurs façons. De manière objective, Google peut suivre le temps passé sur une page et, grâce à l'analyse, peut construire un modèle de la manière dont les utilisateurs perçoivent le contenu de la page. Google utilise également Évaluateurs de la Qualité pour humain pour vérifier l'efficacité de l'algorithme à envoyer les internautes au bon endroit. Ces évaluateurs émettent des avis professionnels sur l'utilité et l'utilisation d'une ressource, ce qui peut avoir un effet indirect sur le classement lorsque l'algorithme de Google est ajusté sur la base de leurs rapports.

Mais la mesure la plus efficace de l'expérience utilisateur commence par la facilité ou la difficulté d'utilisation d'une page web, en particulier si le contenu est facile à comprendre et la facilité d'interaction sur les appareils mobiles. Tous les styles et gadgets fantaisistes ajoutés à une page ne peuvent pas surmonter le contenu mal organisé ou mal écrit ; de telles fioritures peuvent en fait rendre l'expérience de l'utilisateur bien pire s'il cherche des connaissances spécifiques et ne peut pas naviguer à travers les choses frivole ou les panneaux cachés d'une page pour les trouver.

Ajustements pratiques[]

Il existe des moyens pratiques pour améliorer les performances d'un wiki en tant que contributeur. Nombre d'entre elles sont des habitudes à reconsidérer, en partie parce que la nature du web a changé depuis l'apparition des premiers wikis. Chacun de ces moyens a individuellement de petits effets, mais collectivement, ils permettent de mieux positionner un wiki pour en améliorer les performances.

Contenu de page original et ébauches[]

Bien qu'il existe des outils MediaWiki pour automatiser et interpréter les aspects techniques des pages, comme la longueur et les liens, ces outils n'identifient pas les contenus en ébauches ou peu développés. Les « ébauches » sont un terme traditionnel du wiki pour les pages qui sont marquées manuellement comme étant incomplètes et nécessitant l'ajout d'informations supplémentaires. Le contenu peu développé est celui qui ne répond pas aux questions d'un internaute à la recherche d'informations. Par conséquent, la plupart des ébauches sont également considérées comme des contenus peu développés, même si toutes les pages courtes ne sont pas des ébauches. Les wikis de Fandom ne sont pas pénalisés actuellement pour l'abondance de contenus peu développés, bien qu'il y ait des preuves que l'algorithme de Google fait des suppositions sur un wiki (ou tout Fandom) lorsqu'il rencontre des modèles de contenus peu développés et peut agir en conséquence à l'avenir.

Les pages courtes souffrent de problèmes vitaux, mais les ébauches ont en plus des problèmes de compréhension et d'expérience utilisateur. Par exemple, les pages courtes ont de petites zones de contenu ; parfois celles-ci sont suffisamment petites pour que les en-têtes et les barres d'outils deviennent les plus grandes zones de la page. Par conséquent, les petites zones de contenu sont relativement déplacées par des éléments comme les barres d'outils et ont des scores CLS élevés (et donc mauvais). En raison de leur nature interactive, les en-têtes et les barres d'outils sont plus lents à charger que le contenu ; s'il s'agit du plus grand contenu de la page (par la taille du HTML, et non par l'aspect visuel) et qu'il prend le plus de temps à charger, les scores LCP et FID seront inférieurs à l'idéal.

Les ébauches, parce qu'elles ne répondent pas à des enquêtes plus approfondies en raison de leur nature peu développée, ont tendance à être mal classées par Google. Le fait d'avoir un ratio important d'ébauches par rapport aux articles complets diminuera la confiance générale de Google dans la capacité d'un wiki à répondre aux questions sur le sujet et peut donc faire baisser le classement des pages du même wiki (même si ces pages ne sont pas des ébauches). Par conséquent, il est préférable d'éliminer les ébauches le plus rapidement possible (avant 30 jours, date à laquelle on peut s'attendre à ce que Google ré-indexe périodiquement un wiki) en supprimant la page, en la remplissant de manière exhaustive ou en la fusionnant avec une page connexe. Il peut être utile de se rappeler que les humains pensent généralement de la même manière et préfèrent voir les petites informations comme faisant partie d'un « article plus vaste » plutôt que d'être incomplètes et isolées. Le fait d'avoir des sections de page vides, en particulier des sections d'introduction vides (également connues sous le nom de « ledes »), ont un effet négatif à la fois sur l'analyseur de Google et sur l'expérience de l'utilisateur, car un tel vide représente une impasse plutôt qu'une opportunité.

Les liens rouges (ou liens vers des emplacements inexistants où les pages devraient se trouver) sont utilisés pour être considérés comme des opportunités pour les contributeurs et les futurs contributeurs de créer de nouvelles pages de contenu. Bien que l'on s'interroge sur l'efficacité des liens rouges pour attirer les contributeurs, les liens rouges nuisent à la vitalité du web et à l'exploration des recherches ; c'est pourquoi les liens rouges sont affichés en texte clair sur les sites mobiles déconnectés. Les liens rouges conduisent les robots des moteurs de recherche vers des zones inexistantes, les comptant effectivement comme des erreurs lorsqu'une page est introuvable. Le nombre total d'erreurs rencontrées sur un site web, wiki ou non, diminue sa crédibilité et sa perceptible fiabilité. Réduire rapidement le nombre total de liens rouges contribuera à améliorer les performances et le classement des pages.

Les pages de catégorie ne sont souvent envisagés qu'après coup au niveau des wikis. Ils sont aussi bien classés que les pages d'articles si le modèle de Google suggère qu'ils le devraient, en raison des informations déduites. Lorsqu'elles n'ont pas de ledes ou de contexte, elles apparaissent sur les pages de résultats de Google sous forme de texte déformé. Chaque catégorie devrait avoir au moins un peu de texte dans la zone de contenu de la page.

Pages robustes et ergonomie sur mobile[]

Une division du contenu assez mal comprise est celle qui consiste à diviser les articles en plusieurs onglets (via des liens en haut de page ou des onglets interactifs). Lorsque ces liens renvoient à d'autres pages — un processus que Fandom appelle la navigation par onglets — ils créent ou impliquent des concepts incomplets. La diffusion des informations nécessaires pour comprendre ce qui est généralement un concept d'article unique (personnage, épisode, arme, etc. ; autrement dit, une entité de contenu) décomposé en plusieurs pages rend plus difficile pour Google de créer un modèle de ce concept. De la même manière, les lecteurs humains sont moins susceptibles de vouloir visiter et lire plusieurs pages pour comprendre les différentes facettes d'un même article. Cet effet est parfois appelé « notre princesse se trouve dans un autre château », parce que l'internaute doit voyager à travers différents liens pour trouver ce qu'il cherche, en suivant le parfum des informations dans une course-poursuite vers ce qu'il veut vraiment savoir.

Avoir un « article complet » où l'internaute s'attend à trouver l'information et avoir une explication plus approfondie ou plus longue d'un seul aspect sur une page séparée n'est pas une mauvaise chose. Une page de « vue d'ensemble » (généralement appelée « page de base » en raison de son titre sans sous-pages) doit contenir au moins l'essentiel nécessaire pour comprendre le concept abordé dans l'article. Les liens dans le corps du texte (peut-être en utilisant les modèles {{Article détaillé}} ou {{Voir aussi}} sous les en-têtes de section) peuvent conduire l'internaute à l'information plus approfondie et plus détaillée qu'il souhaitait, surtout lorsqu'elle est associée à un résumé et à une explication du contexte. Par exemple, sur une page comportant les liens « Biographie » et « Histoire » en haut de page, comment l'internaute pourrait-il savoir quelles informations se trouvent sur chaque page ? De cette façon, tous les articles concernés peuvent et doivent être des pensées complètes en soi et non des fragments à rassembler.

Il convient également de noter que si ces onglets de page sont créés avec des modèles ou du JavaScript pour une mise en page axée sur le bureau, ils ne fonctionneront pas ou n'apparaîtront pas correctement sur les appareils mobiles. De tels liens n'auront également aucune pertinence pour Google en tant qu'aides sémantiques (le contexte n'est pas compris et ils ressemblent simplement à des liens orphelins à la dérive en haut du texte de l'article). Plutôt que d'ajouter quelque chose qui n'a pas l'air de fonctionner correctement ou qui n'apparaît pas du tout pour la plupart des utilisateurs, le fait de placer les liens de navigation dans un segment <navigation> d'une infobox produira un pont que les utilisateurs mobiles et les moteurs de recherche pourront facilement comprendre.

Dans ce modèle, il y a peu de distinction entre des « liens en forme d'onglet » en haut d'une page et des liens ou indicateurs en forme d'icônes (communément appelés EraIcons) ailleurs sur la page (y compris l'en-tête). Les deux formes sont difficiles à voir ou à utiliser sur les appareils mobiles, et le passage suggéré à la navigation par infobox s'applique aux deux.

Aucun élément de bloc (comme dans : aucun texte) n'est aussi important qu'une infobox pour un article. Dans un sens, avec une section d'introduction (ou « lede »), les infoboxes fournissent un contexte et des points de données sur le sujet d'un article. En tant que telles, elles font l'objet d'un traitement spécial sur l'habillage mobile et envoient des signaux forts à Google. Leur position privilégiée en fait des éléments idéals pour la navigation et l'interconnexion avec d'autres pages fortement liées.

Un problème avec les sections et les pages qui contiennent des images, des tableaux et des galeries est qu'il n'y a souvent pas d'« ancre » narrative pour remettre l'élément dans son contexte. Ceci est fait à la fois à des fins sémantiques (pour que Google comprenne quelle est la relation entre le modèle qu'il crée pour la page et l'élément ou le tableau indiqué) et à des fins d'accessibilité (pour que les lecteurs d'écran et autres appareils d'aide puissent présenter un indice si l'information est pertinente ou non avant que le tableau ou l'élément ne soit interprété). Idéalement, toutes les images devraient être accompagnées de légendes (texte qui met l'image en perspective pour l'article ; par exemple « Batman, vers 2020 ») et/ou d'un texte alternatif (qui décrit littéralement l'image pour ceux qui ne peuvent pas la voir ; par exemple « Un personnage costumé niché sur un toit en pleine nuit »). Autrement dit, le texte alternatif explique ce qu'est une chose, une légende aide à expliquer pourquoi elle est là. Pour les grandes galeries d'images qui peuvent être regroupées logiquement, il est préférable, tant pour le rendu que pour la compréhension humaine, de les diviser en galeries plus petites. L'idéal est d'intercaler ces images avec le texte narratif de sorte que le texte et l'image se complètent ; de telles mises en page fonctionnent bien sur tous les appareils.

Raccourcir les pages[]

Il n'y a rien de mal en soi à avoir de longues pages (du point de vue d'un moteur de recherche). Comme indiqué ci-dessus, elles sont plus susceptibles d'être interprétées comme des modèles de contenu complets avec le classement des passages de Google, car la page entière est analysée. Si le contenu est bien organisé, l'attention du lecteur devrait avoir de quoi l'informer et le divertir sans que des points précis soient difficiles à trouver.

Toutefois, il convient de noter que le placement de blocs de contenu dans des blocs d'onglets interactifs (souvent appelés « tabbers ») présente des obstacles techniques. L'édition de blocs de wikitexte qui se trouvent à l'intérieur d'un code complexe (paragraphes à l'intérieur d'une fonction d'analyse) est plus difficile à faire avec l'interface de l'Éditeur Visuel utilisée par la plupart des contributeurs, et rend également l'édition avec l'interface de modification du wikitexte plus difficile à identifier où les éléments commencent et finissent. La couche de JavaScript interactif augmente le score du « vital » FID en raison de la nécessité de restituer les éléments ; si le tabber se trouve dans la zone initialement visible de la page lors de son premier chargement, il augmentera également le score du « vital » CLS en raison de ce qu'il déplace. Les actions des onglets elles-mêmes qui révèlent le contenu peuvent ne pas fonctionner correctement du tout sur les appareils mobiles. Des rapports mitigés provenant du web indiquent que le contenu caché dans un onglet secondaire peut ne pas être considéré comme important par Google.

Le plus important, cependant, est peut-être l'expérience utilisateur : le contenu derrière les onglets secondaires est un peu comme « loin des yeux, loin du cœur » et n'est pas aussi susceptible d'être vu par les lecteurs. Les onglets situés au-delà du premier sont moins souvent consultés, et chaque onglet supplémentaire a moins de chances d'être activé. La plupart du temps, les lecteurs ne savent même pas qu'il y a des informations qui ne sont pas immédiatement visibles pour eux, et ils négligeront ce qu'ils recherchent ou apprécient parce qu'il est hors de portée de vue.

Pour ces raisons, l'utilisation d'onglets pour « raccourcir » les pages est loin d'être idéale pour la performance et l'expérience dans la plupart des cas. Si des tabbers doivent être utilisés, les recommandations d'utilisation des principaux experts en matière d'expérience utilisateur suggèrent qu'ils doivent :

  • ne pas s'imbriquer les uns dans les autres
  • ont des libellés d'onglet uniquement sur une ligne visuelle
  • utiliser des libellés descriptifs

L'inclusion des DataTables dans cet organigramme met en évidence une caractéristique que nous aimerions souligner. Bientôt disponible dans nos scripts du Dev Wiki, les DataTables ajoute de nombreuses nouvelles fonctionnalités pour améliorer la longue expérience des tableaux de données. Il convient également de noter que l'utilisation de plusieurs infoboxes dans une page est déconseillée (pour des raisons de temps de traitement et d'analyse par les moteurs de recherche) et qu'il est souvent plus utile de consolider plusieurs infoboxes (en particulier celles qui partagent de nombreuses propriétés communes) en une seule infobox en utilisant la fonction panneaux.

Pages d'accueil et navigation[]

Les pages d'accueil sont spéciales sur les wikis pour diverses raisons. Pour les machines et les humains qui n'entrent que l'URL simple d'un wiki (par opposition à une page spécifique), elles représentent le principal point d'entrée à partir duquel le lien se propage. Google interprète les liens sur la page d'accueil (et la barre de navigation locale) comme des endroits importants pour comprendre le sujet du wiki. Lorsque Google examine le wiki pour la première fois, sans rien connaître d'autre sur le sujet, il suppose que tous les liens ont le même poids et la même importance. Cela est simple s'il y a 10 à 20 liens vers des pages ou des catégories. Lorsque des widgets ou des panneaux ajoutent des centaines de liens à la page d'accueil, le poids relatif de ces liens approche de zéro. Comme ce document y a fait allusion à de nombreuses reprises, c'est également la façon dont les humains ont tendance à penser : avoir trop de choix entraîne « la paralysie du choix » ; l'effet est qu'ils ne savent pas par où commencer pour chercher la véritable signification.

C'est pourquoi, pour des raisons techniques et d'expérience utilisateur, nous suggérons fortement de limiter les liens sur une page d'accueil aux articles et catégories les plus importants nécessaires à la compréhension du sujet du wiki. Nous suggérons également de ne pas utiliser de widgets interactifs qui permettent d'explorer les listes de pages du wiki car ils ont un impact sur le rendu, les éléments vitaux et les performances d'exploration. En supposant qu'elles soient liées à une autre page, le crawler finira par les atteindre. Il convient également de noter que Google a pour instruction, dans la plupart des cas, de ne pas explorer les pages spéciales ou les pages de discussion, où elles peuvent initialement recevoir un message d'erreur ou être redirigées. Nous vous conseillons de ne pas créer de liens vers ces pages à partir de la page principale (et dans de nombreux cas, ces pages sont liées à partir de la navigation locale ou les pages Spécial:Community qui ne sont pas immédiatement visibles par Google).

Il existe de nombreuses possibilités d'inclure de la vidéo dans un wiki, mais nous suggérons un maximum de deux ou trois widgets vidéo intégrés. L'impact sur les performances et l'impact visuel d'avoir plus de vidéos sur une page chargée couramment limitent l'efficacité de chaque vidéo.

Un web qui évolue[]

Il est importer de garder Google heureux, du fait que c'est la manière d'attirer les visiteurs. Mais Google est basé sur la pensée et les habitudes des humains, donc ce que fait Google est en grande partie de rendre les humains heureux. Ce ne sont pas des pénalités que Fandom est en train d'imposer aux wikis. Il s'agit de mesures permettant de faire en sorte que les wikis restent pertinents dans un web qui évolue.

Polices de caractères et importations[]

Des polices de caractères spéciales peuvent paraître jolies (si on tient compte de certaines règles typographiques de base), mais elles ont aussi un impact sur les performances de votre wiki. Il existe deux types de polices sur les wikis : les polices web importées et les polices téléchargées. L'option idéale pour les performances est d'utiliser une police disponible sur Google Fonts et, lorsque vous importez plusieurs polices, de regrouper leurs URLs d'importation en une seule ligne. Pour les polices téléchargées, veuillez d'utiliser uniquement du WOFF2. WOFF2 est un format de fichier TrueType/OpenType compressé, optimisé pour le web et pris en charge par tous les principaux navigateurs. Il existe de nombreux outils de conversion gratuits sur le web pour produire un fichier WOFF2 à partir d'autres formats. L'utilisation d'un nombre limité de polices — pas plus de 3 — permet de conserver un aspect propre et professionnel à un wiki, et la fusion de leurs URLs d'importation en une seule ligne (lorsqu'elles proviennent de Google Fonts) est la meilleure solution pour les performances.

À l'exception de Google Fonts (qui dispose d'un système de diffusion de contenu solide et rapide), évitez d'importer (ou de lier en externe) des polices, JavaScript, CSS, des images ou toute autre ressource provenant de l'extérieur du système Fandom. L'importation de ressources hors site peut poser des problèmes de sécurité et avoir un impact certain sur les performances, et elle ajoute du temps au processus de chargement vital (parfois des secondes) lorsque chaque instant compte.

Modèles et complexité des pages[]

Les pages longues ne sont pas toujours des pages complexes, et vice versa. Les pages qui sont traitées à travers des couches de modèles à l'intérieur de modèles prennent plus de temps à être formées en HTML. Les pages qui sont presque entièrement façonnées à l'aide d'un seul modèle (par exemple, les modèles de mise en page) sont particulièrement difficiles à traiter et prennent plus de ressources côté serveur ; à la place, tous les wikis peuvent demander et essayer l'extension Page Forms nouvellement disponible (qui peut structurer les pages pour une édition cohérente). Ces formulaires peuvent également être plus efficaces que les modèles préchargés pour créer de nouvelles pages d'un type spécifique.

Lorsque l'on a affaire à des modèles particulièrement complexes (ceux qui comportent de nombreux ifs, commutateurs, opérations coûteuses, ou fonctions parseur), une conversion vers Lua (un langage de modèle alternatif puissant, efficace et léger) est probablement plus efficace, en particulier lorsque votre modèle est fréquemment utilisé ou appelé par d'autres modèles. Bien que Lua puisse être un outil puissant, il n'est pas facile à apprendre, alors n'hésitez pas à vous tourner vers notre Discord pour une aide à la conversion (ou pour déterminer si Lua est la bonne solution). L'utilisation de Lua est presque toujours plus rapide que l'imbrication de modèles.

La présence d'une Infobox portable sur une page fournit efficacement des informations à Google (ce qui lui permet d'être mieux placé). Ce sont également des éléments particulièrement performants, qui traitent les données de manière efficace. En revanche, l'utilisation de tableaux pour les infobox et autres éléments de mise en page ne fonctionne pas aussi bien sur les appareils mobiles ou autres affichages réactifs. L'imbrication des tableaux les uns dans les autres est également un problème connu pour la portabilité d'une page (c'est-à-dire l'affichage du contenu sur plusieurs platesformes et plusieurs habillages) et doit donc être évitée.

Données et transclusion[]

La manière idéale d'afficher les mêmes données sur plusieurs pages est de conserver toutes les données sur la page que vous souhaitez afficher (c'est-à-dire de les décentraliser). Bien que la mise à jour puisse demander plus d'efforts, le traitement des pages est plus rapide. L'utilisation d'une automatisation lourde pour étendre le texte tend à rendre le texte plus difficile à comprendre pour les nouveaux éditeurs et prolonge le temps nécessaire au traitement de chaque page.

De nombreux wikis à forte densité de données ont tendance à utiliser des options lourdes, comme Semantic MediaWiki ou Cargo, pour distribuer les informations en utilisant les pages d'articles pour stocker les données saisies. Ils peuvent aussi utiliser des options modérément lourdes, comme DynamicPageList ou Limited Section Transclusion, pour prendre des blocs de contenu d'une page et les placer dans une autre. D'autres, lorsqu'ils ne peuvent pas les utiliser, se tournent vers le stockage centralisé des données dans des modules Lua et les traitent comme des bases de données. Le stockage des données dans un emplacement central comme un module Lua ou un modèle est intrinsèquement difficile en termes de performances et ralentit le temps de chargement de vos pages.

Références[]

  1. Il est difficile d'être plus clair ou d'insister suffisamment sur l'importance que Google a prise dans notre toile mondiale : sans Google, très peu de sites web d'information seraient capables d'attirer un trafic régulier. Il ne s'agit pas de publicité, de vie privée ou de partage social. En réalité, plus que tout autre utilitaire web, Google Search met de l'ordre dans le chaos et alimente l'ensemble du web.
  2. Google maintient une position dominante sur la recherche dans toutes les langues dans presque tous les pays sauf en Chine continentale, au Japon, en Russie, en Corée du Sud et en Turquie. Dans la plupart de ces pays, Google conserve une part de marché très majoritaire ou limitée par les gouvernements nationaux. Bien que les préférences personnelles d'un utilisateur puissent être Bing, Yahoo, Baidu, Yandex ou DuckDuckGo — ces sites ne représentent pas plus de 10 % de l'ensemble des recherches sur le web dans le monde. Google est effectivement le seul moteur de recherche externe significatif pour les opérations web de Fandom et donc le seul dont nous nous préoccupons dans « keeping happy » (garder heureux). Le bonheur de Google s'étend aux bonnes pratiques de tous les autres moteurs de recherche et offrir une meilleure expérience aux chercheurs est en fin de compte meilleur pour nos communautés.
  3. Barry Schwartz, "Google: Mobile-First Indexing Should Be Mobile-Only Indexing," Search Engine Roundtable (https://www.seroundtable.com/google-mobile-first-indexing-mobile-only-indexing-30270.html, n.d.)
  4. Roger Montti, "What Is Google Passage Ranking: 16 Key Points You Should Know," Search Engine Journal (https://www.searchenginejournal. com/google-passage-ranking-martin-splitt/388206/, novembre 2020)
  5. Detlef Johnson, "Guide to Core Web Vitals for SEOs and Developers", Search Engine Land (https://searchengineland.com/google-core-web-vitals-guide-for-seo-developers-337825, juillet 2020)
  6. Parabole « Les aveugles et l'éléphant » (Image « Les aveugles et l'éléphant », 1907.)