Kuna valida on nii paljude valikute vahel, on renderdamine teema, millega peate kursis hoidma.

Kaasaegsed veebiraamistikud pakuvad palju võimalusi saidi või rakenduse serverist kliendini edastamiseks. Saate luua HTML-i mõlemal küljel või eelrenderdada selle kiireks levitamiseks sisu edastamise võrgu kaudu.

Saidi või rakenduse ülesehituse otsustamine sõltub mitmest erinevast tegurist. Peate olema teadlik sellest, kuidas külastajad teie saidile või rakendusele juurde pääsevad. Peaksite aru saama, kas laadimiskiirus loeb rohkem alglaadimisel või järgneval navigeerimisel. Mõelge ka sellele, kui sageli saiti värskendate.

Pidage meeles kõiki neid tegureid, et kaaluda iga renderdamisparadigma plusse ja miinuseid.

Veebisaitide renderdamine mitmel viisil

Veebisaidi renderdamine viitab protsessile, mille käigus veebisait kuvatakse veebibrauseris. Toorandmete vormindatud HTML-i teisendamiseks kasutaja ekraanil on palju erinevaid viise.

Igal meetodil on oma plussid ja miinused ning igaühe eeliste ja puuduste tundmine aitab teil valida oma saidile sobivaima.

instagram viewer

CSR: brauser võtab vastutuse

CSR tähendab Client Side Rendering. Kui renderdate rakenduse või saidi kliendi poole, edastab server HTML-i vähe või üldse mitte, välja arvatud väike osa standardkoodist. Seejärel küsib leht pärast lehe laadimise sündmust AJAX-i päringute kaudu serverilt kõiki vajalikke andmeid.

Kui rakendus või leht renderdab kliendi poole, edastab server kliendile skripti, mis genereerib kliendi brauseris HTML-i. See võimaldab ühelehelisi rakendusi, mis ei värskenda brauserit, kui nendega suhtlete.

CSR-rakendused laaditakse navigeerimisel sageli kiiresti, kuid alguses võib nende laadimine olla aeglane. Kiirus sõltub suuresti renderdamiseks valitud raamistikust ning sellest, kui palju lisateeke ja lisandmooduleid kasutate. Enamik populaarsed kaasaegsed JavaScripti raamistikud sisaldama CSR-i valikut.

Täielikult kliendipoolsed renderdatud lehed ja rakendused ei suuda URL-i abil otse antud lehele navigeerida. Kui kliendipoolne renderdatud rakendus esmakordselt käivitub, liigub see olenemata sisestatud URL-ist samasse alguspunkti.

SSR: renderdamine keskserveris

SSR tähendab serveripoolset renderdamist. See on palju traditsioonilisem veebilehe renderdamise vorm, mille puhul saidid genereerivad mallide põhjal HTML-i ja saadavad kliendile HTML-i, stiilitabelite ja skriptide segu. Enamus kõige populaarsemad taustaveebiraamistikud kuuluvad sellesse kategooriasse.

Serveripoolsed renderdatud rakendused ja saidid laaditakse tavaliselt kiiremini, kuid iga järgnev navigeerimine nõuab täielikku värskendamist. See tähendab, et need ei võta mitte ainult kauem aega, vaid ka SSR-iga töötavad arendajad peavad seansi haldamisega arvestama.

SSR-i loodud saitide ja rakenduste suurim pluss on tee navigeerimise järjepidevus. Kasutaja, kes sisestab antud tee, suunatakse otse soovitud lehele. Mõned raamistikud haldavad kasutajate ümbersuunamisi rakenduses lehelt lehele, kuid kasutajad ei pruugi algselt soovitud lehele juurde pääseda.

Paljud kaasaegsed raamistikud pakuvad kombineeritud lahendusi, mis algavad serveris renderdatud lehe teenindamisest kliendile. Kui leht on laaditud, toimub hüdratatsioonina tuntud sündmus, mille käigus lisatakse lehe juhtelementidele kliendipoolsed skriptisündmused. Edaspidi tegeleb navigeerimisega klient.

Segatud dünaamika pakub kasutajatele võimalust minna otse rakenduse mis tahes lehele, säilitades samal ajal ühelehelise rakenduse kiiruse ja sujuvuse. Next.js pakub mitut renderdusparadigmat, nagu ka Nuxt.js ja Sveltekit.

SSG: minimeeritud renderdamine

SSG ehk staatiline saidi genereerimine möödub vajadusest genereerida HTML-i kliendi või serveri poolel. Selle asemel koostavad SSG-stiilis saidid ja rakendused kõik lehe, mida neil võib vaja minna, ning edastavad tulemused kiireks edastamiseks CDN-i.

See on äärmiselt tõhus meetod veebilehtede ülikiireks teenindamiseks. Tulemused koostatakse tavaliselt lihtsate pakettidena, mis sisaldavad kogu HTML-i ja laaditabeleid, mis on üksiku lehe jaoks vajalikud. Need komplektid on võimalikult kompaktsed, et kasutaja saaks need võimalikult kiiresti kätte.

SSG saidid pakuvad tavaliselt erakordselt kiiret laadimiskiirust, hoolimata sellest, et iga navigatsiooni jaoks on vaja värskendada. Staatilise saidi peamine negatiivne külg on aga paindlikkuse puudumine. Väga dünaamilised süsteemid, nagu sotsiaalmeedia rakendused või keerulised e-kaubanduse platvormid, nõuavad palju rohkem muudatusi, kui SSG hõlpsasti hakkama saab.

Paljud staatilised saidid nõuavad muutmiseks ka suuremat üldkulusid, kuna iga uus muudatus tuleb iseseisvalt kompileerida. See muudab SSG-stiilis renderdamise halvaks valikuks saitide jaoks, mis muutuvad kiiresti, näiteks kiiresti muutuva kaubavaru või sotsiaalmeediarakendustega digitaalne kauplus.

ISR: Natuke kõike

Kergesti kõige keerulisem, kuid ka kõige kasulikum renderdamise tüüp ISR tähistab järkjärgulist staatilist taastamist. ISR ühendab staatiliselt loodud saitide kiiruse ja skaleeritavuse SSR-i ja CSR-stiilis rakenduste reaktsioonivõimega.

Kui ISR-tüüpi lehel või rakenduses taotletakse mõnda lehte, kontrollib server esmalt, kas lehe vahemällu salvestatud versioon on aegunud. Kui see on olemas, teenindab server kohe vahemällu salvestatud lehte.

Kui lehe vahemällu salvestatud versiooni pole olemas või selle loomisest on möödunud piisavalt aega, loob server uue versiooni. See uus versioon edastatakse kliendile ja salvestatakse vahemällu edaspidiseks kasutamiseks.

Seda tüüpi renderdamist on keerulisem seadistada, kuid see automatiseerib enamiku probleemidest, mida SSG-saidid tavaliselt kogevad. See võimaldab rakendustel pakkuda nii staatiliselt loodud rakenduse kiirust kui ka töökindlust, automatiseerides samal ajal lisakulud.

Mitmed kaasaegsed raamistikud pakuvad juba ISR-stiilis renderdamise võimalust. Paljudel teistel on arendusjärgus põlvkonna toetamine. Enamik suuremaid raamistikke toetab varsti ISR-i renderdamist, kui nad seda juba ei tee.

Milline renderdustüüp on parim?

Veebisaidi või rakenduse renderdamiseks on mitu võimalust. Kõigil neil neljal renderdustüübil on mitu variatsiooni. Ükski renderdustüüp ei sobi kõigi projektide jaoks ideaalselt ja see, millise tüübi valite, sõltub sellest, mis on teie saidil või rakenduses kõige olulisem.

Projekti jaoks renderdamisparadigma valimisel on oluline arvestada kiirusega, sellega, kuidas teie publik teie projekti kasutab ja kui sageli sait muutub. Need on peamised põhimõtted, mis aitavad teil otsustada, milline on parim viis oma saidi või rakenduse struktureerimiseks.