HTTP 304 status kod: šta znači i kako da ga rešite

Kada proveravate performanse svog web sajta, logove servera ili radite u developer tools-u, možete da naletite na status kod 304 Not Modified. Na prvi pogled, ovaj kod može da deluje kao greška, pogotovo ako niste sigurni šta znači. Na sreću, HTTP 304 uglavnom ne znači neki problem, već u najvećem broju slučajeva ukazuje na problem sa keširanjem.

Šta znači HTTP 304 Not Modified?

HTTP 304 je zapravo odgovor servera da se traženi resurs nije promenio od poslednje posete. To znači da browser ne mora ponovo da preuzima isti fajl sa servera, već može da koristi verziju koju već ima sačuvanu u kešu (slika, CSS fajl, JavaScript fajl, HTML dokument ili neki drugi resurs koji je browser već ranije učitao). Ako server proceni da se taj resurs nije promenio, vraća status 304, kako ne bi nepotrebno ponovo učitavao novi sadržaj.

U praksi, to izgleda ovako: korisnik prvi put otvori stranicu i browser preuzme sve potrebne fajlove. To mogu da budu HTML, CSS, JavaScript, slike, fontovi i drugi resursi. Zajedno sa tim fajlovima, server šalje i informacije o keširanju. Te informacije govore browseru koliko dugo može da čuva fajlove i kako da proveri da li su se promenili.

Kada korisnik sledeći put poseti isti sajt, browser ne mora odmah da preuzima sve ispočetka. Umesto toga on prvo proverava da li postojeći fajlovi i dalje mogu da se koriste. Ako server potvrdi da se sadržaj nije promenio, vraća odgovor 304 Not Modified. Browser zatim prikazuje posetiocu lokalnu kopiju iz keša.

Kako HTTP 304 funkcioniše u praksi?

Da bismo razumeli zašto se javlja status 304, važno je da razumemo osnovni princip HTTP keširanja. Zato hajde prvo da objasnimo kako keširanje uopšte funkcioniše.

Kada browser prvi put zatraži neki fajl, server mu šalje taj fajl zajedno sa određenim HTTP zaglavljima (header). Ta zaglavlja mogu da sadrže podatke kao što su vreme poslednje izmene fajla, oznaka verzije fajla ili pravila koliko dugo fajl može da se čuva u kešu.

Kada browser kasnije ponovo zatraži isti resurs, on može da pošalje uslovni zahtev. To znači da browser praktično pita server: „Imam ovu verziju fajla. Da li se nešto promenilo od tada?“

Ako se fajl nije promenio, server ne šalje ceo fajl ponovo. Umesto toga, šalje odgovor 304 Not Modified. Browser tada koristi kopiju koju već ima.

Ako se fajl promenio, server vraća status 200 OK i šalje novu verziju fajla.

Ovo je važno zato što smanjuje nepotrebno preuzimanje podataka. Kod većih slika, CSS fajlova ili JavaScript bundle-ova, razlika može da bude značajnija.

Razlika između 304 i 200 status koda

Status kod 200 OK znači da je zahtev uspešno obrađen i da server šalje traženi sadržaj. Ako browser traži sliku, server će uz 200 odgovor poslati celu sliku. Ako traži CSS fajl, server će poslati ceo CSS fajl.

Status kod 304 Not Modified znači da server ne šalje ponovo sadržaj, jer browser već ima trenutno važeću verziju u kešu. U tom slučaju server šalje samo zaglavlja, a browser koristi lokalnu kopiju fajla.

Za korisnika, razlika često nije toliko vidljiva, jer se sajt u oba slučaja učita. Razlika je jedino u tome što se kod 304 manje podataka prenosi preko mreže, pa učitavanje može da bude nešto brže.

Na primer, ako je slika velika 500 KB, odgovor 200 znači da se tih 500 KB ponovo preuzima. Odgovor 304 znači da se slika ne preuzima ponovo, već se koristi verzija koju browser već ima. To štedi bandwidth na vašem hosting nalogu i ujedno ubrzava učitavanje vašeg sajta.

Kako ETag utiče na HTTP 304?

Jedan od najvažnijih mehanizama za keširanje jeste ETag. To je oznaka koju server dodeljuje određenoj verziji resursa.

Možete da ga zamislite kao jedinstvenu oznaku verzije fajla. Kada server prvi put pošalje fajl browseru, može da pošalje i ETag vrednost. Kada browser sledeći put traži isti fajl, on šalje tu vrednost nazad serveru i pita ga da li je ta verzija i dalje aktuelna.

Ako se ETag poklapa sa trenutnom verzijom fajla na serveru, server vraća 304 Not Modified. Ako se ne poklapa, server šalje novu verziju fajla sa statusom 200 OK.

ETag je koristan zato što omogućava precizniju proveru od običnog datuma izmene. Ipak, ako nije dobro podešen, može da dovede do toga da browser ili CDN koriste staru verziju fajla duže nego što bi trebalo.

Šta je Last-Modified zaglavlje?

Drugi važan mehanizam je Last-Modified zaglavlje. Ono govori browseru kada je resurs poslednji put izmenjen.

Kada browser kasnije ponovo zatraži isti resurs, može da pošalje informaciju o datumu poslednje poznate izmene. Server zatim proverava da li se fajl u međuvremenu promenio.

Ako se nije promenio, server vraća 304. Ako jeste, šalje novu verziju.

Ovaj sistem je jednostavan i često sasvim dovoljan. Međutim, kod dinamičkih sajtova, CDN sistema, WordPress sajtova sa keš plugin-ovima ili aplikacija koje često menjaju fajlove, potrebno je pažljivo podesiti keširanje kako bi browser uvek znao kada treba da povuče novu verziju.

Uloga Cache-Control zaglavlja

Cache-Control zaglavlje određuje kako browser treba da kešira određeni resurs. Ono može da kaže browseru koliko dugo sme da koristi lokalnu kopiju fajla pre nego što proveri da li postoji nova verzija.

Na primer, ako server pošalje pravilo da se određeni CSS fajl kešira jedan sat, browser ga u tom periodu neće ponovo tražiti od servera. Tek kada taj period istekne, browser može da pošalje uslovni zahtev i tada server može da odgovori statusom 304.

Ovo je korisno za statičke fajlove koji se retko menjaju, kao što su slike, fontovi ili verzionisani CSS i JavaScript fajlovi. Međutim, za sadržaj koji se često menja, predugo keširanje može da napravi problem.

Zato je važno pronaći dobar balans. Prekratko keširanje može da uspori sajt, jer se fajlovi prečesto proveravaju ili preuzimaju. Predugo keširanje može da dovede do toga da korisnici gledaju zastareo sadržaj.

Kada HTTP 304 može da napravi problem?

HTTP 304 može da napravi problem kada server, browser, CDN ili proxy sistem pogrešno procene da se sadržaj nije promenio.

To se najčešće vidi u situacijama kada izmenite CSS, ali korisnik i dalje vidi stari dizajn. Ili kada promenite sliku, a na sajtu se i dalje prikazuje prethodna verzija. Isto može da se desi i sa JavaScript fajlovima, pa neke funkcionalnosti ne rade kako očekujete jer browser koristi stari fajl iz keša.

Kod WordPress sajtova, ovaj problem se često javlja kada imate više slojeva keširanja. Na primer, jedan keš može da postoji u browseru, drugi u WordPress plugin-u, treći na serveru, a četvrti na CDN-u. Ako samo jedan od tih slojeva zadrži staru verziju, korisnik može da vidi sadržaj koji više nije aktuelan.

Zbog toga nije dovoljno samo reći „obrisao sam keš. Važno je znati koji keš je obrisan i gde se problem zapravo nalazi.

Kako da rešite problem sa HTTP 304 status kodom?

Ako 304 radi kako treba, ne treba ništa da popravljate. Ali ako posetioci vašeg sajta vide staru verziju sajta, tada treba da proverite keširanje.

Prvi korak je najjednostavniji: obrišite keš u browseru. To je posebno korisno ako se problem javlja samo kod jednog korisnika ili samo na vašem računaru. Nakon brisanja keša, browser će morati ponovo da preuzme sveže verzije fajlova.

Drugi korak je testiranje kroz developer tools. U Chrome-u, Firefox-u i drugim browserima možete da otvorite Network tab i privremeno isključite keširanje dok je developer tools otvoren. Tako možete da proverite da li server zaista šalje novu verziju fajla ili browser i dalje koristi staru kopiju.

Ako problem nije u browseru, sledeći korak je provera servera. Potrebno je pogledati Cache-Control, ETag i Last-Modified zaglavlja. Ako su podešena previše agresivno, browser može predugo da koristi stare verzije fajlova.

Kod CSS i JavaScript fajlova često je dobro koristiti verzionisanje. Na primer, umesto da se fajl uvek zove style.css, može da se učitava kao style.css?v=2 ili da build proces generiše naziv fajla sa hash vrednošću. Kada se naziv ili verzija fajla promeni, browser zna da treba da preuzme novu verziju.

Ako koristite CDN, obavezno proverite i njegov keš. Vrlo često se desi da browser nije problem, već CDN i dalje isporučuje staru verziju fajla. U tom slučaju potrebno je očistiti CDN cache ili podesiti kraći TTL za resurse koji se češće menjaju.

Da li treba potpuno isključiti keširanje?

U većini slučajeva, ne treba potpuno isključiti keširanje. Keširanje je važno za brzinu sajta, korisničko iskustvo i jer manje troši resurse. Ako ga potpuno isključite, sajt može da postane sporiji, posebno kod korisnika koji se često vraćaju.

Umesto potpunog isključivanja, bolje je pravilno podesiti pravila. Za fajlove koji se retko menjaju možete koristiti duže keširanje. Za fajlove koji se često menjaju bolje je koristiti kraće vreme keširanja ili obaveznu proveru sa serverom.

Važno je razumeti i razliku između no-cache i no-store. Iako zvuče slično, ne znače isto.

no-cache ne znači da browser uopšte ne sme da kešira fajl. To znači da mora da proveri sa serverom da li je keširana verzija i dalje važeća pre nego što je upotrebi.

no-store znači da browser ne treba da čuva resurs u kešu. To se koristi za posebno osetljive podatke, na primer kod stranica koje sadrže privatne informacije, podatke o korisniku ili druge sadržaje koji ne treba da ostaju sačuvani.

Za većinu statičkih fajlova, potpuno isključivanje keša nije dobro rešenje. Bolje je pravilno podesiti keširanje i koristiti verzionisanje fajlova.

HTTP 304 i WordPress sajtovi

Kod WordPress sajtova, HTTP 304 najčešće vidite kod statičkih resursa kao što su CSS, JavaScript, slike i fontovi. To je normalno i često poželjno. Ako se stranice brže učitavaju jer browser koristi keširane fajlove, to je dobra stvar.

Problem se javlja kada promenite temu, CSS, logo, sliku ili neki deo sadržaja, a korisnici i dalje vide staru verziju. Tada treba proveriti više mesta.

Prvo proverite keš browsera. Zatim proverite keš plugin ako ga koristite. Ako imate LiteSpeed Cache, WP Rocket, W3 Total Cache ili neki drugi plugin, očistite keš iz njegovih podešavanja. Ako koristite CDN (na primer Cloudflare), očistite i CDN cache. Ako hosting ima serversko keširanje, proverite da li postoji opcija za njegovo brisanje u hosting panelu.

Kod WordPress-a je čest problem i minifikacija ili kombinovanje CSS i JavaScript fajlova. Ako plugin napravi optimizovanu verziju fajla, a zatim se originalni fajl promeni, nekada optimizovana verzija može da ostane stara. Zato posle većih izmena dizajna ili funkcionalnosti treba očistiti sve relevantne slojeve keša.

HTTP 304 i SEO

HTTP 304 sam po sebi nije loš za SEO. Naprotiv, pravilno keširanje može da pomogne performansama sajta, a brzina učitavanja jeste važna za korisničko iskustvo.

Google i drugi pretraživači razumeju HTTP 304. Kada crawler proverava stranicu ili resurs i dobije odgovor da se sadržaj nije promenio, može efikasnije da koristi svoje resurse. To nije problem dokle god server tačno prijavljuje stanje.

Problem može da nastane ako server vraća 304 i onda kada se sadržaj zaista promenio. U tom slučaju crawler može da propusti novu verziju stranice ili važnu izmenu. To nije čest problem, ali može da se desi kod loše podešenog keširanja, pogrešnih ETag vrednosti, CDN keša ili neispravnih server pravila.

Za SEO je najvažnije da korisnici i pretraživači dobiju aktuelan sadržaj. Ako ste promenili važan tekst, naslov, meta opis, canonical tag, interne linkove ili strukturu stranice, treba proveriti da li se nova verzija zaista isporučuje.

Kako da proverite HTTP 304 status kod?

Najlakši način je da koristite developer tools u browseru. Otvorite stranicu, pritisnite F12 ili desni klik pa Inspect, zatim otvorite Network tab i osvežite stranicu. Tu možete da vidite sve zahteve koje browser šalje i status kodove koje server vraća.

Ako vidite 304 kod statičkih resursa, to ne mora da bude problem. Naprotiv, to često znači da keširanje radi. Ali ako pokušavate da proverite novu verziju CSS-a, JavaScript-a ili slike, a browser stalno dobija 304, tada treba proveriti da li se nova verzija zaista učitava.

Možete koristiti i alate iz terminala, na primer curl, ako želite preciznije da proverite HTTP zaglavlja. To je korisno kada želite da vidite Cache-Control, ETag, Last-Modified i druge informacije koje server šalje.

Primer:

curl -I https://mojdomen.co.rs/style.css

Ova komanda prikazuje samo HTTP zaglavlja, bez preuzimanja celog sadržaja. Tako možete brzo da proverite kako je keširanje podešeno.

Kratak praktičan redosled provere

Ako korisnik vidi staru verziju sajta, prvo proverite da li se problem javlja samo kod njega ili kod svih. Ako se javlja samo kod jednog korisnika, najverovatnije je u pitanju browser cache.

Ako se problem javlja kod više korisnika, proverite WordPress keš, serverski keš i CDN. Nakon toga proverite HTTP zaglavlja i vidite da li server šalje pravila koja predugo zadržavaju stare verzije fajlova.

Ako se problem odnosi na CSS ili JavaScript, proverite da li koristite verzionisanje fajlova. To je često najčistije rešenje, jer browser tada jasno vidi da se fajl promenio.

Zaključak

HTTP 304 Not Modified ne treba posmatrati kao grešku. U većini slučajeva to znači da keširanje radi kako treba i da browser ne preuzima fajlove koje već ima.

Problem postoji samo onda kada korisnici zbog keša vide staru verziju sajta. Tada treba da proverite gde se ta stara verzija zadržala: u browseru, WordPress kešu, na serveru ili CDN-u.

Imajte u vidu da je keš koristan zbog brzine vašeg sajta, ali kada promenite CSS, JavaScript, sliku ili sadržaj stranice, korisnici treba da dobiju novu verziju, a ne staru kopiju iz keša.

Kada je to dobro podešeno, HTTP 304 pomaže da se sajt brže učitava i ne predstavlja razlog za brigu.

Nenad Mihajlović