Razlika je predvsem v tem, kak\u0161no spletno stran imamo, koliko vsebine je dinami\u010dne in kak\u0161no predpomnjenje \u017ee uporabljamo. Pri obi\u010dajni predstavitveni WordPress strani, ki jo u\u010dinkovito predpomni LiteSpeed Cache ali druga re\u0161itev za Page Cache, obiskovalec po vklju\u010ditvi Redisa morda sploh ne bo opazil razlike. Pri spletni trgovini WooCommerce, strani s prijavljenimi uporabniki ali drugi dinami\u010dni aplikaciji pa je zgodba lahko povsem druga\u010dna.<\/p>\n\n
Kaj je Redis?<\/h2>\n
Redis je zelo hitra podatkovna shramba, ki podatke hrani predvsem v delovnem pomnilniku oziroma RAM-u.<\/p>\n
WordPress pri svojem delovanju neprestano potrebuje podatke iz podatkovne baze MySQL oziroma MariaDB. Podatki o objavah, uporabnikih, nastavitvah, izdelkih, kategorijah in \u0161tevilnih drugih elementih se med izdelavo strani pridobivajo in obdelujejo.<\/p>\n
WordPress sicer \u017ee vsebuje svoj Object Cache, vendar je ta privzeto neobstojen. Podatki v njem obstajajo samo med izvajanjem posamezne zahteve in se med razli\u010dnimi prikazi strani ne ohranijo. Persistent Object Cache to spremeni.<\/p>\n
\u010ce za njegovo zaledje uporabimo Redis, lahko pogosto uporabljeni podatki ostanejo v hitrem pomnilniku tudi za naslednje zahteve. WordPress jih zato ob naslednjem prikazu ni nujno prisiljen ponovno pridobiti ali izra\u010dunati. Rezultat je lahko manj dela za podatkovno bazo in hitrej\u0161e izvajanje WordPressa.<\/p>\n\n
Redis Object Cache in Page Cache nista ista stvar<\/h2>\n
To je verjetno najpomembnej\u0161a razlika pri razumevanju Redisa.<\/p>\n
\u010ce uporabljamo LiteSpeed Cache, Nginx FastCGI Cache ali drugo re\u0161itev za Page Cache<\/strong>, lahko stre\u017enik shrani \u017ee izdelano kon\u010dno HTML stran. Ko naslednji obiskovalec zahteva isto stran, se mu lahko postre\u017ee \u017ee pripravljena razli\u010dica, ne da bi WordPress ponovno izvajal celoten PHP in poizvedbe v podatkovno bazo.<\/p>\n Redis Object Cache deluje druga\u010de. WordPress se pri dinami\u010dni zahtevi \u0161e vedno izvaja, vendar lahko del podatkov pridobi iz zelo hitrega pomnilnika namesto iz podatkovne baze.<\/p>\n Redis in Page Cache zato nista konkuren\u010dni tehnologiji. Vsaka re\u0161uje drug problem in zelo dobro lahko delujeta skupaj.<\/p>\n\n Predstavljajmo si preprosto WordPress stran manj\u0161ega podjetja. Na njej je deset ali dvajset podstrani, vsebina se spreminja nekajkrat mese\u010dno, obiskovalci niso prijavljeni in stran uporablja pravilno nastavljen LiteSpeed Cache.<\/p>\n Prvi obiskovalec odpre podstran in WordPress jo izdela. LiteSpeed rezultat shrani. Naslednjih sto obiskovalcev dobi \u017ee pripravljeno razli\u010dico strani.<\/p>\n \u010ce se WordPress pri teh obiskih sploh ne izvaja, Redis nima \u010desa bistvenega pospe\u0161evati. Zato ni smiselno trditi, da bo vklju\u010ditev Redisa vsako WordPress stran pohitrila za 50, 100 ali 300 odstotkov.<\/p>\n \u010ce Page Cache \u017ee opravi skoraj vse delo, je dodatna korist Redis Object Cachea za anonimnega obiskovalca lahko zelo majhna.<\/strong><\/p>\n\n Spletna trgovina je druga\u010den primer. WooCommerce vsebuje veliko dinami\u010dnih elementov: ko\u0161arico, uporabni\u0161ke ra\u010dune, zalogo, cene, naro\u010dila, filtre izdelkov, razli\u010dice izdelkov, personalizirano vsebino in \u0161tevilne druge podatke.<\/p>\n Ko\u0161arice enega obiskovalca seveda ne moremo shraniti v Page Cache in jo nato pokazati drugemu obiskovalcu. Enako velja za checkout in \u0161tevilne strani prijavljenih uporabnikov.<\/p>\n Pri tak\u0161nih zahtevah se mora WordPress dejansko izvajati in dostopati do podatkov. Tu za\u010dne Redis kazati svojo pravo vrednost.<\/p>\n \u010ce WordPress ali posamezni vti\u010dnik ve\u010dkrat potrebuje podatke, ki so \u017ee shranjeni v Redis Object Cacheu, jih lahko pridobi iz pomnilnika namesto s ponovnim delom nad podatkovno bazo.<\/p>\n\n Pri Redisu je zelo lahko narediti napako in gledati samo en rezultat testa hitrosti. Recimo, da se stran brez Redisa izdela v 300 milisekundah, z Redisom pa v 220 milisekundah. Razlika 80 milisekund na prvi pogled ne deluje dramati\u010dno.<\/p>\n Toda zdaj na spletno trgovino isto\u010dasno pride 100 obiskovalcev. \u010ce Redis bistveno zmanj\u0161a \u0161tevilo operacij, ki jih mora izvajati podatkovna baza, je lahko skupna razlika precej ve\u010dja. Stre\u017enik mora opraviti manj dela za posamezno zahtevo in lahko isto\u010dasno obdela ve\u010d obiskovalcev.<\/p>\n Zato je ena najve\u010djih prednosti Redisa pogosto ve\u010dja zmogljivost spletne strani pod obremenitvijo<\/strong>, ne samo nekaj milisekund bolj\u0161i rezultat posameznega testa.<\/p>\n\n \u0160e ena zanimiva razlika je WordPress administracija. Strani Zato lahko persistent object cache pomaga tudi pri administraciji WordPressa, prijavljenih uporabnikih, WooCommerce administraciji, zahtevnej\u0161ih filtrih, REST API zahtevah in drugih dinami\u010dnih operacijah.<\/p>\n\n Persistent Object Cache ni neuraden trik za optimizacijo WordPressa. WordPress ima lasten Object Cache API in v uradni dokumentaciji<\/a> pojasnjuje uporabo persistent cache re\u0161itev. Pri obi\u010dajnem WordPress Object Cacheu se podatki ob koncu zahteve izgubijo, s persistent backendom, kot je Redis, pa lahko ostanejo na voljo naslednjim zahtevam.<\/p>\n\n WordPress in njegovi vti\u010dniki veliko uporabljajo tako imenovane transients \u2013 za\u010dasno shranjene podatke z dolo\u010denim \u010dasom veljavnosti. Brez persistent object cachea se ti praviloma shranjujejo v podatkovno bazo WordPressa. \u010ce je aktiven persistent object cache, kot je Redis, lahko WordPress te podatke u\u010dinkoviteje obravnava prek Object Cachea.<\/p>\n\n Redis ima svoje omejitve. \u010ce WordPress potrebuje tri sekunde za prikaz strani zaradi slabo napisanega vti\u010dnika, to \u0161e ne pomeni, da bo Redis te\u017eavo odpravil.<\/p>\n Prav tako Redis ne bo \u010dude\u017eno popravil slabe SQL poizvedbe, manjkajo\u010dih indeksov v podatkovni bazi, ogromnih in slabo vzdr\u017eevanih tabel, po\u010dasnega zunanjega API-ja, prevelikih slik, ogromne koli\u010dine JavaScripta, po\u010dasnega PHP izvajanja ali stre\u017enika s premalo procesorske mo\u010di in pomnilnika.<\/p>\n \u010ce je spletna stran po\u010dasna, je zato najprej smiselno ugotoviti, kaj je po\u010dasno<\/strong>.<\/p>\n\n Najbolj\u0161i na\u010din ni ugibanje, ampak meritev. Na WordPress strani lahko primerjamo stanje pred in po vklju\u010ditvi Redis Object Cachea.<\/p>\n Smiselno je spremljati predvsem TTFB (Time To First Byte), \u0161tevilo poizvedb v podatkovno bazo, \u010das izvajanja PHP, cache hits in misses ter obna\u0161anje strani pod obremenitvijo. Za podrobnej\u0161o analizo WordPressa je uporabno tudi orodje Query Monitor.<\/p>\n\n Za manj\u0161o predstavitveno stran z odli\u010dnim Page Cacheom Redis verjetno ne bo tehnologija, zaradi katere bo stran nenadoma dvakrat hitrej\u0161a. Pri dinami\u010dni strani pa se razmerje spremeni.<\/p>\n Redis je posebej zanimiv za WooCommerce trgovine, ve\u010dje WordPress portale, strani z veliko prijavljenimi uporabniki, \u010dlanske strani, forume, strani z veliko podatkovnimi poizvedbami, WordPress Multisite in druge dinami\u010dne WordPress projekte.<\/p>\n\n Redis seveda ni WordPress tehnologija. Uporabljajo ga najrazli\u010dnej\u0161e spletne aplikacije in programski jeziki. Poleg predpomnjenja se lahko uporablja za uporabni\u0161ke seje, \u010dakalne vrste, za\u010dasne podatke, API-je, komunikacijo med procesi, omejevanje zahtev in \u0161tevilne druge naloge.<\/p>\n\n Pri ponudnikih gostovanja ni dovolj pogledati samo, ali se beseda Redis pojavlja na seznamu funkcij. Pomembno je tudi, kako je Redis implementiran, pri katerih paketih je na voljo in ali ponudnik pomaga pri njegovi nastavitvi<\/strong>.<\/p>\n\n Webicom<\/a> omogo\u010da uporabo Redis Object Cachea na podprtih cPanel paketih. Zanimiva je predvsem izvedba, saj lahko posamezni cPanel uporabnik uporablja svojo Redis storitev, povezava iz WordPressa pa poteka prek lokalnega Unix socketa. Redis je mogo\u010de povezati tudi z vti\u010dnikom LiteSpeed Cache in tako uporabljati Page Cache in Redis Object Cache hkrati.<\/p>\n Webicom ima objavljena tudi podrobna navodila: Redis Object Cache v WordPressu \u2013 nastavitev na Webicom gostovanju<\/strong><\/a>.<\/p>\n\n![\"Primerjava](\"https:\/\/www.spletnogostovanje.biz\/wp-content\/uploads\/2026\/10\/Page-Cache-vs.-Redis-Object-Cache.png\")
<\/figure>\n\n\nKdaj Redis skoraj ni\u010d ne pohitri?<\/h2>\n
Pri WooCommerce postane stvar precej bolj zanimiva<\/h2>\n
Pomembna ni samo hitrost posameznega obiskovalca<\/h2>\n
Redis lahko pomaga tudi tam, kjer Page Cache ne more<\/h2>\n
\/wp-admin\/<\/code> seveda ne moremo obi\u010dajno servirati vsem uporabnikom iz istega Page Cachea. Redis Object Cache pa deluje na ravni podatkov, ki jih WordPress uporablja.<\/p>\nTudi WordPress sam podpira Persistent Object Cache<\/h2>\n
Redis lahko zmanj\u0161a tudi delo s Transients<\/h2>\n
Redis ne more popraviti slabo narejene spletne strani<\/h2>\n
Kako preveriti, ali Redis dejansko pomaga?<\/h2>\n
Je Redis smiseln za vsako WordPress stran?<\/h2>\n
Redis ni samo za WordPress<\/h2>\n
Kateri slovenski ponudniki gostovanja omogo\u010dajo Redis?<\/h2>\n
Webicom<\/h3>\n
Hostko<\/h3>\n