Reagisci alle strategie SEO e alle migliori pratiche

React è stato sviluppato per creare interfacce utente interattive dichiarative , modulari e multipiattaforma . Oggi è uno dei framework JavaScript più popolari, se non il più popolare, per la scrittura di applicazioni front-end ad alte prestazioni. Sviluppato inizialmente per scrivere applicazioni a pagina singola (SPA), React è ora utilizzato per creare siti Web e applicazioni mobili a tutti gli effetti.

Se hai una vasta esperienza nello sviluppo web convenzionale e passi a React, noterai che una quantità crescente di codice HTML e CSS si sposta in JavaScript. Questo perché React non consiglia di creare o aggiornare direttamente gli elementi dell'interfaccia utente, ma invece di descrivere lo "stato" dell'interfaccia utente. React aggiornerà quindi il DOM in modo che corrisponda allo stato nel modo più efficiente.

Di conseguenza, tutte le modifiche all'interfaccia utente o al DOM devono essere apportate tramite il motore di React. Sebbene sia conveniente per gli sviluppatori, ciò può significare tempi di caricamento più lunghi per gli utenti e più lavoro per i motori di ricerca per trovare e indicizzare il contenuto.

In questo articolo, affronteremo le sfide affrontate durante la creazione di app e siti Web React con prestazioni SEO e delineeremo diverse strategie utilizzate per superarle.

Come Google scansiona e indicizza le pagine web

Google riceve oltre il 90% di tutte le ricerche online. Diamo un'occhiata più da vicino al suo processo di scansione e indicizzazione.

Questa istantanea tratta dalla documentazione di Google può aiutarci. Si prega di notare che questo è uno schema a blocchi semplificato. L'attuale Googlebot è molto più sofisticato.

Punti da notare:

1. Googlebot mantiene una coda di scansione contenente tutti gli URL necessari per eseguire la scansione e l'indicizzazione in futuro.
2. Quando il crawler è inattivo, preleva l'URL successivo nella coda, effettua una richiesta e recupera l'HTML.
3. Dopo aver analizzato l'HTML, Googlebot determina se è necessario recuperare ed eseguire JavaScript per eseguire il rendering del contenuto. Se sì, l'URL viene aggiunto a una coda di rendering.
4. In un secondo momento, il renderer recupera ed esegue JavaScript per eseguire il rendering della pagina. Invia l'HTML renderizzato all'unità di elaborazione.
5. L'unità di elaborazione estrae tutti i <a> tags menzionati nella pagina Web e li aggiunge nuovamente alla coda di scansione.
6. Il contenuto viene aggiunto all'indice di Google.

Si noti che esiste una chiara distinzione tra la fase Elaborazione che analizza l'HTML e la fase Renderer che esegue JavaScript.

Questa distinzione esiste perché l'esecuzione di JavaScript è costosa , dato che i Googlebot devono guardare oltre 130 trilioni di pagine web. Pertanto, quando Googlebot esegue la scansione di una pagina Web, analizza immediatamente l'HTML e quindi mette in coda il JavaScript per l'esecuzione in un secondo momento. La documentazione di Google menziona che una pagina rimane nella coda di rendering per alcuni secondi, anche se potrebbe essere più lungo.

Vale anche la pena menzionare il concetto di crawl budget. La scansione di Google è limitata dalla larghezza di banda, dal tempo e dalla disponibilità delle istanze di Googlebot. Alloca un budget o risorse specifici per indicizzare ogni sito web. Se stai costruendo un grande sito web ricco di contenuti con migliaia di pagine (ad es. un sito di e-commerce) e queste pagine utilizzano molto JavaScript per visualizzare i contenuti, Google potrebbe essere in grado di leggere meno contenuti dal tuo sito web.

Nota: puoi leggere le linee guida di Google per la gestione del budget di scansione qui.

Perché ottimizzare React per la SEO è impegnativo

La nostra breve panoramica di Googlebot, scansione e indicizzazione graffia solo la superficie. Tuttavia, gli ingegneri del software dovrebbero identificare i potenziali problemi affrontati dai motori di ricerca che cercano di eseguire la scansione e l'indicizzazione delle pagine React. Ora possiamo dare un'occhiata più da vicino a ciò che rende React SEO impegnativo e ciò che gli sviluppatori possono fare per affrontare e superare alcune di queste sfide.

Contenuto di primo passaggio vuoto

Sappiamo che le applicazioni React fanno molto affidamento su JavaScript e spesso incontrano problemi con i motori di ricerca. Questo perché React utilizza un modello di shell dell'app per impostazione predefinita. L'HTML iniziale non contiene alcun contenuto significativo e un utente o un bot deve eseguire JavaScript per vedere il contenuto effettivo della pagina.

Questo approccio significa che Googlebot rileva una pagina vuota durante il primo passaggio. Il contenuto viene visualizzato da Google solo quando la pagina viene visualizzata. Ciò ritarderà l'indicizzazione del contenuto quando si tratta di migliaia di pagine.

Tempo di caricamento ed esperienza utente

Il recupero, l'analisi e l'esecuzione di JavaScript richiede tempo. Inoltre, JavaScript potrebbe dover effettuare chiamate di rete per recuperare il contenuto e l'utente potrebbe dover attendere un po' prima di poter visualizzare le informazioni richieste.

Google ha presentato una serie di elementi vitali web relativi all'esperienza dell'utente, utilizzati nei suoi criteri di classificazione. Un tempo di caricamento più lungo può influire sul punteggio dell'esperienza utente, spingendo Google a classificare un sito più in basso.

Esaminiamo in dettaglio le prestazioni del sito Web nella sezione seguente.

Metadati della pagina

I meta tag <meta> sono utili perché consentono a Google e ad altri siti di social media di mostrare titoli, miniature e descrizioni appropriati per le pagine. Ma questi siti Web si basano sul tag <head> della pagina Web recuperata per ottenere queste informazioni. Questi siti Web non eseguono JavaScript per la pagina di destinazione.

React esegue il rendering di tutto il contenuto, inclusi i meta tag, sul client. Poiché la shell dell'app è la stessa per l'intero sito Web/applicazione, potrebbe essere difficile adattare i metadati per le singole pagine.

Mappa del sito

Una mappa del sito è un file in cui fornisci informazioni su pagine, video e altri file sul tuo sito e le relazioni tra di loro. I motori di ricerca come Google leggono questo file per eseguire una scansione più intelligente del tuo sito.

React non ha un modo integrato per generare mappe del sito. Se stai usando qualcosa come React Router per gestire il routing, puoi trovare strumenti in grado di generare una mappa del sito anche se potrebbe richiedere un certo sforzo.

Altre considerazioni SEO

Queste considerazioni sono legate all'impostazione di buone pratiche SEO in generale.

1. Avere una struttura URL ottimale per dare agli utenti e ai motori di ricerca una buona idea su cosa aspettarsi dalla pagina.
2. L'ottimizzazione del file robots.txt può aiutare i robot di ricerca a capire come eseguire la scansione delle pagine del tuo sito web.
3. Usa una CDN per servire tutte le risorse statiche come CSS, JS, font ecc. e usa immagini reattive per ridurre i tempi di caricamento.

Possiamo risolvere molti dei problemi descritti sopra utilizzando il rendering lato server (SSR) o il pre-rendering. Esamineremo questi approcci di seguito.

Inserisci la reazione isomorfa

La definizione del dizionario di isomorfo è "corrispondente o simile nella forma".

In termini di React, ciò significa che il server ha una forma simile al client. In altre parole, puoi riutilizzare gli stessi componenti React sul server e sul client.

Questo approccio isomorfo consente al server di eseguire il rendering dell'app React e inviare la versione renderizzata ai nostri utenti e motori di ricerca in modo che possano visualizzare il contenuto istantaneamente mentre JavaScript viene caricato ed eseguito in background.

Framework come Next.js o Gatsby hanno reso popolare questo approccio. Dovremmo notare che i componenti isomorfi possono apparire sostanzialmente diversi dai componenti React convenzionali. Ad esempio, possono includere codice che viene eseguito sul server anziché sul client. Possono anche includere segreti API (sebbene il codice del server venga rimosso prima di essere inviato al client).

Un punto da notare è che questi framework astraggono molta complessità ma introducono anche un modo supponente di scrivere codice. Approfondiremo ulteriormente i compromessi delle prestazioni in questo articolo.

Faremo anche un'analisi della matrice per comprendere la relazione tra i percorsi di rendering e le prestazioni del sito web. Ma prima, esaminiamo alcune nozioni di base sulla misurazione delle prestazioni del sito Web.

Metriche per le prestazioni del sito web

Esaminiamo alcuni dei fattori utilizzati dai motori di ricerca per classificare i siti web.

Oltre a rispondere alla domanda di un utente in modo rapido e accurato, Google ritiene che un buon sito Web dovrebbe avere i seguenti attributi:

• Dovrebbe caricarsi rapidamente.
• Gli utenti dovrebbero essere in grado di accedere ai contenuti senza troppi tempi di attesa.
• Dovrebbe diventare presto interattivo per le azioni di un utente.
• Non dovrebbe recuperare dati non necessari o eseguire codice costoso per evitare di scaricare i dati o la batteria di un utente.

Queste caratteristiche sono mappate approssimativamente alle seguenti metriche:

• TTFB : Time to First Byte – Il tempo tra il clic su un collegamento e il primo bit di contenuto in arrivo.
• LCP : Largest Contentful Paint – L'ora in cui l'articolo richiesto diventa visibile. Google consiglia di mantenere questo valore al di sotto di 2,5 secondi.
• TTI : Time To Interactive – L'ora in cui una pagina diventa interattiva (un utente può scorrere, fare clic, ecc.).
• Dimensione del pacchetto : il numero totale di byte scaricati e il codice eseguito prima che la pagina diventasse completamente visibile e interattiva.

Rivisiteremo queste metriche per comprendere meglio in che modo i vari percorsi di rendering possono influire su ciascuno di essi.

Successivamente, comprendiamo i diversi percorsi di rendering disponibili per gli sviluppatori di React.

Percorsi di rendering

Possiamo eseguire il rendering di un'applicazione React nel browser o sul server e produrre output variabili.

Due funzioni cambiano in modo significativo tra le app renderizzate lato client e lato server, ovvero il routing e la suddivisione del codice . Diamo un'occhiata più da vicino a questi di seguito.

Rendering lato client (CSR)

Il rendering lato client è il percorso di rendering predefinito per una React SPA. Il server servirà un'app shell che non contiene alcun contenuto. Una volta che il browser scarica, analizza ed esegue le origini JavaScript incluse, il contenuto HTML viene compilato o visualizzato .

La funzione di instradamento è gestita dall'app client gestendo la cronologia del browser. Ciò significa che lo stesso file HTML viene servito indipendentemente dal percorso richiesto e il client aggiorna il suo stato di visualizzazione dopo il rendering.

La suddivisione del codice è relativamente semplice. Puoi dividere il tuo codice usando le importazioni dinamiche o React.lazy in modo tale che solo le dipendenze necessarie vengano caricate in base al percorso o alle azioni dell'utente.

Se la pagina ha bisogno di recuperare i dati dal server per eseguire il rendering del contenuto, ad esempio il titolo di un blog o la descrizione di un prodotto, può farlo solo quando i componenti pertinenti vengono montati e visualizzati.

Molto probabilmente l'utente vedrà un segno o un indicatore "Caricamento dei dati" mentre il sito Web recupera dati aggiuntivi.

Rendering lato client con dati bootstrap (CSRB)

Considera lo stesso scenario di CSR ma invece di recuperare i dati dopo il rendering del DOM, supponiamo che il server abbia inviato dati rilevanti avviati all'interno dell'HTML servito.

Potremmo includere un nodo simile a questo:

 <script type="application/json"> {"title": "My blog title", "comments":["comment 1","comment 2"]} </script>

E analizzalo quando il componente viene montato:

 var data = JSON.parse(document.getElementById('data').innerHTML);

Ci siamo appena risparmiati un viaggio di andata e ritorno al server. Tra poco vedremo i compromessi.

Rendering lato server in contenuto statico (SSRS)

Immagina uno scenario in cui dobbiamo generare HTML al volo.

Ad esempio, se stiamo costruendo un calcolatore online e l'utente emette una query del tipo /calculate/34+15 (tralasciando l'escape dell'URL). Dobbiamo elaborare la query, valutare il risultato e rispondere con l'HTML generato.

Il nostro HTML generato ha una struttura abbastanza semplice e non abbiamo bisogno di React per gestire e manipolare il DOM una volta che l'HTML generato è stato servito.

Quindi stiamo solo servendo contenuti HTML e CSS. È possibile utilizzare il metodo renderToStaticMarkup per ottenere questo risultato.

L'instradamento sarà interamente gestito dal server in quanto deve ricalcolare l'HTML per ogni risultato, sebbene la memorizzazione nella cache CDN possa essere utilizzata per fornire risposte più velocemente. I file CSS possono anche essere memorizzati nella cache dal browser per caricare le pagine successive più velocemente.

Rendering lato server con reidratazione (SSRH)

Immagina lo stesso scenario di quello descritto sopra, ma questa volta abbiamo bisogno di un'applicazione React completamente funzionante sul client.

Eseguiamo il primo rendering sul server e rispediremo il contenuto HTML insieme ai file JavaScript. React reidraterà il markup visualizzato dal server e l'applicazione si comporterà come un'applicazione CSR da questo momento in poi.

React fornisce metodi integrati per eseguire queste azioni.

La prima richiesta viene gestita dal server ei successivi rendering vengono gestiti dal client. Pertanto, tali app sono chiamate app React universali (renderizzate sia sul server che sul client). Il codice per gestire il routing può essere suddiviso (o duplicato) su client e server.

Anche la suddivisione del codice è un po' complicata poiché ReactDOMServer non supporta React. pigro, quindi potresti dover usare qualcosa come Componenti caricabili.

Va anche notato che ReactDOMServer esegue solo un rendering superficiale. In altre parole, sebbene venga richiamato il metodo di rendering per i componenti, i metodi del ciclo di vita come componentDidMount non verranno chiamati. Quindi dovrai refactoring del tuo codice per fornire dati ai tuoi componenti usando un metodo alternativo.

È qui che fanno la loro comparsa framework come NextJS. Mascherano le complessità associate all'instradamento e alla suddivisione del codice in SSRH e offrono un'esperienza di sviluppo più fluida.

Questo approccio produce risultati contrastanti quando si tratta di prestazioni della pagina, come noteremo tra un po'.

Pre-rendering in contenuto statico (PRS)

E se potessimo eseguire il rendering di una pagina Web prima che un utente lo richieda? Questo potrebbe essere fatto in fase di compilazione o dinamicamente quando i dati cambiano.

Possiamo quindi memorizzare nella cache il contenuto HTML risultante su una CDN e servirlo molto più velocemente quando un utente lo richiede.

Questo è chiamato pre-rendering prima del rendering del contenuto, richiesta pre-utente. Questo approccio può essere utilizzato per blog e applicazioni di e-commerce poiché il loro contenuto in genere non dipende dai dati forniti dall'utente.

Pre-rendering con Reidratazione (PRH)

Potremmo desiderare che il nostro HTML prerenderizzato sia un'app React completamente funzionale quando un client lo esegue il rendering.

Dopo che la prima richiesta è stata servita, l'applicazione si comporterà come un'app React standard. Questa modalità è simile a SSRH, descritta sopra, in termini di funzioni di routing e di suddivisione del codice.

Matrice delle prestazioni

Il momento che stavi aspettando è finalmente arrivato. È tempo di una resa dei conti. Diamo un'occhiata a come ciascuno di questi percorsi di rendering influisce sulle metriche delle prestazioni web e determiniamo il vincitore.

In questa matrice, assegniamo un punteggio a ciascun percorso di rendering in base al rendimento in una metrica delle prestazioni.

Il punteggio va da 1 a 5:

• 1 = Insoddisfacente
• 2 = Scarso
• 3 = Moderato
• 4 = Bene
• 5 = Eccellente

Da asporto chiave

Il pre-rendering in contenuto statico (PRS) porta a siti Web con le prestazioni più elevate, mentre il rendering lato server con idratazione (SSRH) o il rendering lato client (CSR) può portare a risultati deludenti.

È anche possibile adottare approcci multipli per diverse parti del sito web . Ad esempio, queste metriche delle prestazioni possono essere fondamentali per le pagine Web rivolte al pubblico in modo che possano essere indicizzate in modo più efficiente mentre potrebbero essere meno importanti una volta che un utente ha effettuato l'accesso e vede i dati dell'account privato.

Ogni percorso di rendering rappresenta dei compromessi su dove e come desideri elaborare i tuoi dati. L'importante è che un team di ingegneri sia in grado di vedere e discutere chiaramente questi compromessi e scegliere un'architettura che massimizzi la felicità dei propri utenti.

Ulteriori letture e considerazioni

Anche se ho cercato di coprire le tecniche attualmente popolari, questa non è un'analisi esauriente. Consiglio vivamente di leggere questo articolo in cui gli sviluppatori di Google discutono di altre tecniche avanzate come il rendering del server di streaming, il rendering trisomorfo e il rendering dinamico (che forniscono risposte diverse a crawler e utenti).

Alcuni altri fattori che devi considerare durante la creazione di siti Web ricchi di contenuti includono la necessità di un buon sistema di gestione dei contenuti (CMS) per i tuoi autori e la possibilità di generare/modificare facilmente le anteprime dei social media e ottimizzare le immagini per dimensioni dello schermo variabili.