Next.js performanse

Zašto Next.js projekti vremenom postaju spori

Većina Next.js projekata nije spora na početku. Obično počinju sa čistom strukturom, malim brojem stranica, malo klijentskog JavaScript-a i backendom koji još brzo odgovara. Prva verzija deluje moderno, jednostavno i brzo.

Problem se javlja kasnije. Dodaju se nove stranice. Više programera radi na istom kodu. Uvode se marketinške skripte. Produktni timovi traže personalizaciju. Dizajneri dodaju interaktivne elemente. Backend API-ji rastu. Upiti ka bazi postaju teži. Odjednom ista aplikacija koja je nekad radila trenutno postaje skupa za održavanje i spora za korišćenje.

Ovo je jedan od najčešćih produkcijskih problema modernih web aplikacija. Next.js daje timovima moćne alate, ali ne sprečava automatski propadanje arhitekture. Performanse moraju da se tretiraju kao inženjerska disciplina, a ne kao završno poliranje pred puštanje.

Next.js obično nije pravi problem

Kada Next.js projekat postane spor, prva reakcija je često da se okrivi framework. U praksi, on je retko glavni problem. Pravi problem je obično način na koji se aplikacija razvijala.

Spora produkcijska Next.js aplikacija je često zbir mnogo malih odluka. Jedna nepotrebna klijentska komponenta nije katastrofa. Jedan dodatni API zahtev nije katastrofa. Jedna analitička skripta nije katastrofa. Jedna neoptimizovana slika nije katastrofa. Ali posle šest meseci te odluke postaju problem performansi celog sistema.

Dobar rad na performansama počinje razdvajanjem simptoma od uzroka. Stranica može da deluje sporo jer je React hidracija skupa, ali hidracija može biti skupa jer je previše stranice prebačeno na klijenta. Stranica renderovana na serveru može sporo da odgovara, ali pravi problem može biti upit ka bazi iza API poziva. Indikator učitavanja se može pojaviti kasno, a stvarni problem je kaskada zahteva.

Skrivena cena previše klijentskih komponenti

Jedan od najčešćih razloga zašto Next.js aplikacije postaju spore je nekontrolisan rast klijentskih komponenti. Direktiva izgleda malo, ali njen uticaj može biti veliki.

'use client'

Kada komponenta postane klijentska, mora da se pošalje u browser kao JavaScript. Browser zatim mora da je preuzme, parsira, izvrši i hidrira. Na jakom razvojnom računaru to može delovati prihvatljivo. Na sporijem mobilnom uređaju to može postati jedan od najvećih troškova performansi koje korisnik oseti.

Opasan obrazac nije korišćenje klijentskih komponenti - one su potrebne za interaktivnost. Opasan obrazac je njihovo korišćenje kao podrazumevanog izbora. Navigacioni meni, panel sa filterima, galerija, kalkulator cena ili widget za zakazivanje možda trebaju ponašanje na klijentu. Ali okolni raspored, statičan tekst, SEO sadržaj, naslovi i većina informacija o proizvodu obično ne trebaju.

Zdrav Next.js kod drži klijentske komponente malim i izolovanim. Browser tretira kao skupo okruženje, a ne kao mesto gde svaki deo stranice automatski treba da se izvršava.

Renderovanje na serveru ne popravlja sporo dohvatanje podataka

Renderovanje na serveru može da poboljša utisak brzine, SEO i isporuku početnog sadržaja. Ali ono ne čini spore izvore podataka brzim. Ako stranica čeka spore API-je, spore upite ka bazi ili zahteve jedan za drugim, i renderovani HTML će kasniti.

Česta greška je ovakav kod za dohvatanje podataka:

const user = await getUser()
const bookings =
    await getBookings(user.id)
const recommendations =
    await getRecommendations(user.id)

Ponekad je ovaj redosled neophodan. Vrlo često nije. Kada podaci ne zavise od prethodnog rezultata, stranica ne treba da pravi veštačku kaskadu.

const [
    user,
    bookings,
    recommendations
] = await Promise.all([
  getUser(),
  getBookings(),
  getRecommendations(),
])

Ova optimizacija izgleda jednostavno, ali u stvarnim produkcijskim sistemima može da skine stotine milisekundi sa zahteva. Što je aplikacija veća, važnije je razumeti koji pozivi zaista zavise jedan od drugog, a koji mogu da idu paralelno.

Indikatori učitavanja mogu da sakriju probleme arhitekture

Stanja učitavanja su korisna - pomažu korisniku da shvati da se nešto dešava. Ali mogu i da sakriju dublje probleme arhitekture.

Ako se svaki važan deo stranice pojavi tek posle dohvatanja na klijentu, korisnik zapravo ne dobija brzu stranicu. Dobija ljušturu. Browser učita ljušturu, zatim preuzme JavaScript, izvrši ga, pokrene API zahteve, sačeka podatke i tek onda prikaže smislen sadržaj.

Takav obrazac može biti prihvatljiv za kontrolne table i interne alate. Obično nije idealan za javne marketinške stranice, stranice proizvoda, landing stranice, blog članke, stranice kategorija ili sadržaj osetljiv na SEO.

U mnogim sporim Next.js aplikacijama pitanje ne treba da bude „kako da indikator učitavanja bude lepši?“. Bolje pitanje je „zašto ovaj sadržaj nije dostupan ranije?“.

Problemi sa hidracijom rastu polako

Problemi sa hidracijom se često javljaju kada projekat postane dinamičniji. Datumi se formatiraju drugačije na serveru i klijentu. Nasumične vrednosti se generišu tokom renderovanja. Komponente čitaju iz local storage-a. Logika zavisna od veličine ekrana se izvršava prerano. Personalizacija zasnovana na kolačićima menja renderovani izlaz.

const value = Math.random()
const now = new Date()
const width = window.innerWidth

Ovi primeri izgledaju bezazleno, ali mogu da naprave razliku između izlaza na serveru i na klijentu. Čak i kada ne pokvare stranicu potpuno, povećavaju složenost i otežavaju traženje problema sa performansama.

Rešenje nije izbegavanje dinamičkog ponašanja, već preciznost oko toga gde ono pripada. Sadržaj renderovan na serveru treba da bude determinističan. Vrednosti dostupne samo u browseru treba čitati tek kada se komponenta montira. Personalizaciju treba projektovati namerno, umesto da se umeša u svaki raspored i komponentu.

Skripte trećih strana su često skuplje nego što se misli

Mnogi timovi pažljivo optimizuju React komponente, a onda dodaju pet skripti trećih strana bez merenja rezultata. Analitika, pikseli za oglase, toplotne mape, chat widget-i, alati za A/B testiranje, menadžeri pristanka i biblioteke za praćenje mogu da se otimaju o glavnu nit browsera.

Najveći trošak nije uvek veličina preuzimanja. Veći problem je izvršavanje. Skripte mogu da blokiraju glavnu nit, odlože interakciju, izazovu pomeranje rasporeda i učine da stranica deluje nestabilno.

Next.js aplikacija spremna za produkciju treba da tretira skripte trećih strana kao deo budžeta performansi. Treba ih učitavati namerno, odlagati kad je moguće i uklanjati kada više ne donose poslovnu vrednost.

Backend je i dalje važan

Next.js performanse nisu samo frontend performanse. Stranica može imati savršenu strukturu komponenti i opet biti spora jer je backend spor.

U stvarnim aplikacijama brzina stranice često zavisi od indeksa u bazi, agregacije API-ja, strategije keširanja, obrade redova poruka, spoljnih servisa i mrežne latencije. Ako serverska komponenta čeka API koji radi neefikasan upit ka bazi, korisnik taj problem baze doživljava kao problem performansi Next.js-a.

Zato ozbiljna optimizacija treba da uključi praćenje celog zahteva. Nije dovoljno znati da je stranici trebalo dve sekunde. Tim mora da zna gde su te dve sekunde otišle.

Renderovanje stranice: 120 ms
API zahtev:            980 ms
Upit ka bazi:          720 ms
Spoljni servis:        260 ms
Hidracija:             430 ms
JS trećih strana:      350 ms

Bez ovakve raščlambe timovi često optimizuju pogrešan sloj. Skrate React komponentu za 20 milisekundi, a zanemare upit ka bazi koji košta 700 milisekundi.

Keširanje je moćno, ali samo kada je projektovano

Next.js nudi više opcija keširanja, ali keširanje postaje opasno kada niko ne razume šta je keširano, gde i kako se poništava.

Zrela strategija keširanja obično ima više slojeva. Browser može da kešira statične fajlove. CDN može da kešira javne stranice. Next.js može da kešira rezultate dohvatanja ili renderovane rute. Backend može da kešira skupe proračune. Baza može da ima koristi od keša upita, indeksa i „zagrejanih“ stranica.

Problem počinje kada timovi dodaju keširanje kao brzu zakrpu. Spora stranica postane brza - dok podaci ne postanu pogrešni. Onda poništavanje keša postane hitno. Onda programeri dodaju ručnu revalidaciju. Onda se različita okruženja različito ponašaju. Na kraju niko nije potpuno siguran koju verziju stranice korisnik vidi.

Dobro keširanje počinje klasifikacijom. Neke stranice mogu da se keširaju agresivno. Neke mogu kratko da budu zastarele. Neke su vezane za korisnika i ne smeju da se dele. Neki podaci mogu da se keširaju, dok okolna stranica mora ostati dinamička.

Statičko generisanje nije čarobno rešenje

Statičko generisanje i postepena regeneracija mogu biti odlični za stranice sa mnogo sadržaja. Blog članci, dokumentacija, landing stranice i mnoge stranice kataloga mogu imati koristi od toga da se generišu unapred ili ponovo koriste između zahteva.

Ali statičko generisanje postaje komplikovano kada stranica sadrži cene koje se često menjaju, dostupnost, sadržaj vezan za korisnika, dozvole, eksperimente ili varijante zavisne od lokacije.

Greška nije korišćenje statičkog generisanja, već pretvaranje da svaka stranica odgovara istom modelu. Aplikacija visokih performansi često koristi više strategija renderovanja: statično gde je moguće, dinamički gde je neophodno, strimovano gde je korisno, a samo na klijentu tamo gde interaktivnost to zaista zahteva.

Middleware može postati skriveni sloj performansi

Middleware je koristan za preusmeravanja, proveru autentikacije, eksperimente, lokalizaciju i obradu zahteva. Ali kada se u njega stavi previše logike, svaki zahtev počinje da plaća tu cenu.

Vremenom middleware može da postane skrivena aplikacija unutar aplikacije. Proverava kolačiće, čita zaglavlja, primenjuje geo pravila, obrađuje preusmeravanja, dodeljuje eksperimente i odlučuje da li korisnik sme da pristupi stranici.

Ta logika treba da bude mala, merljiva i predvidiva. Ako svaki zahtev prolazi kroz složeno grananje pre nego što uopšte stigne do stranice, aplikaciju je teže debagovati, a lakše usporiti.

Globalni provajderi mogu da poskupe svaku stranicu

Još jedan čest izvor pada performansi je nekontrolisan rast globalnih provajdera. Provajderi za autentikaciju, temu, analitiku, modale, obaveštenja, feature flag-ove i upravljanje stanjem često se dodaju u koren aplikacije.

To deluje zgodno jer svaka komponenta može da pristupi svemu. Ali zgodnost ima cenu. Ako je provajder postavljen previsoko u stablu, može da utiče na stranice kojima nije potreban. Može da poveća klijentski JavaScript, posao hidracije i složenost ponovnog renderovanja u celoj aplikaciji.

Provajdere treba postaviti što bliže delovima aplikacije kojima su zaista potrebni. Blog članku ne treba isto klijentsko okruženje kao kontrolnoj tabli za prijavljene korisnike. Javnoj landing stranici ne treba svaki provajder iz toka zakazivanja.

Slike mogu tiho da postanu usko grlo

Slike su često jedan od najvećih delova stranice. Next.js optimizacija slika pomaže, ali ne zamenjuje dobru strategiju za slike.

Stranica i dalje može da postane spora ako učitava previše slika, koristi slike pogrešnih dimenzija, renderuje skrivene galerije, daje prioritet pogrešnoj slici ili generiše previše varijanti. Optimizaciju slika treba spojiti sa odlukama o tome šta zaista mora da se učita odmah.

Najvažnija slika na stranici treba da se učita namerno. Sporedne slike ne treba da joj konkurišu. Galerije, slajderi i slike ispod prvog ekrana treba da budu projektovani sa načinom učitavanja na umu.

Problemi sa performansama obično prolaze kroz više slojeva

Najteži problemi sa performansama u Next.js-u retko su ograničeni na jednu komponentu. Obično prolaze kroz više slojeva.

Stranica proizvoda može biti spora jer je React stablo previše klijentsko, ali i zato što API vraća previše podataka, i zato što upitu ka bazi nedostaje indeks, i zato što stranica učitava previše skripti trećih strana. Rešavanje samo jednog od tih problema možda neće biti dovoljno.

Zato rad na performansama treba meriti kroz celo korisničko putovanje. Tim treba da razume vreme odgovora servera, latenciju API-ja, cenu baze, veličinu JavaScript paketa, vreme hidracije, pomeranja rasporeda i kašnjenje interakcije.

Kako sprečiti pad performansi u Next.js-u

Sprečavanje pada performansi je lakše od popravke kada je sistem već postao spor. Najefikasniji timovi rano uvode jednostavna pravila i drže ih na vidiku tokom razvoja.

Klijentske komponente treba da budu namerne. Dohvatanje podataka treba proveriti na kaskade. Pozive ka backendu treba meriti. Skupe upite treba profilisati. Skripte trećih strana treba da imaju vlasnika. Pravila keširanja treba dokumentovati. Velike zavisnosti treba preispitati pre nego što postanu trajne.

Performanse treba da budu i deo pregleda koda. Pull request koji dodaje novi provajder, novu skriptu, novi API poziv ili novu klijentsku zavisnost treba pregledati ne samo zbog ispravnosti, već i zbog cene u radu.

Praktična lista za pregled

Kada pregledaš Next.js stranicu koja deluje sporo, kreni od cele putanje zahteva. Ne pretpostavljaj da je problem frontend i ne pretpostavljaj da je problem backend. Izmeri oba.

Proveri da li je stranica statična, dinamička ili nepotrebno dinamička. Proveri da li se zahtevi za podacima izvršavaju jedan za drugim bez razloga. Proveri koliko JavaScript-a ide u browser. Proveri da li se klijentske komponente koriste samo tamo gde je potrebna interaktivnost. Proveri da li skripte trećih strana odlažu interakciju. Proveri da li backend rade nepotreban posao. Proveri da li baza koristi prave indekse.

Cilj nije da svaka stranica bude statična ili da se ukloni svaka klijentska komponenta. Cilj je da svaka skupa odluka bude vidljiva.

Kako izgleda zdrava Next.js arhitektura

Zdrava produkcijska Next.js arhitektura ima jasne granice. Statičan sadržaj je statičan. Interaktivni delovi su izolovani. Skupe backend operacije se mere. Pravila keširanja su eksplicitna. Skripte trećih strana su pod kontrolom. Dohvatanje podataka je projektovano, a ne razbacano.

Najbolji sistemi nisu brzi slučajno. Brzi su jer timovi stalno postavljaju ista pitanja: da li ovo mora da se izvršava na klijentu? Da li ovi podaci moraju da se dohvate sada? Da li ovaj zahtev može da se kešira? Da li je ovaj upit indeksiran? Da li je ova skripta vredna svoje cene? Može li ovaj posao da se uradi kasnije?

Ova disciplina postaje sve važnija kako sistem raste. Mali projekat može da preživi mnogo neefikasnih odluka. Veliki produkcijski sistem ne može.

Zaključak

Next.js projekti vremenom postaju spori jer aplikacije postaju složenije. Više klijentskog JavaScript-a, više dohvatanja podataka, više backend zavisnosti, više skripti, više personalizacije i više pravila keširanja - sve to povećava cenu isporuke stranice.

Rešenje nije napuštanje Next.js-a, već njegovo korišćenje uz produkcijsku disciplinu. Drži jasne odgovornosti servera i klijenta. Meri celu putanju zahteva. Tretiraj keširanje kao arhitekturu. Profiliši pozive ka backendu. Smanji nepotreban JavaScript. Proveravaj performanse pre nego što postanu hitan slučaj.

Brze aplikacije se ne prave samo dobrim framework-om. Prave ih timovi koji razumeju gde se troši vreme.