Beneficiile randarii dinamice pentru SEO

Cadrele JavaScript au crescut în popularitate în ultimii ani, datorită în mare măsură flexibilității pe care o oferă. „Cadrele JavaScript permit o dezvoltare rapidă. Oferă o experiență mai bună pentru utilizator. Oferă performanțe mai bune și oferă funcționalități îmbunătățite de care cadrele tradiționale — cele non-JavaScript — cam lipsesc”, a spus Nati Elimelech, tech SEO lead la Wix.

„Deci, nu este surprinzător faptul că site-urile web foarte mari sau interfețele de utilizator complexe cu o logică și caracteristici complexe tind de obicei să utilizeze cadre JavaScript în zilele noastre”, a adăugat el.

La SMX Next, Elimelech a oferit o privire de ansamblu asupra modului în care funcționează JavaScript pentru randarea pe partea client, pe partea serverului și dinamică și a împărtășit informații despre auditare obținute din redarea JavaScript pe peste 200 de milioane de site-uri web.

Redare pe partea client vs. pe partea serverului

Diferite metode de randare sunt potrivite pentru scopuri diferite. Elimelech a susținut randarea dinamică ca un mijloc de a satisface roboții și utilizatorii motoarelor de căutare deopotrivă, dar mai întâi, este necesar să înțelegem cum funcționează randarea pe partea client și pe partea serverului.

Redare pe partea clientului

Când un utilizator face clic pe un link, browserul său trimite solicitări către serverul pe care este găzduit site-ul.

„Când vorbim despre framework-uri JavaScript, acel server răspunde cu ceva care este puțin diferit de ceea ce ne-am obișnuit”, a spus Elimelech.

„Răspunde cu un HTML schelet – doar HTML de bază, dar cu mult JavaScript. Practic, ceea ce face este să spună browserului meu să ruleze JavaScript în sine pentru a obține tot codul HTML important”, a spus el, adăugând că browserul utilizatorului produce apoi HTML redat (HTML final care este folosit pentru a construi pagina în modul în care noi chiar o vezi). Acest proces este cunoscut sub numele de randare pe partea clientului.

„Este foarte asemănător cu asamblarea propriei mobilier, deoarece, practic, serverul îi spune browserului: „Hei, acestea sunt toate piesele, acestea sunt instrucțiunile, construiește pagina. Am încredere în tine.' Și asta înseamnă că toate sarcinile sunt mutate în browser în loc de server”, a spus Elimelech.

Redarea pe partea clientului poate fi excelentă pentru utilizatori, dar există cazuri în care un client nu execută JavaScript, ceea ce înseamnă că nu va primi întregul conținut al paginii dvs. Un astfel de exemplu poate fi crawlerele motoarelor de căutare; deși Googlebot poate vedea acum mai mult din conținutul tău decât oricând, există încă limitări.

Redare pe partea serverului

Pentru clienții care nu execută JavaScript, poate fi utilizată redarea pe partea serverului.

„Randarea pe partea serverului este atunci când tot acel JavaScript este executat pe partea serverului. Toate resursele sunt necesare pe partea serverului, iar browserul dvs. și botul motorului de căutare nu trebuie să execute JavaScript pentru a obține codul HTML redat complet”, a explicat Elimelech. Aceasta înseamnă că randarea pe server poate fi mai rapidă și mai puțin consumatoare de resurse pentru browsere.

„Redarea pe partea serverului este ca și cum le-ați oferi oaspeților un scaun real pe care să-l așeze, în loc să fie nevoiți să-l asambleze”, a spus el, continuând analogia anterioară. „Și, atunci când faceți randare pe server, practic vă faceți HTML vizibil pentru tot felul de roboți, pentru tot felul de clienți. . . Nu contează care sunt capabilitățile JavaScript, acesta poate vedea HTML redat important final”, a adăugat el.

Redare dinamică

Redarea dinamică reprezintă „cel mai bun din ambele lumi”, a spus Elimelech. Redarea dinamică înseamnă „comutația între conținutul redat pe partea clientului și conținutul pre-ratat pentru agenți de utilizator specifici”, potrivit Google.

Mai jos este o diagramă simplificată care explică cum funcționează randarea dinamică pentru diferiți agenți utilizatori (utilizatori și roboți).

”Deci, există o solicitare către URL, dar de data aceasta verificăm: Cunoaștem acest agent de utilizator? Acesta este un bot cunoscut? Este Google? Este Bing? Este Semrush? Este ceva despre care știm? Dacă nu este, presupunem că este un utilizator și apoi facem randare pe partea clientului”, a spus Elimelech.

În acest caz, browserul utilizatorului rulează JavaScript pentru a obține codul HTML randat, dar beneficiază în continuare de avantajele redării pe partea clientului, care include adesea o creștere percepută a vitezei.

Pe de altă parte, dacă clientul este un bot, atunci randarea pe server este utilizată pentru a servi HTML-ul complet randat. „Deci, vede tot ce trebuie văzut”, a spus Elimelech.

Acesta reprezintă „cel mai bun din ambele lumi”, deoarece proprietarii de site-uri sunt în continuare capabili să-și difuzeze conținutul, indiferent de capabilitățile JavaScript ale clientului. Și, deoarece există două fluxuri, proprietarii de site-uri le pot optimiza pe fiecare pentru a servi mai bine utilizatorii sau roboții fără a-l afecta pe celălalt.

Dar, randarea dinamică nu este perfectă

Există, totuși, complicații asociate redării dinamice. „Avem două fluxuri de menținut, două seturi de logici, caching, alte sisteme complexe; deci este mai complex când ai două sisteme în loc de unul”, a spus Elimelech, menționând că proprietarii de site-uri trebuie să mențină și o listă de agenți utilizatori pentru a identifica roboții.

Unii s-ar putea îngrijora că oferirea unor roboți ai motoarelor de căutare cu ceva diferit față de ceea ce le arătați utilizatorilor poate fi considerată descuiat.

„Randarea dinamică este de fapt o soluție preferată și recomandată de Google, deoarece ceea ce îi pasă lui Google este dacă lucrurile importante sunt aceleași [între cele două versiuni]”, a spus Elimelech, adăugând că „„Lucrurile importante” sunt lucrurile la care ne pasă. ca SEO: conținutul, titlurile, metaetichetele, legăturile interne, linkurile de navigare, roboții, titlul, marcarea datelor canonice, structurate, conținutul, imaginile - tot ceea ce are de-a face cu modul în care un bot ar reacționa la pagină . . . este important să păstrați identice și atunci când le păstrați identice, în special conținutul și mai ales metaetichetele, Google nu are nicio problemă cu asta.”

Deoarece este necesar să se mențină paritatea între ceea ce oferiți roboților și ceea ce serviți utilizatorilor, este, de asemenea, necesar să verificați problemele care ar putea rupe acea paritate.

Pentru a verifica eventualele probleme, Elimelech recomandă Screaming Frog sau un instrument similar care vă permite să comparați două crawl-uri. „Deci, ceea ce ne place să facem este să accesăm cu crawlere un site web ca Googlebot (sau un alt agent de utilizator al motorului de căutare) și să îl accesăm cu crawlere ca utilizator și să ne asigurăm că nu există diferențe”, a spus el. Compararea elementelor adecvate dintre cele două accesări cu crawlere vă poate ajuta să identificați potențialele probleme.

Elimelech a menționat, de asemenea, următoarele metode pentru a detecta probleme:

• Inspecție vizuală prin comutarea agentului utilizator în browser și/sau dezactivarea JavaScript pentru a vedea dacă ceva se schimbă între versiuni.
• Google Search Console poate fi folosit pentru a vedea ce fel de HTML este returnat la Google și cum îl poate reda.
• Instrumente de testare, cum ar fi testul Google pentru dispozitive mobile, testul cu rezultate bogate și instrumentul Schema.org de validare a marcajului de schemă (fost instrument de testare a datelor structurate).

„Amintiți-vă, cadrele JavaScript nu merg nicăieri”, a spus el. „Șansele sunt să întâlnești unul dintre ei în curând, așa că ar fi bine să fii pregătit să-i faci față.”

Urmăriți prezentarea completă SMX Next aici (este necesară înregistrarea gratuită).

Opiniile exprimate în acest articol sunt cele ale autorului invitat și nu neapărat Search Engine Land. Autorii personalului sunt enumerați aici.