React SEO Strategii și bune practici

React a fost dezvoltat pentru a crea interfețe de utilizare interactive care sunt declarative , modulare și multiplatforme . Astăzi, este unul dintre cele mai populare, dacă nu și cel mai popular, framework-uri JavaScript pentru scrierea aplicațiilor front-end performante. Dezvoltat inițial pentru a scrie aplicații cu o singură pagină (SPA), React este acum folosit pentru a crea site-uri web cu drepturi depline și aplicații mobile.

Dacă aveți o experiență vastă în dezvoltarea web convențională și treceți la React, veți observa că o cantitate din ce în ce mai mare din codul dvs. HTML și CSS se mută în JavaScript. Acest lucru se datorează faptului că React nu recomandă crearea sau actualizarea directă a elementelor UI, ci în schimb să descrie „starea” UI. React va actualiza apoi DOM-ul pentru a se potrivi cu starea în cel mai eficient mod.

Ca rezultat, toate modificările la UI sau DOM trebuie făcute prin intermediul motorului React. Deși convenabil pentru dezvoltatori, acest lucru poate însemna timpi de încărcare mai lungi pentru utilizatori și mai multă muncă pentru motoarele de căutare pentru a găsi și indexa conținutul.

În acest articol, vom aborda provocările cu care se confruntă în timpul construirii de aplicații și site-uri web React performante SEO și vom schița câteva strategii folosite pentru a le depăși.

Cum accesează Google cu crawlere și indexează paginile web

Google primește peste 90% din toate căutările online. Să aruncăm o privire mai atentă asupra procesului său de accesare cu crawlere și indexare.

Acest instantaneu preluat din documentația Google ne poate ajuta. Vă rugăm să rețineți că aceasta este o diagramă bloc simplificată. Googlebot propriu-zis este mult mai sofisticat.

Puncte de reținut:

1. Googlebot menține o coadă de accesare cu crawlere care conține toate adresele URL de care are nevoie pentru a fi accesate cu crawlere și indexate în viitor.
2. Când crawler-ul este inactiv, preia următoarea adresă URL din coadă, face o solicitare și preia codul HTML.
3. După analizarea codului HTML, Googlebot stabilește dacă trebuie să preia și să execute JavaScript pentru a reda conținutul. Dacă da, adresa URL este adăugată la o coadă de randare.
4. La un moment ulterior, redarea preia și execută JavaScript pentru a reda pagina. Acesta trimite HTML redat înapoi la unitatea de procesare.
5. Unitatea de procesare extrage toate <a> tags menționate pe pagina web și le adaugă înapoi în coada de accesare cu crawlere.
6. Conținutul este adăugat la indexul Google.

Observați că există o distincție clară între etapa de procesare care analizează HTML și etapa de redare care execută JavaScript.

Această distincție există deoarece executarea JavaScript este costisitoare , având în vedere că Googlebots trebuie să se uite la peste 130 de trilioane de pagini web. Așadar, atunci când Googlebot accesează cu crawlere o pagină web, acesta analizează imediat codul HTML și apoi pune în coadă JavaScript pentru a rula mai târziu. Documentația Google menționează că o pagină rămâne în coada de randare pentru câteva secunde, deși poate fi mai lungă.

De asemenea, merită menționat și conceptul de buget crawl. Accesul cu crawlere Google este limitat de lățimea de bandă, timpul și disponibilitatea instanțelor Googlebot. Alocă un buget sau resurse specifice pentru a indexa fiecare site web. Dacă construiți un site web mare de conținut, cu mii de pagini (de exemplu, un site de comerț electronic) și aceste pagini folosesc mult JavaScript pentru a reda conținutul, Google ar putea să citească mai puțin conținut de pe site-ul dvs.

Notă: puteți citi regulile Google pentru gestionarea bugetului de accesare cu crawlere aici.

De ce este o provocare optimizarea React pentru SEO

Scurta noastră prezentare a Googlebot, crawling și indexare doar zgârie suprafața. Cu toate acestea, inginerii de software ar trebui să identifice problemele potențiale cu care se confruntă motoarele de căutare care încearcă să acceseze cu crawlere și să indexeze paginile React. Acum putem arunca o privire mai atentă la ceea ce face ca React SEO să fie provocator și ce pot face dezvoltatorii pentru a aborda și depăși unele dintre aceste provocări.

Conținut gol de prima trecere

Știm că aplicațiile React se bazează în mare măsură pe JavaScript și întâmpină adesea probleme cu motoarele de căutare. Acest lucru se datorează faptului că React folosește un model de shell de aplicație în mod implicit. HTML inițial nu conține niciun conținut semnificativ, iar un utilizator sau un bot trebuie să execute JavaScript pentru a vedea conținutul real al paginii.

Această abordare înseamnă că Googlebot detectează o pagină goală în timpul primei treceri. Conținutul este văzut de Google numai atunci când pagina este redată. Acest lucru va întârzia indexarea conținutului atunci când aveți de-a face cu mii de pagini.

Timpul de încărcare și experiența utilizatorului

Preluarea, analizarea și executarea JavaScript necesită timp. Mai mult, este posibil ca JavaScript să fie nevoit să efectueze apeluri în rețea pentru a prelua conținutul, iar utilizatorul poate fi nevoit să aștepte un timp înainte de a putea vizualiza informațiile solicitate.

Google a stabilit un set de elemente vitale web legate de experiența utilizatorului, utilizate în criteriile sale de clasare. Un timp mai lung de încărcare poate afecta scorul experienței utilizatorului, determinând Google să clasifice mai jos un site.

Analizăm performanța site-ului în detaliu în secțiunea următoare.

Metadatele paginii

Meta-etichetele <meta> sunt utile deoarece permit Google și altor site-uri de social media să afișeze titluri, miniaturi și descrieri adecvate pentru pagini. Dar aceste site-uri se bazează pe eticheta <head> a paginii web preluate pentru a obține aceste informații. Aceste site-uri web nu execută JavaScript pentru pagina țintă.

React redă tot conținutul, inclusiv metaetichetele, pe client. Deoarece shell-ul aplicației este același pentru întregul site/aplicație, poate fi dificil să adaptați metadatele pentru pagini individuale.

Harta site-ului

O hartă a site-ului este un fișier în care furnizați informații despre paginile, videoclipurile și alte fișiere de pe site-ul dvs. și relațiile dintre acestea. Motoarele de căutare precum Google citesc acest fișier pentru a vă accesa cu crawlere mai inteligent site-ul.

React nu are o modalitate încorporată de a genera sitemap-uri. Dacă utilizați ceva precum React Router pentru a gestiona rutarea, puteți găsi instrumente care pot genera o hartă a site-ului, deși poate necesita ceva efort.

Alte considerații SEO

Aceste considerații sunt legate de stabilirea unor bune practici SEO în general.

1. Aveți o structură URL optimă pentru a oferi oamenilor și motoarelor de căutare o idee bună despre ce să se aștepte pe pagină.
2. Optimizarea fișierului robots.txt poate ajuta roboții de căutare să înțeleagă cum să acceseze cu crawlere paginile de pe site-ul dvs. web.
3. Utilizați un CDN pentru a servi toate activele statice, cum ar fi CSS, JS, fonturi etc. și utilizați imagini receptive pentru a reduce timpii de încărcare.

Putem rezolva multe dintre problemele prezentate mai sus utilizând randarea pe server (SSR) sau pre-randarea. Vom analiza mai jos aceste abordări.

Intră în Reacția izomorfă

Definiția din dicționar a izomorfei este „forma corespunzătoare sau similară”.

În termeni React, aceasta înseamnă că serverul are o formă similară cu cea a clientului. Cu alte cuvinte, puteți reutiliza aceleași componente React pe server și client.

Această abordare izomorfă permite serverului să redeze aplicația React și să trimită versiunea redată utilizatorilor și motoarelor noștri de căutare, astfel încât aceștia să poată vizualiza conținutul instantaneu în timp ce JavaScript se încarcă și se execută în fundal.

Framework-uri precum Next.js sau Gatsby au popularizat această abordare. Ar trebui să remarcăm că componentele izomorfe pot arăta substanțial diferit față de componentele React convenționale. De exemplu, pot include cod care rulează pe server în loc de client. Ele pot include chiar și secrete API (deși codul serverului este eliminat înainte de a fi trimis către client).

Un punct de remarcat este faptul că aceste cadre abstrag multă complexitate, dar introduc și un mod obișnuit de a scrie cod. Vom cerceta în continuare compromisurile de performanță în acest articol.

De asemenea, vom face o analiză matrice pentru a înțelege relația dintre căile de randare și performanța site-ului. Dar înainte de asta, să trecem prin câteva elemente de bază ale măsurării performanței site-ului web.

Valori pentru performanța site-ului

Să examinăm câțiva dintre factorii pe care motoarele de căutare îi folosesc pentru a clasifica site-urile web.

În afară de a răspunde rapid și precis la întrebarea unui utilizator, Google consideră că un site web bun ar trebui să aibă următoarele atribute:

• Ar trebui să se încarce rapid.
• Utilizatorii ar trebui să poată accesa conținut fără prea mult timp de așteptare.
• Ar trebui să devină interactiv cu acțiunile unui utilizator din timp.
• Nu ar trebui să preia date inutile sau să execute cod scump pentru a preveni consumarea datelor sau a bateriei unui utilizator.

Aceste caracteristici se mapează aproximativ la următoarele valori:

• TTFB : Time to First Byte – Timpul dintre clic pe un link și primul bit de conținut care intră.
• LCP : Cea mai mare vopsea de conținut – Momentul în care articolul solicitat devine vizibil. Google recomandă menținerea acestei valori sub 2,5 secunde.
• TTI : Time To Interactive – Ora la care o pagină devine interactivă (un utilizator poate derula, face clic etc.).
• Dimensiunea pachetului – numărul total de octeți descărcați și codul executat înainte ca pagina să devină complet vizibilă și interactivă.

Vom revizui aceste valori pentru a înțelege mai bine modul în care diferitele căi de randare le pot afecta pe fiecare dintre ele.

În continuare, să înțelegem diferitele căi de randare disponibile pentru dezvoltatorii React.

Redare căi

Putem reda o aplicație React în browser sau pe server și să producem rezultate diferite.

Două funcții se schimbă semnificativ între aplicațiile randate pe partea client și pe server, și anume rutarea și împărțirea codului . Aruncăm o privire mai atentă la acestea mai jos.

Redare pe partea clientului (CSR)

Redarea pe partea client este calea de randare implicită pentru un SPA React. Serverul va servi o aplicație shell care nu conține niciun conținut. Odată ce browserul descarcă, analizează și execută sursele JavaScript incluse, conținutul HTML este populat sau redat .

Funcția de rutare este gestionată de aplicația client prin gestionarea istoricului browserului. Aceasta înseamnă că același fișier HTML este servit, indiferent de rută solicitată, iar clientul își actualizează starea de vizualizare după ce este redat.

Împărțirea codului este relativ simplă. Puteți împărți codul folosind importuri dinamice sau React.lazy, astfel încât numai dependențele necesare să fie încărcate pe baza rutei sau acțiunilor utilizatorului.

Dacă pagina trebuie să preia date de pe server pentru a reda conținut - de exemplu, un titlu de blog sau o descriere a produsului - poate face acest lucru numai atunci când componentele relevante sunt montate și redate.

Cel mai probabil, utilizatorul va vedea un semn sau un indicator „Se încarcă date” în timp ce site-ul web preia date suplimentare.

Redare pe partea clientului cu date bootstrapped (CSRB)

Luați în considerare același scenariu ca CSR, dar în loc să preluați date după ce DOM-ul este randat, să presupunem că serverul a trimis date relevante bootstrapped în HTML servit.

Am putea include un nod care arată cam așa:

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

Și analizați-l când se montează componenta:

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

Tocmai ne-am economisit o călătorie dus-întors la server. Vom vedea compromisurile peste puțin.

Redare pe partea de server la conținut static (SSRS)

Imaginați-vă un scenariu în care trebuie să generăm HTML din mers.

De exemplu, dacă construim un calculator online și utilizatorul lansează o interogare de tipul /calculate/34+15 (lăsând deoparte evadarea URL-ului). Trebuie să procesăm interogarea, să evaluăm rezultatul și să răspundem cu HTML generat.

HTML-ul nostru generat este destul de simplu ca structură și nu avem nevoie de React pentru a gestiona și manipula DOM-ul odată ce HTML-ul generat este servit.

Așa că oferim doar conținut HTML și CSS. Puteți utiliza metoda renderToStaticMarkup pentru a realiza acest lucru.

Rutarea va fi gestionată în întregime de server, deoarece trebuie să recalculeze HTML pentru fiecare rezultat, deși memorarea în cache CDN poate fi folosită pentru a furniza răspunsuri mai rapid. Fișierele CSS pot fi, de asemenea, stocate în cache de browser pentru încărcări mai rapide ale paginilor ulterioare.

Redare pe server cu rehidratare (SSRH)

Imaginați-vă același scenariu ca cel descris mai sus, dar de data aceasta avem nevoie de o aplicație React complet funcțională pe client.

Vom efectua prima randare pe server și vom trimite înapoi conținut HTML împreună cu fișierele JavaScript. React va rehidrata marcajul redat de server, iar aplicația se va comporta ca o aplicație CSR din acest moment.

React oferă metode încorporate pentru a efectua aceste acțiuni.

Prima cerere este gestionată de server, iar randările ulterioare sunt gestionate de client. Prin urmare, astfel de aplicații sunt numite aplicații React universale (redate atât pe server, cât și pe client). Codul pentru a gestiona rutarea poate fi divizat (sau duplicat) pe client și server.

Împărțirea codului este, de asemenea, puțin complicată, deoarece ReactDOMServer nu acceptă React. leneș, așa că poate fi necesar să utilizați ceva de genul Loadable Components.

De asemenea, trebuie remarcat faptul că ReactDOMServer efectuează doar o randare superficială. Cu alte cuvinte, deși metoda de randare pentru componentele dvs. va fi invocată, metodele ciclului de viață precum componentDidMount nu vor fi apelate. Deci, va trebui să refactorizați codul pentru a furniza date componentelor dvs. folosind o metodă alternativă.

Aici își fac apariția cadrele precum NextJS. Ele maschează complexitățile asociate cu rutarea și împărțirea codului în SSRH și oferă o experiență mai fluidă pentru dezvoltatori.

Această abordare dă rezultate mixte când vine vorba de performanța paginii, așa cum vom observa în curând.

Pre-randarea la conținut static (PRS)

Ce se întâmplă dacă am putea reda o pagină web înainte ca un utilizator să o solicite? Acest lucru se poate face în timpul construirii sau dinamic atunci când datele se modifică.

Apoi putem stoca în cache conținutul HTML rezultat pe un CDN și îl putem servi mult mai rapid atunci când un utilizator îl solicită.

Aceasta se numește pre-rendare înainte de a reda conținutul, cererea pre-utilizator. Această abordare poate fi utilizată pentru bloguri și aplicații de comerț electronic, deoarece conținutul acestora nu depinde de obicei de datele furnizate de utilizator.

Pre-rendare cu rehidratare (PRH)

Ne-am dori ca HTML-ul nostru pre-rendat să fie o aplicație React complet funcțională atunci când un client o redă.

După ce prima solicitare este servită, aplicația se va comporta ca o aplicație React standard. Acest mod este similar cu SSRH, descris mai sus, în ceea ce privește funcțiile de rutare și divizare a codului.

Matricea de performanță

Momentul pe care îl așteptați a sosit în sfârșit. E timpul pentru o confruntare. Să ne uităm la modul în care fiecare dintre aceste căi de randare afectează valorile de performanță web și să determinăm câștigătorul.

În această matrice, atribuim un scor fiecărei căi de randare în funcție de cât de bine se descurcă într-o măsurătoare de performanță.

Scorul variază de la 1 la 5:

• 1 = Nesatisfăcător
• 2 = Sărac
• 3 = Moderat
• 4 = Bun
• 5 = Excelent

Recomandări cheie

Pre-randarea la conținut static (PRS) duce la site-uri web cu cele mai înalte performanțe , în timp ce randarea pe server cu hidratare (SSRH) sau redarea pe partea client (CSR) poate duce la rezultate dezamăgitoare.

De asemenea, este posibil să adoptați mai multe abordări pentru diferite părți ale site-ului web . De exemplu, aceste valori de performanță pot fi critice pentru paginile web publice, astfel încât să poată fi indexate mai eficient, în timp ce pot conta mai puțin odată ce un utilizator s-a conectat și vede datele contului privat.

Fiecare cale de randare reprezintă compromisuri în ceea ce privește locul și modul în care doriți să vă procesați datele. Important este că o echipă de ingineri este capabilă să vadă clar și să discute aceste compromisuri și să aleagă o arhitectură care maximizează fericirea utilizatorilor lor.

Lectură suplimentară și considerații

Deși am încercat să acopăr tehnicile populare în prezent, aceasta nu este o analiză exhaustivă. Recomand cu căldură să citiți acest articol în care dezvoltatorii de la Google discută despre alte tehnici avansate, cum ar fi randarea serverului de streaming, randarea trisomorfă și randarea dinamică (care oferă răspunsuri diferite crawlerelor și utilizatorilor).

Alți factori pe care trebuie să îi luați în considerare atunci când construiți site-uri web cu conținut intens includ necesitatea unui sistem de management al conținutului (CMS) bun pentru autorii dvs. și capacitatea de a genera/modifica cu ușurință previzualizările rețelelor sociale și de a optimiza imaginile pentru diferite dimensiuni de ecran.