Greitesnis tinklalapio įkėlimo laikas turi didelę reikšmę naudotojų patirčiai ir SEO, o puslapio įkėlimo greitis yra pagrindinis „Google“ algoritmo veiksnys.
Paprastas žiniatinklio kūrėjas turi nuspręsti, kaip geriausia pateikti svetainę, kad ji teiktų greitą patirtį ir dinamišką turinį.
Du populiarūs atvaizdavimo metodai yra kliento pusės atvaizdavimas (CSR) ir serverio atvaizdavimas (SSR).
Visoms svetainėms keliami skirtingi reikalavimai, todėl suprasdami skirtumą tarp kliento ir serverio pusės atvaizdavimo galite padaryti svetainę taip, kad ji atitiktų jūsų verslo tikslus.
Google ir JavaScript
„Google“ turi daug dokumentų, kaip tvarko „JavaScript“, o „Google“ darbuotojai įvairiais formatais – tiek oficialiais, tiek neoficialiais – pateikia įžvalgų ir reguliariai atsako į „JavaScript“ klausimus.
Pavyzdžiui, „Search Off The Record“ podcast'e buvo aptarta, kad „Google“ paieškai pateikia visus puslapius, įskaitant tuos, kuriuose daug „JavaScript“.
Tai sukėlė didelį pokalbį „LinkedIn“, o dar pora podcast'o ir vykstančių diskusijų ištraukų yra šie:
- „Google“ neseka, kiek kainuoja pateikti konkrečius puslapius.
- „Google“ pateikia visus puslapius, kad matytų turinį, nesvarbu, ar ji naudoja „JavaScript“, ar ne.
Visas pokalbis padėjo išsklaidyti daugybę mitų ir klaidingų nuomonių apie tai, kaip „Google“. galėjo turėti priartėjo prie JavaScript ir skyrė išteklių.
Visas Martino Splitto komentaras apie tai „LinkedIn“ buvo toks:
„Mes nesekame „kiek brangus mums kainavo šis puslapis? ar kažkas. Žinome, kad didelė žiniatinklio dalis naudoja „JavaScript“ tinklalapių turiniui pridėti, pašalinti, keisti. Mes tiesiog turime perteikti, pamatyti viską. Nesvarbu, ar puslapis naudoja „JavaScript“, ar ne, nes galime būti tikri, kad visą turinį pamatysime tik tada, kai jis bus pateiktas.
Martinas taip pat patvirtino eilę ir galimą delsą tarp tikrinimo ir indeksavimo, bet ne tik todėl, kad kažkas yra „JavaScript“, ar ne, ir nėra „nematoma“ problema, kad „JavaScript“ buvimas yra pagrindinė URL neindeksavimo priežastis.
Bendra „JavaScript“ geriausia praktika
Prieš pradedant diskusiją kliento ir serverio pusėje, svarbu, kad taip pat vadovautumėmės bendrosios geriausios praktikos pavyzdžiais, kad vienas iš šių būdų veiktų:
- Neblokuokite „JavaScript“ išteklių naudodami Robots.txt arba serverio taisykles.
- Venkite atvaizdavimo blokavimo.
- Venkite įvesti JavaScript į DOM.
Kas yra kliento pusės atvaizdavimas ir kaip jis veikia?
Kliento pusės atvaizdavimas yra palyginti naujas svetainių pateikimo būdas.
Jis išpopuliarėjo, kai „JavaScript“ bibliotekos pradėjo jį integruoti, o „Angular“ ir „React.js“ yra vieni geriausių bibliotekų, naudojamų tokio tipo atvaizdavimui, pavyzdžių.
Jis veikia pateikdamas svetainės JavaScript naršyklėje, o ne serveryje.
Serveris atsako pateikdamas atvirą HTML dokumentą, kuriame yra JS failai, užuot gavęs visą turinį iš HTML dokumento.
Nors pradinis įkėlimo laikas yra šiek tiek lėtas, vėlesni puslapių įkėlimai bus greiti, nes jie nepriklauso nuo kito maršruto HTML puslapio.
Nuo logikos valdymo iki duomenų gavimo iš API – klientų pateiktos svetainės viską daro „nepriklausomai“. Puslapis pasiekiamas įvykdžius kodą, nes kiekvienas puslapis, kuriame lankosi vartotojas, ir atitinkamas URL yra sukuriami dinamiškai.
CSR procesas yra toks:
- Vartotojas adreso juostoje įveda URL, kurį nori aplankyti.
- Duomenų užklausa siunčiama serveriui nurodytu URL.
- Pirmą kartą klientui paprašius svetainės, serveris pateikia statinius failus (CSS ir HTML) į kliento naršyklę.
- Kliento naršyklė pirmiausia atsisiųs HTML turinį, o po to „JavaScript“. Šie HTML failai sujungia „JavaScript“, pradėdami įkėlimo procesą, rodydami įkėlimo simbolius, kuriuos kūrėjas apibrėžia vartotojui. Šiame etape svetainė vis dar nėra matoma vartotojui.
- Atsisiuntus JavaScript, turinys dinamiškai generuojamas kliento naršyklėje.
- Žiniatinklio turinys tampa matomas, kai klientas naršo ir sąveikauja su svetaine.
Kas yra serverio atvaizdavimas ir kaip jis veikia?
Serverio pusės atvaizdavimas yra labiau paplitęs informacijos rodymo ekrane metodas.
Žiniatinklio naršyklė pateikia užklausą dėl informacijos iš serverio, gaudama konkretaus vartotojo duomenis, kuriuos reikia užpildyti, ir siunčia klientui visiškai pateiktą HTML puslapį.
Kiekvieną kartą vartotojui apsilankius naujame svetainės puslapyje, serveris pakartos visą procesą.
Štai kaip SSR procesas vyksta žingsnis po žingsnio:
- Vartotojas adreso juostoje įveda URL, kurį nori aplankyti.
- Serveris pateikia paruoštą pateikti HTML atsakymą į naršyklę.
- Naršyklė pateikia puslapį (dabar galima peržiūrėti) ir atsisiunčia „JavaScript“.
- Naršyklė vykdo React, todėl puslapis tampa sąveikus.
Kuo skiriasi kliento ir serverio atvaizdavimas?
Pagrindinis skirtumas tarp šių dviejų atvaizdavimo metodų yra jų veikimo algoritmai. CSR rodo tuščią puslapį prieš įkeliant, o SSR rodo visiškai pateiktą HTML puslapį pirmą kartą įkeliant.
Tai suteikia serverio pusės atvaizdavimo greičio pranašumą, palyginti su atvaizdavimu kliento pusėje, nes naršyklei nereikia apdoroti didelių „JavaScript“ failų. Turinys dažnai matomas per porą milisekundžių.
Paieškos sistemos gali tikrinti svetainę, kad būtų geresnis SEO, todėl būtų lengva indeksuoti tinklalapius. Šis teksto skaitomumas yra būtent toks, kaip SSR svetainės rodomos naršyklėje.
Tačiau atvaizdavimas kliento pusėje yra pigesnis pasirinkimas svetainių savininkams.
Tai sumažina jūsų serverių apkrovą, o atsakomybė už pateikimą perduodama klientui (rotui arba vartotojui, bandančiam peržiūrėti jūsų puslapį). Ji taip pat siūlo turtingą sąveiką su svetaine, užtikrindama greitą sąveiką su svetaine po pradinio įkėlimo.
Mažiau HTTP užklausų pateikiama serveriui naudojant CSR, skirtingai nei SSR, kai kiekvienas puslapis atvaizduojamas nuo nulio, todėl perėjimas tarp puslapių yra lėtesnis.
SSR taip pat gali susilpnėti esant didelei serverio apkrovai, jei serveris vienu metu gauna daug užklausų iš skirtingų vartotojų.
CSR trūkumas yra ilgesnis pradinio įkėlimo laikas. Tai gali turėti įtakos SEO; tikrinimo programos gali nelaukti, kol turinys bus įkeltas ir išeis iš svetainės.
Šis dviejų etapų metodas padidina galimybę savo puslapyje matyti tuščią turinį, nes pirmą kartą patikrinus ir indeksavus puslapio HTML, trūksta „JavaScript“ turinio. Atminkite, kad daugeliu atvejų CSR reikalinga išorinė biblioteka.
Kada naudoti serverio atvaizdavimą
Jei norite pagerinti savo „Google“ matomumą ir užimti aukštą vietą paieškos sistemos rezultatų puslapiuose (SERP), serverio atvaizdavimas yra pirmasis pasirinkimas.
El. mokymosi svetainės, internetinės prekyvietės ir programos su paprasta vartotojo sąsaja su mažiau puslapių, funkcijų ir dinaminių duomenų – visa tai naudinga šio tipo atvaizdavimui.
Kada naudoti kliento pusės atvaizdavimą
Kliento pusės atvaizdavimas paprastai suporuojamas su dinamiškomis žiniatinklio programomis, pvz., socialiniais tinklais ar internetiniais pasiuntiniais. Taip yra todėl, kad šių programų informacija nuolat keičiasi ir turi apdoroti didelius ir dinamiškus duomenis, kad būtų galima greitai atnaujinti, kad atitiktų vartotojų poreikius.
Čia dėmesys sutelkiamas į turtingą svetainę, kurioje yra daug vartotojų, pirmenybę teikiant naudotojų patirčiai, o ne SEO.
Kas geriau: serverio ar kliento pusės atvaizdavimas?
Nustatydami, kuris metodas yra geriausias, turite ne tik atsižvelgti į savo SEO poreikius, bet ir į tai, kaip svetainė veikia vartotojams ir teikia vertę.
Pagalvokite apie savo projektą ir kaip jūsų pasirinktas atvaizdavimas paveiks jūsų poziciją SERP ir jūsų svetainės naudotojų patirtį.
Paprastai CSR geriau tinka dinamiškoms svetainėms, o SSR geriausiai tinka statinėms svetainėms.
Turinio atnaujinimo dažnis
Svetainės, kuriose pateikiama labai dinamiška informacija, pvz., lošimų ar FOREX svetainės, atnaujina savo turinį kas sekundę, o tai reiškia, kad šiuo atveju greičiausiai pasirinktumėte CSR, o ne SSR arba pasirinktumėte naudoti CSR konkretiems nukreipimo puslapiams, o ne visiems puslapiams, atsižvelgiant į jūsų vartotojų įgijimo strategija.
SSR yra efektyvesnis, jei jūsų svetainės turiniui nereikia daug naudotojo sąveikos. Tai teigiamai veikia prieinamumą, puslapio įkėlimo laiką, SEO ir socialinės žiniasklaidos palaikymą.
Kita vertus, CSR puikiai tinka ekonomiškai efektyviam žiniatinklio programų atvaizdavimui, ją lengviau kurti ir prižiūrėti; tai geriau pirmosios įvesties delsai (FID).
Kitas CSR aspektas yra tas, kad metažymos (aprašas, pavadinimas), kanoniniai URL ir „Hreflang“ žymos turėtų būti pateikiamos serverio pusėje arba pateikiamos pradiniame HTML atsakyme, kad tikrinimo programos galėtų kuo greičiau jas identifikuoti, o ne tik rodomose HTML.
Platformos svarstymai
CSR technologijos priežiūra paprastai yra brangesnė, nes React.js arba Node.js programuotojų valandinis įkainis paprastai yra didesnis nei PHP ar WordPress kūrėjų.
Be to, CSR sistemoms yra mažiau paruoštų papildinių arba paruoštų sprendimų, palyginti su didesne papildinių ekosistema, kurią turi ir „WordPress“ vartotojai.
Tiems, kurie galvoja apie begalvę „WordPress“ sąranką, pvz., „Fronity“ naudojimą, svarbu atkreipti dėmesį, kad turėsite samdyti ir React.js kūrėjus, ir PHP kūrėjus.
Taip yra todėl, kad begalvis „WordPress“ priekinėje dalyje remiasi React.js, o galinėje dalyje vis tiek reikalauja PHP.
Svarbu atsiminti, kad ne visi „WordPress“ papildiniai yra suderinami su sąrankomis be galvos, todėl gali būti apribotas funkcionalumas arba reikalingas papildomas pritaikytas kūrimas.
Svetainės funkcionalumas ir paskirtis
Kartais jums nereikia rinktis iš dviejų, nes yra hibridinių sprendimų. Tiek SSR, tiek CSR gali būti įdiegtos vienoje svetainėje arba tinklalapyje.
Pavyzdžiui, internetinėje prekyvietėje puslapiai su produktų aprašymais gali būti pateikiami serveryje, nes jie yra statiški ir turi būti lengvai indeksuojami paieškos sistemų.
Pasiliekant el. prekybą, jei daugelio puslapių naudotojai yra labai suasmeninti, negalėsite SSR pateikti turinio robotams, todėl turėsite apibrėžti tam tikrą numatytąjį „Googlebot“ turinį, kuris tikrina be slapukų ir be pilietybės.
Tokių puslapių kaip naudotojų paskyros nebūtina reitinguoti paieškos variklio rezultatų puslapiuose (SERP), todėl UX gali būti geresnis CRS metodas.
Tiek CSR, tiek SSR yra populiarūs svetainių pateikimo būdai. Jūs ir jūsų komanda turite priimti šį sprendimą pradiniame produkto kūrimo etape.
Daugiau išteklių:
Teminis vaizdas: TippaPatt/Shutterstock



