Tā kā ir tik daudz iespēju, no kurām izvēlēties, renderēšana ir tēma, kas jums jāturpina.
Mūsdienu tīmekļa ietvari piedāvā daudzas iespējas, kā vietni vai lietotni piegādāt no servera uz klientu. Varat ģenerēt HTML abās pusēs vai iepriekš atveidot to liela ātruma izplatīšanai, izmantojot satura piegādes tīklu.
Lēmums par vietnes vai lietotnes strukturēšanu ir atkarīgs no dažiem dažādiem faktoriem. Jums ir jāzina, kā apmeklētāji piekļūs jūsu vietnei vai lietotnei. Jums vajadzētu saprast, vai ielādes ātrumam ir lielāka nozīme sākotnējās ielādes vai turpmākās navigācijas laikā. Apsveriet arī to, cik bieži atjaunināsit vietni.
Ņemiet vērā visus šos faktorus, lai izsvērtu katras renderēšanas paradigmas plusus un mīnusus.
Vietņu renderēšana vairākos veidos
Vietnes renderēšana attiecas uz procesu, kurā vietne tiek parādīta tīmekļa pārlūkprogrammā. Ir daudz dažādu veidu, kā lietotāja ekrānā veikt neapstrādātu datu konvertēšanu uz formatētu HTML.
Katrai metodei ir savi plusi un mīnusi, un, zinot katras metodes priekšrocības un trūkumus, varat izvēlēties savai vietnei piemērotāko.
CSR: Pārlūkprogramma uzņemas atbildību
CSR nozīmē klienta puses renderēšana. Kad renderējat lietotnes vai vietnes klienta pusi, serveris nodod maz vai vispār nenodod HTML, izņemot nelielu standarta koda fragmentu. Pēc tam lapa pēc lapas ielādes notikuma no servera pieprasa visus tai nepieciešamos datus, izmantojot AJAX pieprasījumus.
Kad lietotne vai lapa atveido klienta pusi, serveris klientam nodod skriptu, kas ģenerēs HTML klienta pārlūkprogrammā. Tas ļauj izmantot vienas lapas lietojumprogrammas, kas neatsvaidzina pārlūkprogrammu, kad ar tām mijiedarbojaties.
CSR lietotnes bieži tiek ātri ielādētas navigācijā, taču sākotnēji tās var būt lēnas. Ātrums lielā mērā būs atkarīgs no ietvara, kuru izvēlaties renderēšanai, un no tā, cik papildu bibliotēku un papildinājumu izmantojat. Lielākā daļa populāri mūsdienu JavaScript ietvari iekļaut CSR opciju.
Pilnībā klienta puses renderētās lapas un lietotnes cieš no nespējas tieši pārvietoties uz noteiktu lapu, izmantojot URL. Kad klienta puses renderētā lietotne pirmo reizi tiek startēta, neatkarīgi no ievadītā URL tā tiks virzīta uz to pašu sākumpunktu.
SSR: renderēšana uz centrālā servera
SSR nozīmē servera puses renderēšana. Šis ir daudz tradicionālāks tīmekļa lapu renderēšanas veids, kurā vietnes ģenerē HTML, pamatojoties uz veidnēm, un nosūta klientam HTML, stila lapu un skriptu maisījumu. Lielākā daļa no populārākās aizmugursistēmas tīmekļa ietvarus ietilpst šajā kategorijā.
Servera puses renderētās lietotnes un vietnes parasti tiek ielādētas ātrāk, taču katrai nākamajai navigācijai būs nepieciešama pilnīga atsvaidzināšana. Tas nozīmē, ka tas ne tikai prasīs ilgāku laiku, bet arī izstrādātājiem, kas strādā ar SSR, būs jāņem vērā sesiju pārvaldība.
SSR radīto vietņu un lietotņu lielākā priekšrocība ir ceļu navigācijas konsekvence. Lietotājs, kurš ievadīs noteiktu ceļu, tiks novirzīts tieši uz pieprasīto lapu. Daži ietvari pārvalda lietotāju novirzīšanu no lietotnes lapas uz lapu, taču lietotāji, iespējams, sākotnēji nevarēs piekļūt vajadzīgajai lapai.
Daudzas mūsdienu sistēmas piedāvā jauktus risinājumus, kas sākas ar servera renderētas lapas apkalpošanu klientam. Kad lapa ir ielādēta, notiek notikums, kas pazīstams kā hidratācija, kurā klienta puses skripta notikumi tiek pievienoti lapas vadīklām. Turpmāk klients apstrādā jebkuru navigāciju.
Jauktā dinamika piedāvā lietotājiem iespēju pāriet tieši uz jebkuru lietotnes lapu, vienlaikus saglabājot vienas lapas lietojumprogrammas ātrumu un vienmērīgumu. Next.js piedāvā vairākas renderēšanas paradigmas, tāpat kā Nuxt.js un Sveltekit.
SSG: Minimizēta renderēšana
SSG jeb Static Site Generation apiet nepieciešamību ģenerēt HTML klienta vai servera pusē. Tā vietā SSG stila vietnes un lietotnes iepriekš apkopo katru lapu, kas tām varētu būt nepieciešama, un nosūta rezultātus uz CDN ātrai piegādei.
Šī ir ārkārtīgi efektīva metode tīmekļa lapu ārkārtīgi ātrai apkalpošanai. Rezultāti parasti tiek apkopoti vienkāršos komplektos, kas satur visu HTML un stilu lapas, kas nepieciešamas atsevišķai lapai. Šie komplekti tiek turēti pēc iespējas kompaktāki, lai nodrošinātu, ka lietotājs tos saņems pēc iespējas ātrāk.
SSG vietnes mēdz piedāvāt ārkārtīgi lielu ielādes ātrumu, neskatoties uz to, ka katrai navigācijai ir nepieciešama atsvaidzināšana. Tomēr galvenais statiskās vietnes trūkums ir elastības trūkums. Ļoti dinamiskām sistēmām, piemēram, sociālo mediju lietotnēm vai sarežģītām e-komercijas platformām, būs nepieciešams daudz vairāk izmaiņu, nekā SSG var viegli apstrādāt.
Daudzu statisku vietņu mainīšanai būs nepieciešamas arī lielākas pieskaitāmās izmaksas, jo katras jaunas izmaiņas būs jāapkopo neatkarīgi. Tas padara SSG stila renderēšanu par sliktu izvēli vietnēm, kas strauji mainās, piemēram, digitālā veikala mājaslapa ar strauji mainīgiem krājumiem vai sociālo mediju lietotnēm.
ISR: mazliet no visa
Viegli vissarežģītākais, bet arī visizdevīgākais renderēšanas veids ISR nozīmē pakāpenisku statisko atjaunošanu. ISR apvieno statiski ģenerētu vietņu ātrumu un mērogojamību ar SSR un CSR stila lietotņu reaktivitāti.
Ja kāda lapa tiek pieprasīta ISR stila lapā vai lietotnē, serveris vispirms pārbaudīs, vai nav kešatmiņā saglabātas lapas versijas, kuras derīguma termiņš nav beidzies. Ja ir, serveris nekavējoties apkalpos kešatmiņā saglabāto lapu.
Ja lapas kešatmiņā saglabātā versija nepastāv vai kopš tās ģenerēšanas ir pagājis pietiekami daudz laika, serveris ģenerēs jaunu versiju. Šī jaunā versija tiks nodota klientam un saglabāta kešatmiņā turpmākai lietošanai.
Šāda veida renderēšanu ir sarežģītāk iestatīt, taču tas automatizē lielāko daļu problēmu, ar kurām parasti saskaras SSG vietnes. Tas ļauj lietotnēm piedāvāt gan statiski ģenerētas lietotnes ātrumu, gan uzticamību, vienlaikus automatizējot papildu izmaksas.
Vairāki mūsdienīgi ietvari jau piedāvā ISR stila renderēšanas iespēju. Daudzām citām ir atbalsts pakāpeniskai paaudzei attīstībā. Lielākā daļa galveno ietvaru drīzumā atbalstīs ISR renderēšanu, ja vēl ne.
Kurš renderēšanas veids ir labākais?
Ir vairāki veidi, kā renderēt vietni vai lietotni. Katram no šiem četriem renderēšanas veidiem ir vairākas variācijas. Neviens renderēšanas veids nav ideāls visiem projektiem, un izvēlētais veids būs atkarīgs no tā, kas ir vissvarīgākais jūsu vietnē vai lietotnē.
Izvēloties savam projektam renderēšanas paradigmu, ir svarīgi ņemt vērā ātrumu, to, kā auditorija izmantos jūsu projektu un cik bieži vietne mainīsies. Šie būs galvenie principi, kas palīdzēs jums izlemt, kā vislabāk strukturēt vietni vai lietotni.