Conținut Dinamic în Cache
Memorarea în cache este crucială pentru WordPress. Este una dintre modalitățile principale de a face site-urile WordPress să se încarce cât mai repede posibil. Memorarea în cache este ceea ce excelează pluginul WP Rocket. Cu toate acestea, nu este atât de ușor să memorezi în cache site-uri WordPress foarte dinamice, în special cele care afișează pagini personalizate fiecărui utilizator. Dar este posibil să stocați în cache conținutul dinamic cu tehnicile și tehnologia potrivite.
În acest articol, veți afla ce este acest conținut dinamic în cache, cum funcționează stocarea în cache a conținutului dinamic, diferitele sale beneficii și modalitățile multiple în care îl puteți implementa în diferite configurații de server.
Să începem!
Conținut Static vs Conținut Dinamic
Conținutul static rămâne același pe paginile web pentru toți utilizatorii. Proprietarul site-ului îl poate actualiza, dar după aceea noul conținut va fi în continuare static pentru toți utilizatorii. Conținutul static include fișiere precum HTML, CSS, JavaScript, imagini și videoclipuri.
Un exemplu de conținut static este chiar această postare pe blog pe care o citiți. Deoarece conținutul static nu se schimbă adesea (sau deloc), stocarea în cache și livrarea acestuia este foarte ușoară.
Conținutul dinamic nu este același pe paginile web pentru toți utilizatorii. Este personalizat pentru fiecare utilizator în funcție de mai mulți factori, cum ar fi locația, dispozitivul, ora din zi, setările profilului utilizatorului etc. Paginile web dinamice se pot schimba din mers, în funcție de intrarea utilizatorului. Acest lucru face site-urile web mai interactive, captivante și personalizate pentru fiecare utilizator.
Un exemplu de conținut dinamic este feedul de rețele sociale sau coșul de cumpărături. Deoarece este unic pentru fiecare utilizator, stocarea în cache și livrarea nu este atât de simplă.
Cele mai multe site-uri web moderne sunt într-o oarecare măsură dinamice. Ei folosesc scripturi de pe partea serverului pentru a genera toate activele necesare pentru redarea unei pagini web. Browserul compilează aceste elemente pentru a afișa conținut unic și personalizat fiecărui utilizator.
Conținut Dinamic vs Conținut Bazat pe Evenimente
Există și conținut care se încadrează între conținutul static și cel dinamic. Este denumit „Conținut bazat pe evenimente” de către unii profesioniști din industrie.
Câteva exemple de conținut bazat pe evenimente includ:
- Prețurile acțiunilor se modifică rapid în timp ce piețele sunt deschise și apoi rămân statice după închiderea piețelor.
- Comentarii la un articol vechi de știri (nu atrage prea multă atenție) versus o nouă poveste în tendințe (atrage multe comentarii).
- Dacă un site de știri oferă utilizatorilor conținut personalizat în funcție de locația lor, pentru mulți utilizatori din aceeași locație, conținutul este static, dar este dinamic dacă utilizatorii provin din zone unice.
Deoarece nu puteți prezice cu certitudine dacă un anumit conținut este bazat pe evenimente sau dinamic, majoritatea conținutului bazat pe evenimente este clasificat drept conținut dinamic.
Pentru a menține lucrurile simple, vom trata conținutul bazat pe evenimente ca conținut dinamic în acest articol. Odată ce ați înțeles cum funcționează stocarea dinamică în cache a conținutului, puteți explora acest subiect în continuare.
Cum Funcționează Conținut Dinamic în Cache pe WordPress?
Majoritatea site-urilor WordPress sunt simple bloguri sau site-uri de afaceri mici. Conținutul de pe aceste site-uri este de obicei static.
Deoarece WordPress este un CMS care utilizează scripturi PHP și interogări de baze de date pentru a genera toate paginile site-ului în mod dinamic, fiecare solicitare primită generează un nou răspuns de la server. Astfel de răspunsuri nu sunt necesare pentru majoritatea site-urilor web, deoarece duce la o criză de server atunci când traficul crește.
Un cache poate stoca aceste rezultate ale paginii prima dată când sunt generate, astfel încât să poată servi cererile ulterioare din cache și nu de pe server. Acest lucru accelerează semnificativ încărcarea paginii.
Deși acest lucru funcționează perfect pentru conținutul static, deoarece conținutul dinamic este unic pentru fiecare utilizator, nu îl puteți pune în cache folosind tehnici obișnuite de stocare în cache.
În vremurile bune, stocarea în cache a conținutului dinamic era aproape imposibilă. Chiar și astăzi, majoritatea CDN-urilor memorează în cache numai conținut static în mod implicit.
Dar tehnologiile mai noi au făcut posibilă difuzarea cu ușurință a conținutului dinamic dintr-un cache, reducând semnificativ TTFB-ul unor astfel de pagini, păstrând în același timp experiența utilizatorului excelentă.
CDN-urile sunt una dintre cele mai bune modalități de a stoca în cache conținutul static și de a-l livra rapid utilizatorului final, dar pot servi și conținut dinamic. O modalitate prin care CDN-urile „memorează cache” conținutul dinamic este rularea scripturilor pe un server cel mai apropiat de utilizator, mai degrabă decât pe serverul de origine îndepărtată.
Astfel, CDN-urile generează și livrează tot conținutul dinamic de pe serverele lor edge. Acest lucru accelerează timpul de încărcare a paginilor web dinamice.
CDN-urile pot folosi un limbaj de marcare numit Edge Side Includes (ESI) pentru a stoca în cache conținutul dinamic. Puteți insera etichete de elemente ESI în pagina HTML pentru a arăta care elemente sunt dinamice. Acest lucru ajută procesoarele de la margine (un CDN sau un server de origine) să memoreze în cache doar părțile statice ale unei pagini web dinamice.
Proxy-urile inverse HTTP precum Varnish, NGINX și IIS sunt o altă modalitate de a stoca în cache conținutul dinamic. Unele dintre ele, cum ar fi NGINX și IIS, acționează și ca server web primar.
De obicei, un proxy invers este un server (fizic sau virtual) plasat între client și serverul web. Scopul său principal este de a filtra toate solicitările înainte ca acestea să ajungă pe site.
Varnish nu numai că se ocupă de toate solicitările de intrare înainte ca acestea să ajungă pe server, ci memorează și toate răspunsurile serverului. În mod implicit, memoria cache Varnish se reîmprospătează la fiecare două minute, dar o puteți seta la orice timp doriți. Acesta este modul în care Varnish ajută la stocarea în cache a conținutului dinamic.
Varnish își stochează memoria cache în memoria serverului, făcând recuperarea și livrarea răspunsurilor către clienți mult mai rapidă. Pentru o explicație detaliată, citiți articolul despre proxy-urile inverse HTTP. De asemenea, puteți viziona acest videoclip educațional pentru a înțelege mai bine cum funcționează Varnish.
Să vedem cum puteți stoca în cache conținutul dinamic prin diferite mijloace.
Conținut Dinamic în Cache pe un CDN
Metoda exactă de Conținut Dinamic în Cache folosind un CDN variază de la o platformă la alta, dar toate se bazează pe un set de tehnologii numite Dynamic Site Acceleration (DSA).
De exemplu, dacă utilizați Cloudflare CDN, puteți utiliza Cloudflare Workers pentru a configura funcții JavaScript fără server care rulează pe CDN PoP-uri plasate în întreaga lume.
Puteți utiliza aceste funcții personalizate fără server pentru a modifica solicitările și răspunsurile HTTP ale site-ului dvs., pentru a genera răspunsuri noi și pentru a face solicitări paralele. Specialiștii Cloudflare vă pot ajuta site-ul să îndeplinească o varietate de sarcini pe baza mai multor parametri, cum ar fi intrarea utilizatorului, tipul de dispozitiv, locația, ora din zi, API-urile terțelor etc.
Astfel, puteți genera conținut dinamic din CDN-ul însuși și apoi îl puteți servi clienților. De asemenea, puteți combina funcții fără server cu etichete ESI pentru a face acest proces și mai eficient.
Pentru a implementa cu ușurință edge caching pe site-ul dvs., puteți utiliza pluginul gratuit Cloudflare Page Cache. Intrarea în detalii suplimentare depășește scopul acestui articol, dar puteți consulta documentația oficială Cloudflare Workers pentru a începe.
De asemenea, KeyCDN oferă două opțiuni pentru a stoca în cache conținutul dinamic. Prima metodă este să utilizați API-ul KeyCDN pentru a curăța instantaneu memoria cache CDN pe baza acțiunilor utilizatorului, astfel încât utilizatorii dvs. să vadă întotdeauna cel mai recent conținut dinamic în cache.
A doua opțiune sugerată de KeyCDN implică modificarea antetelor Cache-Control pentru ai direcționa clientului cum și când să memoreze în cache răspunsurile și pentru cât timp. Puteți vedea un exemplu în documentația API KeyCDN pentru a înțelege mai bine modul în care este implementat.
API-ul Fastly CDN oferă funcții precum curățarea instantanee a memoriei cache, înregistrarea și disponibilitatea în timp real și mecanisme precum Origin Shield. Puteți consulta câteva exemple despre modul în care utilizatorii Fastly au stocat conținut dinamic în cache folosind CDN: „Cum să memorați în cache cu cookie-uri de urmărire” și „API caching”.
Majoritatea CDN-urilor de top oferă mai multe moduri de Conținut Dinamic în Cache. Dacă utilizați sau intenționați să utilizați oricare dintre CDN-urile menționate mai sus, resursele pe care le-am arătat mai sus vă vor fi utile. Dacă este orice alt CDN, atunci vă sugerez să explorați documentațiile lor sau să luați legătura cu echipa lor de asistență.
Consultați documentația WP Rocket pentru a afla mai multe despre cum puteți integra diferite CDN-uri populare cu WP Rocket.
Conținut Dinamic în Cache Folosind NGINX
Există multe plugin-uri și tehnici de stocare pentru Conținut Dinamic în Cache generat de site-urile WordPress care rulează pe un server NGINX. Cea mai recomandată soluție este utilizarea FastCGI, care este o variantă îmbunătățită a protocolului Common Gateway Interface (CGI).
FastCGI îmbunătățește performanța site-ului prin nedeschiderea unui proces separat pentru fiecare solicitare primită. Orice server care procesează cereri pentru a genera conținut dinamic, cum ar fi NGINX care rulează WordPress, poate beneficia foarte mult de pe urma acestuia.
După cum este descris în articolul NGINX FastCGI Caching pentru WordPress, este foarte ușor să începeți. Serverul web NGINX oferă un modul nativ FastCGI pentru a vă ajuta să îl configurați în câteva minute.
FastCGI elimină necesitatea de a configura soluții suplimentare de stocare în cache, cum ar fi pluginuri WordPress și proxy inverse (de exemplu, Varnish) pentru majoritatea site-urilor.
Modulul ngx_http_fastcgi_module de la NGINX permite serverului web principal să transmită cererile primite către serverul FastCGI. Ca și în cazul tuturor modulelor NGINX, FastCGI este controlat de diverse directive pe care le specificați în fișierul său de configurare.
De obicei, fișierul gazdă virtuală pentru configurarea NGINX se găsește în directorul /etc/nginx/sites-available/domeniultau.ro, unde domeniultau.ro este numele domeniului dvs. (de exemplu, popaion.ro, comunitateawordpress.club) .
Să configurăm NGINX deschizând terminalul serverului și tastând următoarea comandă:
sudo nano /etc/nginx/sites-available/domeniultau.ro
Aceasta va deschide fișierul de configurare în editorul de text Nano din terminalul Linux. Apoi, adăugați următoarele directive NGINX înainte de blocarea serverului{} în fișierul dvs. de configurare.
fastcgi_cache_path /var/run/nginx-fastcgi-cache levels=1:2 keys_zone= COMUNITATEAWORDPRESS:100m inactive=60m; fastcgi_cache_key "$scheme$request_method$host$request_uri"; fastcgi_cache_use_stale error timeout invalid_header http_500; fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
Iată o defalcare linie cu linie a directivelor utilizate mai sus:
- fastcgi_cache_path: Aceasta specifică locația cache-ului, dimensiunea, nivelurile subdirectorului, numele zonei-cheie și durata inactivă. Locația cache-ului poate fi oriunde pe server. Deoarece este mai rapid să serviți fișiere din RAM, am folosit folderul /var/run, deoarece Ubuntu montează acest director ca tmpfs (o memorie rapidă volatilă).
- fastcgi_cache_key: Aceasta direcționează modulul FastCGI asupra modului de criptare a fișierelor cache prin generarea de nume de chei unice.
- fastcgi_cache_use_stale: Acest lucru indică NGINX să continue să difuzeze memoria cache a paginilor vechi (învechite), chiar dacă PHP se blochează (și prin extensie WordPress). Acesta este unul dintre multele puncte forte ale serverelor web NGINX.
- fastcgi_ignore_headers: Această directivă îi spune serverului FastCGI să nu proceseze câmpuri specifice antetului răspunsului.
Directivele de mai sus împreună cu cele implicite NGINX vor permite stocarea în cache pentru întregul dvs. site. Dar configurația actuală nu este încă ideală pentru a difuza un site cu conținut dinamic.
Acum, trebuie să direcționați NGINX să nu memoreze în cache anumite pagini. Pentru a face asta, trebuie doar să adăugați următoarele directive condiționale înainte de primul bloc de locație{} din blocul dvs. de server{}.
set $skip_cache 0;
# POST requests and URLs with query strings won't be cached
if ($request_method = POST) {
set $skip_cache 1;
}
if ($query_string != "") {
set $skip_cache 1;
}
# URIs containing the following segments won't be cached
if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") {
set $skip_cache 1;
}
# Don't serve cache for logged-in users or recent commentators
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
set $skip_cache 1;
}Directivele de mai sus vor instrui NGINX să ignore difuzarea conținutului în cache pentru solicitările POST, solicitările URL cu șiruri de interogare atașate acestora, ecranele de administrare, paginile pentru utilizatorii conectați și alte câteva pagini.
Apoi, adăugați următoarele directive în blocul PHP locație{}.
fastcgi_cache_bypass $skip_cache; fastcgi_no_cache $skip_cache; fastcgi_cache COMUNITATEAWORDPRESS; fastcgi_cache_valid 60m; add_header X-FastCGI-Cache $upstream_cache_status;
Directiva fastcgi_cache_bypass definește când va fi omisă memoria cache a serverului, în timp ce directiva fastcgi_no_cache specifică condițiile în care niciun răspuns server nu va fi salvat în cache.
Valoarea din directiva fastcgi_cache ar trebui să se potrivească cu valoarea keys_zone pe care ați setat-o înainte. În cazul meu, este COMUNITATEAWORDPRESS.
De asemenea, puteți specifica pentru cât timp este valabilă memoria cache FastCGI. Valoarea implicită este setată la 60 de minute. Este o durată decentă pentru majoritatea site-urilor. Totuși, îl puteți schimba la durata dorită.
Dacă modificați valoarea fastcgi_cache_valid și o setați la o altă durată, atunci este o idee excelentă să actualizați și valoarea parametrului inactiv. L-ați definit mai devreme în directiva fastcgi_cache_path.
Parametrul inactiv specifică timpul maxim în care serverul permite oricărei date din cache să rămână în memoria sa fără a fi apelat. Dacă nu este accesat în intervalul de timp specificat, serverul va elimina memoria cache.
Ultima linie adaugă antetul X-FastCGI-Cache la răspunsurile HTTP ale serverului dvs. Îl puteți folosi pentru a valida dacă cererile către site-ul dvs. sunt servite din memoria cache FastCGI sau nu.
Odată ce sunteți mulțumit de configurație, salvați fișierul, părăsiți editorul și apoi reporniți NGINX.
sudo service nginx restart
Ultimul pas pentru a configura NGINX să funcționeze cu site-ul dvs. WordPress este să instalați pluginul gratuit Nginx Cache de la Till Krüss. După activarea pluginului, accesați Instrumente > panoul Nginx din tabloul de bord WordPress și setați Calea zonei cache. Ar trebui să fie același cu cel pe care l-ați definit mai devreme în fișierul NGINX hosts.
De asemenea, puteți activa ștergerea automată a memoriei cache NGINX în același panou de setări. De fiecare dată când modificați orice conținut de pe site-ul dvs., acesta va șterge automat memoria cache NGINX.
Pluginul Nginx Cache vă permite să curățați cache-ul manual prin pagina de setări și bara de administrare. Nginx Helper este un alt plugin grozav pe care îl puteți instala pentru a automatiza multe alte funcții NGINX.
Acum că ați învățat cum să memorați în cache paginile în mod selectiv pe site-ul dvs. WordPress, puteți aplica aceeași logică pentru a specifica reguli personalizate de cache FastCGI pentru site-urile WordPress dinamice create cu WooCommerce, BuddyPress sau Easy Digital Downloads.
De exemplu, dacă aveți un site de comerț electronic care rulează pe WooCommerce, nu ar trebui să stocați în cache contul de utilizator, coșul de cumpărături sau paginile de plată, deoarece acestea sunt unice pentru fiecare utilizator. Pentru a rezolva această problemă, puteți configura excluderi suplimentare din cache prin extinderea directivelor condiționate pe care le-ați folosit mai devreme.
if ($request_uri ~* "/(cart|checkout|my-account)/*$") {
set $skip_cache 1;
}Trebuie să lipiți directiva condiționată de mai sus în aceeași locație în care le-ați introdus mai devreme.
Acest fragment de cod îl instruiește pe NGINX să nu memoreze în cache paginile implicite ale WooCommerce, cum ar fi paginile Coș, Checkout și Contul meu. De asemenea, puteți utiliza expresii regex pentru a adăuga și mai multe pagini la lista de excludere a memoriei cache.
Trebuie să rețineți că memoria cache încă nu funcționează pentru utilizatorii conectați, deoarece li se afișează pagini extrem de personalizate. Pentru a stoca în cache paginile accesate de utilizatorii conectați, puteți stoca în cache în mod selectiv toate elementele statice ale unei pagini web dinamice, utilizând o tehnică avansată numită stocarea în cache a fragmentelor. Deși este destul de complex, merită verificat.
Majoritatea pluginurilor WordPress care creează pagini foarte dinamice ar trebui să aibă o documentație extinsă despre cum să-și excludă paginile dinamice din cache. WP Rocket joacă bine cu serverele NGINX după câteva modificări simple. Consultați Configurația NGINX pentru WP Rocket pentru mai multe informații.
Conținut Dinamic în Cache Folosind Varnish
Varnish este unul dintre cele mai populare acceleratoare HTTP și proxy inverse utilizate astăzi. Este axat exclusiv pe HTTP și este conceput pentru a accelera site-urile web dinamice cu conținut intens.
Varnish Cache folosește un limbaj de configurare specific domeniului numit Varnish Configuration Language (VCL). Dacă sunteți familiarizat cu limbajul de programare C, veți găsi că VCL este similar. Este un limbaj extrem de flexibil care vă oferă independența de a testa și implementa Varnish așa cum doriți.
De exemplu, dacă doriți ca Varnish Cache să ignore solicitările AJAX, iată cum îl implementați:
if (req.http.X-Requested-With == "XMLHttpRequest") {
return(pass);
}
Similarly, if you want to instruct Varnish Cache to skip caching WordPress admin screens and edit pages, you need to add the following VCL code snippet to your config file.
if (req.url ~ "(wp-admin|post\.php|edit\.php|wp-login)") {
return(pass);
}
if (req.url ~ "/wp-cron.php" || req.url ~ "preview=true") {
return (pass);
}Să începem cu Varnish pe Site-ul tău WordPress!
Dacă serverul dvs. web rulează pe Ubuntu, iată un ghid rapid pentru a instala și configura Varnish. Alternativ, puteți parcurge și acest tutorial pas cu pas pentru a activa Varnish Cache pe site-ul dvs. WordPress.
După ce v-ați configurat serverul să folosească Varnish pentru a stoca în cache conținutul, puteți apoi direcționa WordPress să se ocupe de restul. Site-urile WordPress cu conținut în mare parte static nu vor avea nevoie de prea multe modificări. Există o mulțime de pluginuri de ajutor care vă ajută să vă optimizați și mai mult configurația Varnish Cache. Iată câteva dintre cele mai preferate:
De fiecare dată când modificați o postare sau o pagină de pe site-ul dvs. web, Proxy Cache Purge va trimite automat o solicitare PURGE în numele adresei URL. De exemplu, atunci când editați, publicați sau ștergeți o postare, Proxy Cache Purge își va șterge automat vechiul cache. Același lucru este valabil și pentru a comenta o postare sau pentru a schimba tema site-ului dvs.
Puteți modifica configurația lui Varnish Cache pentru a ignora anumite pagini de la cache.
WPBase Cache este un plugin specializat care optimizează implementarea WordPress pe o stivă de server care cuprinde varnish + nginx + php-fpm + php-apc. Folosește trei tipuri de cache pentru a vă supraîncărca site-ul web: cache de pagină completă, cache db și opcode cache.
Acest plugin integrează codul din pluginurile de ajutor nginx-compatibility și db-cache-reloaded-fix. Sunt remedieri pentru nginx și, respectiv, cache-ul bazei de date.
WPBase Cache acceptă și configurarea Varnish Cache cu fișierul default.vcl furnizat. Puteți afla mai multe despre caracteristicile și beneficiile WPBase Cache pe site-ul său web.
Suplimentul Varnish de la WP Rocket vă permite să curățați atât cache-ul Varnish, cât și cache-ul WP Rocket în același timp. Pe lângă faptul că permite interoperabilitatea fără a provoca conflicte, suplimentul va asigura că conținutul oferit utilizatorilor dvs. este întotdeauna actualizat.
Cu suplimentul Varnish instalat, vă puteți relaxa știind că atât Varnish, cât și WP Rocket sunt compatibile între ele și pot lucra împreună. Pentru mai multe informații, consultați documentația WP Rocket despre suplimentul Varnish.
Am terminat de configurat Varnish Cache pentru a stoca în cache și a difuza conținut static. Dar cum rămâne cu stocarea pentru Conținut Dinamic în Cache? Soluția este utilizarea modulelor Varnish (VMOD) pentru a extinde caracteristicile Varnish Cache.
Noile VMOD XBody și Edgestash de la Varnish 6.0 vă permit să stocați în cache și să accelerați conținutul dinamic cu ușurință.
XBody VMOD preia tot conținutul dinamic de pe pagina web și îl analizează în formatul de schimb de date JSON și un șablon web Mustache.
Mai târziu, Edgestash VMOD preia atât datele JSON, cât și șablonul Mustache, apoi le recombină înapoi într-un nou răspuns. Puteți consulta documentația Varnish Software despre memorarea în cache personalizată pentru a afla mai multe despre cum se face.
Conținut Dinamic în Cache Folosind WP Rocket
Pluginurile avansate de stocare în cache precum WP Rocket pot detecta în mod inteligent care active sunt statice sau dinamice și pot stoca în cache doar conținutul static. De asemenea, actualizează cache-ul automat ori de câte ori este actualizat orice conținut static.
WP Rocket dezactivează memorarea în cache în mod implicit pentru pagini dinamice, cum ar fi coșul de cumpărături, finalizarea comenzii, profilurile de utilizator etc. De asemenea, vă permite să dezactivați manual cache pentru pagini.
Dacă aveți pagini cu mult conținut static și câteva elemente dinamice, atunci puteți încă stoca acele pagini prin servirea elementelor dinamice prin JavaScript/AJAX. Deoarece JS rulează pe partea client (sau browser), elementele dinamice vor fi actualizate pe pagina stocată în cache oferită utilizatorului.
Puteți citi acest tutorial AJAX pas cu pas pentru a afla cum puteți actualiza în mod dinamic conținutul de pe site-ul dvs. WordPress.
De asemenea, puteți utiliza WP Rocket pentru a stoca în cache pagini cu conținut dinamic. WooCommerce oferă o modalitate fără efort de a ajaxifica vizualizatorul de coș prin adăugarea unui fragment de cod simplu.
Concluzie
Memorarea în cache nu mai este doar pentru site-uri statice sau bazate pe evenimente. Ați văzut mai sus multe opțiuni pentru a stoca în cache site-uri WordPress foarte dinamice. Deși inițial necesită unele configurații și ajustări, rezultatul final merită efortul. Conținut Dinamic în Cache vă ajută să îmbunătățiți timpul pentru Time to First Byte al site-ului dvs. (TTFB), să reduceți costurile de găzduire, să obțineți un SEO mai bun și să vă creșteți ratele de conversie.
Prin extinderea memoriei cache pentru a include și conținut dinamic, puteți avea un efect dramatic asupra performanței site-ului dvs. De asemenea, se va asigura că utilizatorii dvs. primesc cele mai recente informații actualizate rapid.
Și dacă doriți să mergeți mai departe, WP Rocket funcționează imediat cu majoritatea soluțiilor de stocare în cache la nivel de server discutate în acest articol. Este timpul să vă supra-alimentați site-ul web cu WP Rocket acum!
