Wiki della Community
Advertisement
Wiki della Community

Come il web (e i servizi e i siti che lo supportano) cresce e cambia, anche la parte tecnica di siti come Fandom deve adattarsi per accomodare le abitudini dei suoi utenti e rimanere moderna. Per i servizi di informazione come le wiki, ci sono infinite fonti dove i fan possono trovare risposte su quasi qualsiasi argomento.

Benché ci piacerebbe immagire che i fan giungano su questa o quella community di Fandom digitando l'indirizzo web direttamente, la realtà è che più dell'80% dei visitatori web arriva attraverso i risultati di un motore di ricerca.[1] Nella maggior parte del mondo, Google fornisce una piattaforma quasi esclusiva per tutte le ricerche.[2] In aggiunta: la maggior parte delle ricerche che portano sulle wiki di Fandom non sono "X Wiki", ma sono molto più spesso ricerche per specifici titoli di pagina o argomenti. Questo rappresenta un cambiamento nelle abitudini degli utenti che si è evoluto con il web e il potente impatto dei motori di ricerca.

Google cambia frequentemente l'algoritmo che governa il suo servizio di ricerca e occasionalmente avverte il resto del web sui suoi piani previsti. Ci si aspetta che tre di queste modifiche annunciate[3][4][5] influenzeranno significativamente Fandom, in particolare a causa della natura con cui le wiki vengono sviluppate e aggiornate. Queste modifiche, se non corrisposte da una nostra reazione, abbasseranno la visibilità sia di singole wiki sia dell'intera piattaforma Fandom. Pertanto, questa guida tratterà di come le wiki sono viste da una prospettiva tecnica (e umana) e che cosa possono fare le community per fare i dovuti aggiustamenti.

Metriche[]

Ci sono molti fattori che definiscono le performance di una wiki e ciascun passo del processo ha metriche differenti.

Performance di MediaWiki[]

Prima che una pagina di wikitesto arrivi sul web, essa deve diventare HTML. Il processo di analisi e "interpretazione" avviene nel software dei server MediaWiki, dove la pagina viene tradotta riga per riga nel linguaggio base delle pagine web. La velocità a cui le pagine sono processate e restituite è tipicamente inferiore a due secondi e può essere più alta la seconda volta se la stessa pagina viene sottomessa senza modifiche tramite un processo chiamato "caching".

La performance di una pagina MediaWiki è misurata sulle risorse di tempo e memoria utilizzate per renderizzare la pagina e anche su quanto è complesso l'HTML risultante (poiché i browser devono interpretare il codice HTML e trasformarlo in qualcosa che gli umani possano capire visivamente). Le pagine che richiamano informazioni da altre parti del server (un processo chiamato "transclusione") richiedono più tempo e più risorse. Usare i template è una forma di transclusione, quindi la complessità e la profondità dell'annidamento dei template influenza la performance. A seconda di come sono scritte, questo si applica anche a estensioni che spostano il contenuto da una pagina all'altra (come il DynamicPageList).

"Diagramma di flusso della renderizzazione di MediaWiki"

Core Web Vitals[]

Recentemente, Google ha iniziato a prestare attenzione a tre indicatori chiave di performance che influenzano la classifica dei risultati di ricerca. Collettivamente, questi Core Web Vitals sono:

  • Largest Contentful Paint, o LCP, che misura la performance di caricamento, ovvero quanto rapidamente l'area di contenuti più grande della pagina diventa visibile al lettore.
  • First Input Delay, o FID, che misura l'interattività, ovvero quanto rapidamente i link o i moduli possono essere premuti o cliccati.
  • Cumulative Layout Shift, o CLS, che misura la stabilità visiva, ovvero quanto gli elementi nella schermata inizialmente visibile si muovono prima che ci si possa interagire.

Molto di quello che viene misurato dai Core Web Vitals dipende dalla gestione delle pagine parte di Fandom, benché ci siano azioni che possono essere fatte dagli utenti e dalle community per migliorare gli indicatori di una wiki. Nonostante sia importante notare queste cose per le pagine desktop, la maggior parte dell'attenzione di Google è concentrata sulle visualizzazioni da mobile (da parte di utenti non registrati o anonimi). Google considera in alcuni casi le wiki individualmente per il calcolo della classifica, ma considera anche Fandom come un unico blocco in diverse situazioni. I Core Web Vitals hanno un effetto più grande sulla piattaforma nel suo complesso (e quindi possono risollevare wiki più piccole che non sono ricercate tanto frequentemente), ma è comunque importante per le singole wiki esserne consapevoli e potenzialmente fare correzioni.

Contenuto comprensibile[]

Oltre alle semplici metriche, avere le pagine della propria wiki ben esposte e raggiungibili è un fattore importante per la performance.

Blind men and elephant4.jpg

Parti importanti dell'algoritmo di Google riguardano il "Passage Ranking" e l'indicizzazione "totale" della pagina. Google tocca ogni pagina che riesce a trovare attraverso i link nelle pagine e con discrezione mappa e crea copie nel suo database, che poi processa per cercare informazioni. Queste informazioni includono per Google leggere le frasi (dall'indice che ha creato) e "capire" il loro contesto — ad esempio, se una pagina dice (in una frase completa) che "X è la madre di Y" e un'altra pagina dice che "Z è il padre di X", Google di fatto ha un modello nella sua "mente" per cui "Z è il nonno di Y" senza che questo sia stato scritto esplicitamente. Questo processo di semantica aiuta Google a rispondere alle domande quando un utente cerca informazioni. Mentre l'analisi dei motori di ricerca arcaici era dipendente dalle parole chiave in una pagina, il passage ranking è tutto basato sull'usare il linguaggio naturale e dati esposti (come in tabelle e infobox) per sviluppare modelli così che Google sappia i posti giusti in cui indirizzare gli utenti. In un certo senso, questo è molto simile alla vecchia parabola de "I ciechi e l'elefante"[6], in cui informazioni frammentarie sono utilizzate per costruire il quadro completo. Questo è il motivo per cui avere più contesto e narrazione (anche se produce pagine più lunghe) aiuta a costruire un concetto completo a cui Google può riferirsi. Non è una coincidenza che questo metodo sia anche migliore per fare capire agli umani gli argomenti di una wiki, poiché molti dei metodi di Google sono progettati per mimare come pensano gli umani — se Google capisce cosa dice una pagina, penserà che quella pagina sia la risorsa migliore per gli umani che vogliono capire quella pagina (e altre sulla stessa wiki) e classificherà quelle pagine più in alto.

Queste pagine complete possono essere valutate da quanto bene sono riempite. Avere pagine sparse con contenuti di riferimento minimali è più utile per siti web tipo database che per wiki Fandom, dove gli utenti sono più interessati alla voce e alla saggezza della community che a semplici nozioni. L'esperienza della community su quando separare argomenti autoconclusivi da un articolo lungo o quando unire insieme articoli corti correlati è un aspetto importante che non è facilmente quantificabile.

Esperienza utente[]

I lettori non rimangono se sono spinti via. Avere pagine che sono troppo dense di informazioni o difficili da navigare spingerà chi cerca informazioni a guardare altrove proprio come avviene con pagine scritte male o di bassa qualità.

Google misura l'esperienza degli utenti sistematicamente, in diversi modi. Da un punto di vista oggettivo, Google può tracciare la quantità di tempo spesa su una pagina e attraverso un'analisi costruire un modello di come gli utenti sperimentano il contenuto al suo interno. Google impiega anche Quality Raters umani per verificare quanto è efficace l'algoritmo nell'indirizzare le persone nel posto giusto. Questi valutatori danno un'opinione professionale su quanto utile e utilizzabile sia una risorsa, che può influenzare indirettamente le classifiche quando l'algoritmo di Google viene tarato utilizzando in parte i loro rapporti.

Ma la misura più efficace dell'esperienza utente inizia con quanto semplice o difficile è navigare sulla pagina web — in particolare se è semplice comprendere e interagire con il contenuto su dispositivi mobili. Tutti gli stili elaborati e i gadget aggiunti alla pagina non possono nascondere materiale organizzato o scritto male; questa ostentazione potrebbe anzi rendere l'esperienza degli utenti ancora peggiore se cercano una nozione specifica e non riescono a superare i fronzoli o i pannelli nascosti della pagina per trovarla.

Aggiustamenti pratici[]

Ci sono dei metodi pratici per aumentare le performance di una wiki da semplici utenti. Molti di questi sono abitudini da riconsiderare, in parte perché il web è cambiato da quando le wiki furono introdotte per la prima volta. Ciascuna di queste individualmente ha un piccolo effetto, ma collettivamente contribuiscono a posizionare meglio una wiki nell'ottenere performance migliori.

Contenuto originale e abbozzi[]

Benché esistano strumenti di MediaWiki che automatizzano e interpretano gli aspetti tecnici della pagine, come la lunghezza e i collegamenti reciproci, questi strumenti non identificano gli abbozzi o il contenuto superficiale. Abbozzo è un termine tradizionalmente usato sulle wiki per pagine che sono manualmente segnalate come incomplete e che necessitano l'aggiunta di più informazioni. Il contenuto superficiale è quello che non risponde alle domande di chi cerca informazioni. Dunque, la maggior parte degli abbozzi sono considerati anch'essi contenuti superficiali, anche se non tutte le pagine corte sono abbozzi. Le wiki di Fandom non sono attualmente penalizzate per avere un'abbondanza di contenuti superficiali, nonostante ci siano evidenze che l'algoritmo di Google faccia assunzioni su una wiki (o su tutto Fandom) quando si imbatte in pagine di contenuti superficiali e possa agire di conseguenza in futuro.

Le pagine corte soffrono di problemi fondamentali, ma gli abbozzi in aggiunta hanno anche problemi di comprensione e di esperienza utente. Per esempio, le pagine corte hanno un'area di contenuti piccola; talvolta queste sono tanto piccole che le intestazioni e le barre degli strumenti diventano le aree più grandi della pagina. Di conseguenza, la piccola area di contenuti viene spostata relativamente di più da cose come le barre degli strumenti e ottiene un alto (e quindi cattivo) punteggio CLS. A causa della loro natura interattiva, le intestazioni e le barre degli strumenti sono più lente a caricare rispetto al contenuto; se sono il contenuto più grande nella pagina (in termini di dimensioni HTML, non di spazio visibile) e ci mettono di più a caricare, i punteggi LCP e FID saranno tutt'altro che ideali.

Gli abbozzi, poiché non rispondono alle ricerche approfondite a causa della loro natura superficiale, tendono ad avere punteggi bassi con Google. Avere un rapporto abbozzi su pagine complete significativo abbasserà la fiducia complessiva che Google ha nelle capacità della wiki di rispondere alle domande sul soggetto in questione e potrebbe dunque abbassare il punteggio di altre pagine sulla stessa wiki (anche se quelle pagine non sono abbozzi). Pertanto, è meglio eliminare gli abbozzi più velocemente possibile (prima di 30 giorni, quando ci si aspetta che Google possa re-indicizzare la wiki) cancellando la pagina, riempiendola in modo completo, o unendola ad una pagina correlata. Può essere utile ricordare che gli umani generalmente pensano allo stesso modo e preferiscono vedere poche informazioni come parte di un "quadro più grande" che vederle incomplete e isolate. Avere delle sezioni di una pagina vuote, specialmente sezioni introduttive vuote (anche note come "ledes"), ha un effetto negativo sia sul parser di Google sia sull'esperienza utente umana poiché questo vuoto rappresenta un strada chiusa invece di un'opportunità.

Si era soliti vedere i link rossi (o link a pagine non-esistenti) come opportunità per gli utenti e i futuri contributori per costruire nuove pagine di contenuto. Benchè ci sia qualche indagine su quanto siano efficaci nell'attrarre contributi, i link rossi sono un danno per i Web Vitals e le scansioni dei motori di ricerca; questo è il motivo per cui i link rossi sono mostrati come semplice testo nella versione mobile per gli utenti non-registrati. I link rossi portano le scansioni dei motori di ricerca su aree non esistenti, che contano effettivamente come errori quando una pagina non può essere trovata. Il computo totale degli errori incontrati su un sito web, wiki o no, riduce la sua credibilità e affidabilità percepita. Ridurre il numero complessivo di link rossi velocemente aiuterà le perfomance e il punteggio di una pagina.

Le pagine di Categoria sono spesso un pensiero secondario per le wiki. Possono avere punteggi alti tanto quanto le pagine di articoli se il modello di Google suggerisce che dovrebbero, secondo le informazioni che deduce. Quando non hanno un'introduzione o un contesto, appaiono nelle pagine di risultati di Google come parole ingarbugliate. Ciascuna categoria dovrebbe avere almeno un po' di testo nell'area contenuto della pagina.

Pagine robuste e usabilità da mobile[]

Una separazione del contenuto abbastanza incompresa è quando gli articoli vengono divisi in schede (con link in cima alla pagina o schede interattive). Quando queste linkano ad altre pagine — un processo che Fandom chiama navigare con pagine di schede — creano intrinsecamente o implicano concetti incompleti. Spargere le informazioni necessarie per capire quello che è tipicamente un unico soggetto dell'articolo (un personaggio, un episodio, un'arma, etc.; altrimenti noto come un'entità di contenuto) separate su pagine multiple rende più difficile per Google creare un modello di quel concetto. In un modo simile, è meno probabile che i lettori umani vogliano visitare e leggere molteplici pagine per capire le singole sfaccettature di uno stesso oggetto. A questo effetto ci si riferisce talvolta come "la nostra principessa è in un altro castello", poiché l'utente deve viaggiare tra diversi link per trovare quello che sta cercando, seguendo la pista dell'informazione in una caccia a quello che vuole veramente sapere.

Avere un "quadro completo" dove un utente si aspetta di trovarlo e avere una spiegazione più lunga e approfondita di un singolo aspetto in una pagina separata non è una cosa cattiva. Una pagina di "panoramica" (tipicamente chiamata una "pagina base" a causa del suo titolo senza sottopagine) dovrebbe contenere almeno le cose essenziali necessarie a capire il concetto dell'articolo. Link nel corpo del testo (magari usando i template {{Principale}} o {{Vedi anche}} sotto i titoli di sezione) possono portare il lettore alle informazioni più dettagliate e approfondite che vogliono, specialmente se uniti ad un sommario e una spiegazione del contesto. Per esempio, in una pagina con i link "Biografia" e "Storia" in cima, come potrebbe un lettore sapere quale informazioni sono contenute in ciascuna pagina? In questo modo, tutti gli articoli coinvolti possono e dovrebbero essere pensieri completi a pieno titolo e non frammenti da collezionare.

Bisogna anche notare che le schede, se create con template o Javascript per un layout ottimizzato nella versione desktop, non funzioneranno o non appariranno correttamente su dispositivi mobili. Questi link non avranno neppure alcuna rilevanza per Google come aiuti semantici (il contesto non viene compreso e appaiono solo come link orfani alla deriva in cima al titolo dell'articolo). Piuttosto che aggiungere qualcosa che non appare oppure non funziona bene per la maggioranza dei lettori, inserire i link di navigazione in un segmento <navigation> di un infobox produrrà un ponte che gli utenti da mobile e i motori di ricerca possono entrambi prontamente capire.

In questo modello, c'è poca distinzione tra "link a forma di scheda" in cima ad una pagina e link a forma di icona o indicatori (comunemente chiamati EraIcons) in qualche altro punto della pagina (inclusa l'intestazione). Entrambe le forme sono difficili da vedere o utilizzare su dispotivi mobili e il suggerimento di spostarsi alla navigazione infobox si applica per entrambi.

Nessun singolo blocco o elemento (inteso: non testo) è così importante per un articolo quanto un infobox. In un certo senso, insieme alla sezione introduttiva (o "lede"), gli infobox forniscono contesto e dati sul soggetto dell'articolo. In quanto tali, ricevono un trattamento speciale nella versione mobile e danno forti segnali a Google. La loro posizione evidente li rende ideali per la navigazione e l'interconnessione con altre pagine fortemente correlate.

Un problema con le sezioni che contengono immagini, tabelle e gallerie è che spesso non c'è alcuna "ancora" narrativa che contestualizzi la figura. Questo è sia per gli obiettivi semantici (così che Google capisca qual è la relazione tra il modello che crea per la pagina e la figura o tabella indicata) e gli obiettivi di accessibilità (così che i lettori di schermo e altri dispositivi di assistenza possano dare un indizio se l'informazione è rilevante o meno prima che la tabella o figura sia interpretata). Idealmente, tutte le immagini dovrebbe avere una didascalia (il testo che mette l'immagine in prospettiva per l'articolo; esempio: "Batman, 2020 circa") e/o un testo alternativo (che descrive letteralmente l'immagine per chi non può vederla; esempio: "Un personaggio in costume minaccioso su un tetto di notte"). Messa in un altro modo: l'alt-text spiega cosa qualcosa sia, la didascalia aiuta a spiegare perché è lì. Per le lunghe gallerie di immagini che possono essere raggruppate logicalmente, è meglio sia per il rendimento nelle performance sia per la comprensione umana dividerle in gallerie più piccole. L'ideale è frapporre tra queste immagini del testo di narrazione così che il testo e l'immagine si complementino a vicenda; questi layout funzionano bene su tutti i dispositivi.

Accorciare le pagine[]

Non c'è nulla di intrinsecamente sbagliato con le pagine lunghe (dal punto di vista dei motori di ricerca). Come notato sopra, è più probabile che siano interpretate come modelli di contenuto completi dal passage ranking di Google poiché l'intera pagina viene analizzata. Se il contenuto all'interno è ben organizzato, l'attenzione del lettore dovrebbe trovare molto da cui essere informato e divertito senza specifici punti difficili da trovare.

Tuttavia, bisogna notare che piazzare blocchi di contenuti in schede interattive (spesso chiamate "tabber") presenta ostacoli tecnici. Modificare blocchi di wikitesto che sono all'interno di codice complesso (paragrafi dentro una funzione parser) è più difficile con l'interfaccia di Editor Visuale utilizzata dalla maggior parte dei contributori e rende anche più difficile modificare con l'interfaccia di modifica del wikitesto nell'identificare dove gli elementi iniziano e finiscono. Lo strato di JavaScript interattivo aumenta il punteggio FID a causa della necessità di renderizzare gli elementi; se il tabber è nell'area della pagina inizialmente visibile quando si carica la prima volta, aumenterà anche il punteggio CLS a causa di quello che sposta. La stessa azione della scheda che rivela contenuto potrebbe non funzionare correttamente sui dispositivi mobili. Rapporti contrastanti sul web indicano che il contenuto nascosto in una scheda secondaria potrebbe non essere visto come importante da Google.

Forse la cosa più importante, però, è l'esperienza utente: il contenuto delle schede secondarie è "lontano dagli occhi, lontano dal cuore" e non è così probabile che venga visto dai lettori. Le schede oltre la prima sono aperte meno frequentemente, con ogni scheda aggiuntiva aperta con sempre meno probabilità. La maggior parte delle volte, i lettori non sanno nemmeno che c'è informazione non immediatamente visibile a loro e si lasceranno sfuggire quello che stanno cercando o che li sta divertendo perché è nascosto alla vista.

Per queste ragioni, utilizzare i tabber per "accorciare" la pagine è molto lontano dall'ideale per le performance e l'esperienza nella maggior parte dei casi. Se si devono usare dei tabber, le linee guida di usabilità di esperti di spicco di esperienza utente suggeriscono che questi devono:

  • non essere annidati uno dentro l'altro
  • avere le etichette delle schede solo su un'unica riga
  • usare etichette descrittive

L'inclusione delle DataTables in questo diagramma di flusso evidenzia una funzionalià che vogliamo enfatizzare. Disponibili presto tramite script dalla nostra Dev Wiki, le DataTables aggiungono molte nuove funzioni per migliorare l'esperienza con lunghe tabelle di dati. È anche importante notare che usare infobox multipli in una pagina è scoraggiato (per il tempo di processamento e il parsing dei motori di ricerca) ed è molto spesso più utile consolidare gli infobox multipli (in particolare quelli che condividono molte proprietà in comune) in un singolo infobox usando la funzione panel.

Pagine principali e navigazione[]

Le pagine principali sono speciali per le wiki per una varietà di ragioni. Per le macchine e gli umani che entrano con il semplice URL della wiki (al posto di una pagina specifica), rappresentano il punto di ingresso primario da cui dipartono i collegamenti. Google interpreta i link sulla pagina principale (e la barra di navigazione locale) come posti importanti per capire l'argomento della wiki. Quando Google esamina la wiki per la prima volta, non conoscendo niente sull'argomento discusso, assume che tutti i link abbiano lo stesso peso e importanza. Questo è semplice se ci sono 10 o 20 link a pagine o categorie. Quando i widget e i pannelli aggiungono centinaia di link alla pagina principale, il peso relativo di quei link tende a zero. Come questo documento ha già alluso più volte, questo è anche il modo in cui gli umani tendono a pensare: avere troppe scelte porta a una "paralisi della scelta"; l'effetto è che non sanno da dove iniziare a guardare per una vera comprensione.

Pertanto, per ragioni tecniche e di esperienza utente, suggeriamo fermamente di ridurre i link sulla pagina principale a quegli articoli e categorie più importanti per capire l'argomento della wiki. Suggeriamo anche di non utilizzare widget interattivi che scavano nelle liste di pagine della wiki dato che influenzano la renderizzazione, i vitals e le performance delle scansioni. Assumendo che siano linkate da qualche altra pagina, la scansione alla fine le raggiungerà. Altro da notare è che Google è istruito nella maggior parte dei casi per non scansionare le pagine Speciali o di Discussione, dove riceverebbe inizialmente un messaggio di errore o sarebbe reindirizzato altrove. Suggeriamo di non linkare a queste dalla pagina principale (e in molti casi queste sono linkate dalla navigazione locale o Speciale:Community che non sono immediatamente visibili a Google).

Ci sono molte opportunità per includere un video in una wiki, ma suggeriamo un massimo di due o tre widget con video incorporati. Sia l'impatto nella performance sia l'impatto visivo di avere più video in una pagina caricata spesso limita l'efficacia di ciascun video.

Font e import[]

I font speciali possono avere un bell'aspetto (quando si considerano alcune regole base di tipografia), ma impattano anche la performance della vostra wiki. I font sulle wiki possono essere di due tipi: font importati dal web e font caricati. L'opzione ideale per la performance è usare un font che sia disponibile su Google Fonts e, quando si importa più di un font, è bene mettere insieme i loro URL di import in un unico comando. Per i font caricati, utilizzate solo il formato WOFF2. WOFF2 è un formato di file compresso TrueType/OpenType ottimizzato per il web e supportato da tutti i browser più comuni e ci sono molti strumenti di conversione gratuiti sul web per produrre un file WOFF2 da altri formati. Usare un numero limitato di font - non più di 3 — mantiene il look della wiki pulito e professionale e mettere insieme i loro URL di import in un unico comando (quando vengono da Google Fonts) è la cosa migliore per la performance.

Oltre a Google Fonts (che hanno un sistema forte e veloce di comunicazione del contenuto), cercate di evitare di importare (o linkare dall'esterno) font, JavaScript, CSS, immagini o qualsiasi altra risorsa fuori dal circuito Fandom. Ci sono potenziali problemi di sicurezza e certamente un impatto sulla performance nell'importare risorse esterne, che aggiungono tempo al processo di caricamento (a volte di diversi secondi) quando ogni istante conta.

Template e complessità della pagina[]

Una pagina lunga non è sempre una pagina complessa, e viceversa. Le pagine che devono essere processate attraverso strati di template dentro template impiegano più tempo per essere trasformate in HTML. La pagine che sono costruite quasi interamente usando un singolo template (per esempio un template di layout di pagina) sono particolarmente difficili da processare e impiegano più risorse del server; al posto di questo, tutte le wiki possono richiedere e provare la nuova estensione disponibile Page Forms (che può strutturare le pagine per uniformarne lo stile). Questi form possono essere anche più efficaci dei template precaricati nel costruire nuove pagine di una tipologia specifica.

Quando si lavora con template particolarmente complessi (quelli con molti if, switch, operazioni dispendiose, o funzioni parser), una conversione a Lua (un potente, efficiente e leggero linguaggio alternativo per template) è probabilmente più efficiente, specialmente quando il template è usato frequentemente o chiamato da altri template. Benché Lua sia uno strumento potente, non è facile da imparare, quindi sentitevi liberi di rivolgervi sul nostro Discord per aiuto con la conversione (o per capire se Lua sia la soluzione giusta). Usare Lua è quasi sempre più veloce che annidare template.

Avere un Infobox Portatile su una pagina fornisce efficacemente le informazioni a Google (portando a piazzamenti più in vista). Sono anche elementi particolarmente performanti, che processano i dati efficientemente all'interno. In confronto, usare una tabella come infobox e altri elementi di layout non funziona altrettanto bene sui dispositivi mobili o su altri display touchscreen. Annidare tabelle una dentro l'altra è inoltre un noto problema per la portabilità della pagina (cioè la visualizzazione del contenuto su più piattaforme / più skin) e pertanto dovrebbe essere evitato.

Dati e inclusioni[]

Il modo ideale per visualizzare gli stessi dati su pagine multiple è tenere tutti i dati sulla pagina in cui si vuole mostrarli (cioè decentralizzare). Anche se questo può richiedere più lavoro per aggiornare le pagine, permette di velocizzare il loro processamento. Utilizzare un'automatizzazione pesante per espandere il testo tende a renderlo più difficile da capire per i nuovi contributori e allunga il tempo che impiega ciascuna pagina ad essere processata.

Molte wiki incentrate sui dati tendono ad usare opzioni da pesi massimi, come Semantic MediaWiki o Cargo, per distribuire le informazioni usando gli articoli per contenere i dati inseriti. Usano anche opzioni più moderate, come DynamicPageList o l'inclusione limitata a sezioni, per prendere blocchi di contenuto da una pagina e inserirli in un'altra. Altri, quando non possono usare queste cose, scelgono di contenere i dati in modo centralizzato in moduli Lua e li trattano come database. Immagazzinare i dati in un posto centralizzato come un modulo Lua o un template è intrinsecamente dannoso per la performance e rallenta il tempo di caricamento delle pagine.

Un web in evoluzione[]

È importante mantenere Google felice perché è così che facciamo visite. Ma Google è basato sul pensiero e sulle abitudini umane, quindi quello che fa Google è in gran parte rendere gli umani felici. Queste non sono penalità che Fandom impone sulle wiki. Queste sono misure che mantengono le singole wiki rilevanti in un web in evoluzione.

Note[]

  1. È difficile essere più chiari o enfatizzare abbastanza quanto importante sia divenuto Google sul web: senza Google, solo pochi siti di informazione sarebbero in grado di attirare traffico in modo consistente. Non si tratta di annunci, privacy o condivisione sui social. Nel vero senso della parola, più di qualsiasi altra utility web, Google Search porta ordine al caos e alimenta l'intero web.
  2. Google mantiene una posizione dominante nelle ricerche in tutte le lingue in quasi tutti i paesi eccetto la Cina continentale, il Giappone, la Russia, la Corea del Sud e la Turchia. Nella maggior parte di questi paesi, Google mantiene comunque la maggioranza delle quote del mercato oppure è limitato dai governi nazionali. Anche se la preferenza personale di un utente possa essere Bing, Yahoo, Baidu, Yandex o DuckDuckGo — questi insieme non rappresentano più del 10% di tutte le ricerche web globali. Google è effettivamente l'unico motore di ricerca esterno rilevante per le operazioni web di Fandom e pertanto l'unico che siamo interessati a "mantenere felice". Le felicità di Google si estende a buone pratiche anche per ogni altro motore di ricerca e fornire migliori esperienze di ricerca è in definitiva meglio per le nostre community.
  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/, November 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, July 2020)
  6. La parabola "I ciechi e l'elefante" (Immagine "Blind Men and an Elephant," 1907.)
Advertisement