Kur një biznes më kërkon një faqe interneti, para dizajnit ka një zgjedhje që peshon për vite: faqe statike, rendering në server (SSR) apo CMS? Në vend që ta shpjegoj në abstrakt, e tregoj me projektin që njoh më mirë: këtë faqe.
Tri opsionet me dy rreshta
- Faqe statike: faqet janë skedarë HTML të gatshëm, të gjeneruar një herë dhe të ngarkuar në një hosting. Shumë e shpejtë, e lirë, shumë e vështirë për t'u sulmuar. Por çdo ndryshim kërkon një publikim të ri.
- SSR (server-side rendering): një server e gjeneron faqen në çdo kërkesë, me të dhëna gjithmonë të përditësuara. Fleksibël dhe shumë i mirë për SEO, por duhet një server gjithmonë i ndezur dhe dikush që ta mirëmbajë.
- CMS (WordPress ose një CMS headless): pronari i ndryshon tekstet dhe artikujt nga një panel, pa zhvillues. I rehatshëm, por sjell përditësime, plugin-e dhe një sipërfaqe sulmi për t'u kujdesur.
Rasti im: një faqe Angular e publikuar si statike
Kjo faqe është një aplikacion Angular me SSR të konfiguruar, një backend NestJS të veçantë me MongoDB dhe një blog në shtatë gjuhë, artikujt e të cilit ruhen në databazë. Në letër është rasti ideal për SSR. Në praktikë, për kosto dhe thjeshtësi, frontend-i kompilohet dhe publikohet si skedarë statikë në një hosting Plesk, ndërsa backend-i punon në një shërbim të veçantë.
Funksionon, por e zbulova me lëkurën time se çfarë sjell ajo zgjedhje.
1. Pa server, SSR nuk ekziston
Me një deploy statik, rendering-u në server nuk ekzekutohet kurrë: nëse një faqe nuk gjenerohet gjatë build-it, Google merr vetëm "guaskën" bosh të aplikacionit. Kur e vura re, nga 32 URL në sitemap Google kishte indeksuar 4, dhe asnjë artikull: të gjithë hetimin e kam treguar në këtë artikull. Zgjidhja ishte prerendering-u: gjenerimi i HTML-së së çdo faqeje gjatë build-it, artikull pas artikulli dhe gjuhë pas gjuhe.
2. Qindra faqe për t'u gjeneruar në çdo build
Çdo artikull ekziston në shtatë gjuhë, ndaj faqet për t'u prerenderizuar janë qindra. Build-et e para pyesnin API-n e prodhimit për secilën: kufiri i kërkesave aktivizohej dhe disa faqe gjeneroheshin me mesazhin "artikulli nuk u gjet". E zgjidha duke shkarkuar të gjithë artikujt një herë të vetme para build-it, në një skedar cache nga i cili lexon prerendering-u:
// Before the build: download every published post once
const posts = await fetchAllPublishedPosts();
fs.writeFileSync('.prerender-cache/blog-posts.json', JSON.stringify({ posts }));
// The prerender reads this file instead of calling the API hundreds of times3. Çdo artikull i ri kërkon një publikim të ri
Ky është kompromisi më i dukshëm: kur publikoj një artikull nga paneli, përmbajtja është menjëherë e disponueshme përmes API-t, por faqja HTML që lexon Google ekziston vetëm pas build-it të radhës dhe ngarkimit të skedarëve. Për një blog që përditësohet herë pas here është e pranueshme; për një faqe lajmesh jo.
4. Detajet e hostingut kanë rëndësi
Edhe me faqet e gjeneruara, Apache përgjigjej me një redirect 301 për secilën: çdo faqe e prerenderizuar është një dosje me një index.html brenda, dhe serveri i shtonte URL-së slash-in përfundimtar. Rregullimi ishte disa rreshta në .htaccess, por pa një kontroll me curl -I nuk do ta kisha vënë re kurrë:
<IfModule mod_dir.c>
DirectorySlash Off
</IfModule>Pikërisht për shkak të këtyre kompromiseve po përgatis kalimin në një container Node në Plesk, me SSR të vërtetë: kompleksiteti ishte tashmë në projekt, aq më mirë ta shfrytëzoj plotësisht.
Çfarë i rekomandoj një biznesi të vogël
Faqja ime nuk është rast tipik: është edhe një laborator. Për një biznes real, zgjedhja varet pothuajse gjithmonë nga tri pyetje: sa shpesh ndryshojnë përmbajtjet, kush i përditëson dhe sa faqe duhen.
| Situata | Zgjedhja e rekomanduar | Pse |
|---|---|---|
| Restorant, zanatçi ose studio me 5–10 faqe që ndryshojnë disa herë në vit | Faqe statike | E shpejtë, e lirë, pa server për të mirëmbajtur |
| Profesionist që publikon vetë artikuj ose lajme | CMS | I përditëson përmbajtjet pa thirrur një zhvillues |
| Katalog me qindra produkte ose përmbajtje që ndryshojnë çdo ditë | SSR ose platformë e-commerce | Faqe gjithmonë të përditësuara dhe të indeksueshme pa rindërtuar faqen |
| Zonë e rezervuar, rezervime, të dhëna për përdorues | Web app plus faqe publike statike ose SSR | Faqet publike i shërbejnë SEO-së, zona e rezervuar jo |
Për shumë biznese lokale, oraret, vlerësimet dhe udhëzimet rrugore kanë më shumë rëndësi se vetë faqja: një profil Google Business i kujdesur vlen shpesh më shumë se një funksionalitet shtesë.
Pyetjet që duhen bërë para se të zgjedhësh
- Kush do t'i përditësojë përmbajtjet, dhe sa shpesh? Nëse përgjigjja është "pronari, çdo javë", duhet një panel.
- Sa rëndësi ka Google? Nëse faqja jeton nga kërkimet organike, çdo faqe duhet t'i arrijë crawler-it si HTML i plotë: statike ose SSR, kurrë një single page app pa prerendering.
- Kush do ta mirëmbajë serverin? Një SSR ose një CMS pa përditësime plaket keq; një faqe statike mund të qëndrojë e paprekur për vite.
- Sa mund të rritet? Të nisesh statik dhe të kalosh në SSR është e mundur, me kusht që të zgjedhësh një arkitekturë që e lejon, siç ndodhi me mua me Angular.
Gabimet që shoh më shpesh
- Një CMS i rëndë për pesë faqe që nuk ndryshojnë kurrë: plugin-e për t'u përditësuar dhe rreziqe sigurie pa asnjë përfitim.
- Një single page app pa prerendering për një faqe që duhet të gjendet: e këndshme në përdorim, e padukshme për motorët e kërkimit.
- Zgjedhja e SSR-së pa buxhet për ta mirëmbajtur: një server duhet monitoruar, përditësuar dhe paguar çdo muaj.
Në përmbledhje
Nuk ekziston teknologjia më e mirë në absolut: ekziston ajo që i përshtatet mënyrës si përditësohen përmbajtjet dhe kujt i menaxhon. Për shumicën e bizneseve të vogla një faqe statike e bërë mirë është zgjedhja më solide; një CMS ka kuptim kur pronari do autonomi; SSR duhet kur përmbajtjet janë shumë dhe ndryshojnë shpesh. Faqja ime më mësoi se çdo zgjedhje ka një kosto të fshehur: e rëndësishme është ta njohësh që më parë. Nëse po vlerëson një projekt, më shkruaj dhe nisemi nga këto pyetje.