Găzduirea lacurilor

Dacă doriți să optimizați și să accelerați deschiderea site-ului dvs. WordPress, WooCommerce sau alt site, cu siguranță veți fi întâlnit cu postări și sfaturi care v-au spus despre instalarea software-ului sau a pluginurilor Cache.

Dacă ai avut noroc, ai fi auzit și niște profesioniști vorbind despre asta Cache de lac, mai degrabă decât Cache inutil pe partea de plugin sau serverul Cache mai banal și mai puțin funcțional NGINX FastCGI Cache.

Ce este Varnish Cache?

Dar ce anume este lac și de ce este cea mai bună alegere dacă decideți să accelerați experiența de utilizare a site-ului dvs. web?

Varnish Cache este un software puternic pe partea de server, scris în limbajul de programare C, recunoscut pentru performanța remarcabilă. Proiectarea și dezvoltarea sa au fost ghidate de concepte stabilite și de cele mai bune practici de dezvoltare a software-ului, inclusiv managementul dinamic al memoriei, implementarea firelor, utilizarea memoriei partajate și utilizarea socket-ului standard POSIX, printre altele. Aceste mecanisme rafinate ar fi imposibil de fezabil cu un limbaj interpretat precum PHP.

Spre deosebire de cache-urile PHP menționate, care intră în joc numai după ce codul cache PHP a fost executat și un proces de interpret PHP a fost generat prin firele PHP-FPM (Fast Process Manager), Varnish Cache intră imediat. Nu implică deloc PHP sau generarea de noi fire și procese, reducând semnificativ sarcina CPU. Acest aspect este deosebit de avantajos atunci când aveți de-a face cu niveluri foarte mari de trafic web, care poate ajunge la mii sau chiar zeci de mii de vizitatori concurenți.

De fapt, într-o găzduire WordPress gestionată cu trafic ridicat, utilizarea Varnish în stiva noastră de software ne permite să gestionăm site-uri care au peste 45 de milioane de vizitatori unici pe lună, peste 200 de milioane de vizualizări de pagini și vârfuri de peste 100.000 de utilizatori pe minut.

Pentru a ilustra acest punct, să luăm în considerare captura de ecran de mai jos din Google Analytics a unuia dintre clienții noștri. Acest site atrage până la 85 de milioane de vizitatori pe lună, demonstrând astfel scalabilitatea și rezistența oferite de Varnish Cache.

Mulți vizitatori, multe fire PHP?

Una dintre cele mai frecvente neînțelegeri în rândul administratorilor de site-uri web care gestionează un volum mare de trafic, cu vârfuri de vizitatori atingând mii pe minut, se referă la gestionarea PHP-FPM Listeners. Greșeala comună este încercarea de a crește numărul de ascultători PHP-FPM pentru a gestiona mai multe conexiuni și solicitări primite.

Raționamentul care ghidează adesea această decizie poate fi rezumat după cum urmează:

Dacă am 1000 de utilizatori pe minut, în loc să setez ascultătorii PHP-FPM la 32, îi pot configura la 512. În acest fel, voi putea gestiona mai multe solicitări.

Aceasta este o capcană în care cad mulți, crezând în mod eronat că creșterea valorii numărului de ascultători PHP-FPM este suficientă pentru a gestiona mai multe solicitări.

Cu toate acestea, realitatea se dovedește a fi foarte diferită. Deși este posibil să creșteți numărul de ascultători PHP-FPM cu o simplă modificare a fișierului de configurare a pool-ului relevant, hardware-ul fizic de bază nu poate fi adaptat la fel de ușor. De exemplu, dacă sistemul dvs. are 8 nuclee, setarea a 512 fire ar putea să nu fie cea mai înțeleaptă alegere. De fapt, aceste thread-uri vor mai trebui executate pe cele 8 nuclee disponibile, implicând activarea multiplexării și programarii procesorului. Acest mecanism va determina rularea mai multor procese, dar cu timpi de execuție redusi, fiind astfel mai lent.

Pe măsură ce procesorul lucrează pentru a gestiona operațiunile din pool-ul 512, noi solicitări primite vor începe să se adună. Acestea se vor adăuga la coada de solicitări anterioare și, în câteva minute, această coadă ar putea deveni atât de lungă încât durează minute sau chiar zeci de minute pentru procesare. Acest lucru duce la timeout-uri enervante, cum ar fi o eroare 502 Gateway Timeout sau 502 Bad Gateway.

În concluzie, deși pare o soluție intuitivă, creșterea numărului de ascultători PHP-FPM nu este întotdeauna răspunsul optim pentru a gestiona un aflux mare de utilizatori. Mai degrabă, o înțelegere adecvată a funcționării de bază a hardware-ului și software-ului sistemului poate ajuta la găsirea unor strategii mai eficiente pentru a gestiona concurența ridicată a cererilor.

PHP e de rahat. MySQL e de rahat. Apache și NGINX suge. WordPress? De asemenea.

Nu este neobișnuit să auzi critici dure la adresa PHP, MySQL, Apache, NGINX și WordPress. Da, tocmai am afirmat asta și da, poate sună puțin cinic. Totuși, intenția mea nu este de a denigra aceste tehnologii, ci mai degrabă de a sublinia o realitate concretă: dacă PHP și MySQL ar fi la fel de rapide ca tehnologiile mai moderne precum Node.js, GoLang sau bazele de date noSQL precum Redis.io și MongoDB, utilizarea serviciilor de cache ar fi probabil superfluă.

Din păcate, lumea digitală nu este așa. De exemplu, multe dintre cele mai importante CMS continuă să se bazeze pe stiva PHP + MySQL, ceea ce face ca munca noastră și utilizarea unor soluții precum Varnish să fie încă necesare. Și, în ciuda criticilor, asta ne oferă o oportunitate reală. O oportunitate care se traduce în valoare tangibilă: posibilitatea de a obține performanțe mai mari folosind hardware mai ieftin.

În cele din urmă, ceea ce derivă din aceasta este un dublu avantaj care urmează bazele cercetării operaționale: maximizarea profiturilor minimizând costurile. Așadar, în loc să devalorizăm PHP, MySQL, Apache, NGINX și WordPress, am putea mai degrabă să le recunoaștem rolul în peisajul tehnologic actual și să lucrăm pentru a le optimiza performanța cu instrumente adecvate precum Varnish, astfel încât să obținem beneficii maxime de pe urma prezenței lor.

Varnish Cache în practică.

Varnish funcționează practic prin stocarea cererilor GET, ca o pagină web obișnuită, în stocarea sa. Acesta din urmă poate locui fizic atât pe disc, cu avantaje în ceea ce privește capacitatea de stocare, cât și în RAM, care oferă în schimb avantaje în ceea ce privește viteza de acces și deci latența redusă.

Să ne imaginăm că un utilizator navighează la https://www.sitoexample.it/company din browserul său. Funcționarea Varnish în această împrejurare prevede ca software-ul să verifice inițial dacă pagina solicitată este deja prezentă în cache-ul său. Dacă răspunsul este da, Varnish va furniza prompt pagina utilizatorului. În caz contrar, cererea va fi TRANSMISĂ la backend-ul serverului web, care este de obicei reprezentat de Apache sau NGINX.

Aceste servere web vor declanșa, la rândul lor, execuția codului PHP și vor trimite interogări aferente bazei de date MySQL pentru a genera pagina HTML solicitată. Odată generată, pagina este returnată la serverul web, este stocată în cache pentru utilizare ulterioară și în final trimisă în browserul utilizatorului. Astfel, utilizatorul va putea în sfârșit să vizualizeze pagina companiei pe site-ul exemplu.

Să presupunem că, la prima vizită, pagina durează o secundă pentru a se genera, cu o întârziere suplimentară de 50 de milisecunde pentru livrarea către browserul vizitatorului. Acum, la a doua vizită, deoarece pagina a fost deja memorată de Varnish, nu va fi necesară generarea din nou a paginii, dar va fi suficient să o trimiteți utilizatorului. Prin urmare, în loc să dureze 1 secundă și 50 de milisecunde, va dura doar 50 de milisecunde pentru a căuta pagina în memoria cache Varnish și încă 50 de milisecunde pentru a o livra utilizatorului. Ca urmare, timpul total de răspuns merge de la 1,050 milisecunde la 100 milisecunde, o economie de 1500%. Acest lucru demonstrează modul în care Varnish poate avea un impact semnificativ asupra vitezei de încărcare a paginii și, în consecință, asupra experienței utilizatorului.

Este evident că în descriere tocmai am dat caracteristici importante ale lacului, cum ar fi hashing, preluarea, decuparea cookie-urilor, parametrii și așa mai departe, au fost omise de dragul narării. funcții absolut vitale în unele cazuri care fac ca Lacul să fie exact flagship al software-ului de cache.

În acest scurt videoclip în limba engleză de la compania-mamă Varnish-Software puteți înțelege într-un mod foarte elementar semnificația unui software Cache precum Varnish.

Cache de lac. Mari puteri, mari responsabilități.

La fel ca supereroii din benzi desenate și filme, simbolizați în mascota Varnish Cache ca un iepuraș super-erou, marea putere vine cu o mare responsabilitate.

Varnish este, fără îndoială, unul dintre cele mai bune software de web caching disponibile (să spunem chiar cel mai bun), dar, în același timp, este un software „simplu” în sensul că face doar ceea ce este configurat pentru a face. Acest lucru implică faptul că o configurație exactă și precisă, atât a lui Varnish, cât și a aplicației pe care intenționați să o utilizați cu acesta, este absolut esențială. pentru cele mai bune rezultate.

Există câteva întrebări pe care fiecare dezvoltator, administrator de sistem și utilizator de Varnish ar trebui să le pună în timpul fazei de configurare, cum ar fi:

Cât trebuie să dureze memoria cache?

Durata memoriei cache este un aspect crucial de luat în considerare atunci când configurați Varnish. Acest lucru se datorează faptului că timpul de păstrare a informațiilor din cache poate varia foarte mult în funcție de tipul de conținut și de frecvența de actualizare a acestuia.

Să luăm de exemplu pagina de prezentare instituțională a unei companii. Acest tip de conținut se schimbă rar, poate o dată sau de două ori pe an. Prin urmare, pentru acest tip de pagină, setarea unei durate de cache foarte mare ar putea fi adecvată, deoarece aceasta ar permite ca pagina să fie servită foarte rapid tuturor vizitatorilor, fără a fi nevoie să reîncărcați informațiile de pe server la fiecare solicitare.

Pe de altă parte, dacă luăm în considerare un blog care raportează știri despre fotbal în timp real în timpul unui meci din Serie A, situația se schimbă drastic. În acest scenariu, orice acțiune semnificativă în meci, cum ar fi un cartonaș, un cartonaș roșu, un penalty sau un gol, ar putea necesita o reîmprospătare imediată a paginii. În acest caz, setarea duratei cache-ului prea lungă vă poate împiedica să oferiți utilizatorilor actualizări în timp util și relevante. Prin urmare, ar fi înțelept să configurați o durată de cache mult mai scurtă sau chiar să dezactivați complet memorarea în cache în timpul evenimentelor live.

Durata memoriei cache ar trebui să fie ponderată cu atenție în funcție de natura conținutului site-ului și de cât de des este actualizat. Această considerație ajută la echilibrarea nevoii de a furniza conținut actualizat cu nevoia de a menține o capacitate de răspuns ridicată a site-ului.

Cum gestionez paginile AMP cu Cache?

Gestionarea paginilor mobile accelerate (AMP) într-un mediu cache, precum cel oferit de Varnish, prezintă o provocare interesantă. Odată cu introducerea AMP, s-au schimbat multe aspecte ale clasării motoarelor de căutare, SEO în timp real și servicii bazate pe trafic cu plăți mari, cum ar fi Știri Google. Printre cele mai frecvente probleme care apar în acest context se numără gestionarea paginilor AMP.

AMP este un cadru dezvoltat de Google pentru a îmbunătăți viteza și gradul de utilizare a site-urilor web pe dispozitive mobile. Paginile AMP sunt versiuni simplificate ale paginilor web standard, concepute pentru a se încărca rapid pe dispozitivele mobile. Acest lucru are un impact semnificativ asupra SEO, deoarece Google tinde să favorizeze paginile AMP în rezultatele căutării mobile.

Când utilizați un sistem de stocare în cache precum Varnish, este important să luați în considerare modul de gestionare a paginilor AMP. În special, atunci când conținutul unei postări este actualizat, este esențial să anunțați Google că și versiunea AMP a postării a fost modificată. Acest lucru se datorează faptului că dacă conținutul AMP nu este actualizat corespunzător, pot exista discrepanțe între versiunea standard a paginii și cea AMP, ceea ce poate duce la penalități în rezultatele căutării Google.

Strategia ideală pentru gestionarea paginilor AMP poate depinde de diverși factori, inclusiv tipul de conținut de pe site, frecvența actualizărilor și natura publicului. O posibilitate ar fi să setați o durată mai scurtă a memoriei cache pentru paginile AMP, pentru a vă asigura că acestea sunt actualizate mai frecvent. O altă opțiune ar fi utilizarea unui sistem de invalidare a memoriei cache, care permite ca anumite pagini să fie eliminate din cache atunci când conținutul original este actualizat.

În orice caz, este esențial să monitorizați îndeaproape performanța site-ului și metricile SEO pentru a vă asigura că strategia adoptată este eficientă și nu creează probleme neașteptate.

Cum gestionăm cookie-urile inutile, le lăsăm să treacă?

Gestionarea cookie-urilor poate fi un lucru deosebit de complicat când vine vorba de stocarea în cache, în special cu software precum Varnish. Acest lucru se datorează faptului că prezența unui cookie ar putea determina Varnish să considere o solicitare ca „personalizată” pentru un anumit utilizator și, în consecință, să nu folosească memoria cache.

Uneori, s-ar putea să întâlniți pluginuri sau coduri care setează cookie-uri pe server în mod inutil, provocând o invalidare a memoriei cache chiar și atunci când nu este necesar. Acest comportament poate reduce drastic eficiența stocării în cache și, ca urmare, poate încetini site-ul.

Cea mai bună strategie pentru a face față acestei situații poate depinde de diverși factori, inclusiv de natura cookie-ului și de implicațiile sale potențiale pentru experiența utilizatorului și funcționalitatea site-ului. Dacă cookie-ul este cu adevărat inutil și nu are niciun impact asupra funcționalității site-ului sau asupra experienței utilizatorului, este posibil să-l ștergeți complet. Acest lucru se poate face prin modificarea codului care generează cookie-ul sau prin configurarea Varnish pentru a ignora sau elimina anumite module cookie.

Cu toate acestea, înainte de a lua această decizie, este important să luați în considerare cu atenție consecințele posibile. Unele cookie-uri, chiar dacă pot părea inutile la prima vedere, ar putea juca un rol important pentru unele caracteristici ale site-ului sau pentru respectarea legilor și reglementărilor, cum ar fi cele referitoare la confidențialitate și protecția datelor.

Prin urmare, atunci când vine vorba de gestionarea cookie-urilor într-un context de stocare în cache, este important să procedați cu prudență și, de preferință, cu asistența unui expert în dezvoltare web sau a unui consultant SEO. De asemenea, este esențial să testați cu atenție orice modificări pe care le faceți pentru a vă asigura că nu au efecte negative neașteptate asupra site-ului sau experienței utilizatorului.

Dar fișierele mari?

Când vine vorba de gestionarea fișierelor mari într-un mediu de stocare în cache, cum ar fi cel oferit de Varnish, este important să luați în considerare cu atenție avantajele și dezavantajele. Pe de o parte, stocarea în cache a fișierelor mari, cum ar fi imagini de înaltă rezoluție, fișiere ISO sau arhive ZIP sau RAR poate părea o idee bună pentru a accelera încărcarea acestor elemente. Cu toate acestea, pe de altă parte, există câteva considerații importante de reținut.

În primul rând, stocarea în cache a fișierelor mari poate ocupa mult spațiu de stocare. Aceasta poate să nu fie o problemă pentru site-urile cu o cantitate limitată de conținut mare, dar pentru site-urile care găzduiesc un număr mare de astfel de fișiere, resursele de stocare pot deveni rapid o problemă. De asemenea, dacă hardware-ul de bază nu este la înălțime, poate exista o încetinire generală a sistemului din cauza sarcinii de gestionare a fișierelor mari.

În al doilea rând, poate exista o problemă cu latența. Dacă un utilizator solicită descărcarea unui fișier mare și Varnish trebuie să încarce mai întâi acel fișier în memoria cache, este posibil ca utilizatorul să fie nevoit să aștepte mai mult pentru ca descărcarea să înceapă. În unele cazuri, ar putea fi mai eficient să transmiteți cererea direct către serverul web, care poate începe imediat să trimită fișierul către utilizator.

În cele din urmă, este important să ne amintim că fișierele mari, în special cele precum fișierele ISO sau arhivele ZIP sau RAR, tind să fie descărcate mai rar decât alte tipuri de conținut. Ca rezultat, beneficiul memorării în cache a acestor fișiere poate să nu fie atât de mare pe cât s-ar putea crede.

Prin urmare, atunci când vine vorba de gestionarea fișierelor mari cu Varnish, cea mai bună strategie poate depinde de tipul specific de site și de publicul acestuia. Poate doriți să vă uitați la statisticile de acces ale site-ului dvs. pentru a determina ce fișiere sunt descărcate cel mai frecvent și să vă gândiți dacă este logic să memorați aceste fișiere în cache. De asemenea, ar trebui să monitorizați îndeaproape performanța site-ului și să efectuați teste pentru a determina efectul stocării în cache a fișierelor mari asupra performanței generale a site-ului.

Cum gestionez paginile de utilizator ale unui comerț electronic?

Gestionarea paginilor utilizatorului într-un comerț electronic, mai ales într-un mediu care utilizează o soluție de cache precum Varnish, necesită o atenție deosebită. Există câteva aspecte cruciale de luat în considerare pentru a asigura o experiență de utilizator fluidă și sigură, respectând în același timp reglementările privind confidențialitatea, cum ar fi GDPR în Europa.

Primul aspect se referă la cărucior. Când un client adaugă articole în coșul său într-un magazin de comerț electronic precum WooCommerce, aceste date sunt specifice utilizatorului respectiv și nu ar trebui să fie partajate sau făcute vizibile pentru alți clienți. Dacă căruciorul este memorat incorect în cache de către Varnish, pot apărea probleme, cum ar fi afișarea coșului unui alt utilizator. Pentru a evita acest lucru, trebuie să configurați Varnish să nu memoreze în cache paginile coșului. În general, toate paginile care conțin date sensibile și specifice utilizatorului nu ar trebui să fie stocate în cache.

Al doilea aspect se referă la zona privată a utilizatorului, unde pot fi vizualizate detaliile contului său, precum informațiile de facturare și istoricul comenzilor. Aceste pagini sunt foarte personalizate și conțin date sensibile. Prin urmare, ca și în cazul coșului de cumpărături, aceste pagini nu ar trebui să fie stocate în cache. Este esențial să ne asigurăm că fiecare utilizator poate vedea doar propriile date și nu pe cele ale altor clienți.

În rezumat, orice pagină sau secțiune a unui site de comerț electronic care conține informații specifice utilizatorului sau date sensibile ar trebui exclusă din memoria cache. Acest lucru poate necesita o configurare atentă a Varnish, precum și o înțelegere clară a cerințelor specifice ale magazinului de comerț electronic. Această abordare nu numai că asigură o experiență mai bună pentru utilizator, dar vă ajută și să respectați reglementările de confidențialitate precum GDPR. Este important de subliniat că configurația Varnish trebuie gestionată de profesioniști cu experiență pentru a evita erorile care ar putea compromite securitatea și confidențialitatea datelor utilizatorului.

Cum gestionez adresele URL de urmărire parametrică precum fbclid sau utm cu Varnish?

Problema parametrilor de urmărire precum „fbclid” în URL-uri, folosiți frecvent în campaniile de marketing online, prezintă o provocare pentru optimizarea cache-ului cu Varnish. Într-adevăr, pentru fiecare adresă URL unică, Varnish creează o versiune separată în cache. Prin urmare, dacă parametrul „fbclid” se modifică pentru fiecare utilizator care face clic pe un link de pe Facebook, Varnish va trata fiecare cerere ca fiind unică, ocolind memoria cache și încetinind viteza site-ului ca și când nu ar exista cache.

Cu toate acestea, este posibil să gestionați această situație într-un mod elegant și eficient, fără a compromite funcționalitatea de urmărire a unor parametri precum „fbclid” sau „UTM” de către Google.

O soluție poate fi configurarea Varnish pentru a normaliza adresele URL prin eliminarea sau ignorarea anumitor parametri ai șirurilor de interogare. Acest lucru se poate face prin limbajul de configurare Varnish (VCL). În funcțiune vcl_recv, puteți adăuga cod care rescrie adresa URL, eliminând anumiți parametri de interogare. Cu toate acestea, este important de menționat că această acțiune nu va afecta funcționalitatea de urmărire, deoarece parametrii vor fi pur și simplu eliminați până când solicitarea ajunge la Varnish, dar vor fi în continuare prezenți atunci când solicitarea inițială este făcută din browserul utilizatorului.

De asemenea, o altă posibilitate ar fi să folosiți o funcție hash în Varnish. În VCL, puteți personaliza funcția vcl_hash pentru a ignora anumiți parametri URL atunci când Varnish decide dacă o pagină este sau nu în cache.

În acest fel, vă puteți asigura că site-ul dvs. WooCommerce rulează la cea mai rapidă viteză posibilă, indiferent de campaniile de publicitate pe care le desfășurați, fără a pierde capacitatea de a urmări în mod eficient originea traficului către site-ul dvs.

Cum folosesc Varnish cu HTTPS?

Utilizarea Varnish împreună cu HTTPS poate părea o mică provocare, având în vedere presupusa incompatibilitate dintre sistemul de cache al lui Varnish și protocolul HTTPS. Într-adevăr, această presupunere a determinat mulți furnizori de servicii web, atât în ​​Italia, cât și la nivel internațional, să abandoneze Varnish în favoarea unor soluții precum LiteSpeed ​​​​Cache. Cu toate acestea, putem spune cu încredere că, cu o configurație adecvată, Varnish poate fi utilizat eficient cu HTTPS, iar experiența noastră este dovada vie a acestui lucru.

Varnish în sine nu acceptă direct HTTPS. Cu toate acestea, asta nu înseamnă că nu poate fi utilizat într-un mediu care necesită HTTPS. Pentru a ocoli această limitare, puteți utiliza un proxy invers precum NGINX sau Hitch în fața lui Varnish. Aceste servere pot gestiona conexiunile HTTPS, le pot decripta și apoi pot transmite cereri HTTP către Varnish. În acest fel, puteți profita de puterea și performanța Varnish, menținând în același timp securitatea oferită de HTTPS.

Mai mult, implementarea Varnish cu HTTPS ne-a permis să profităm de protocolul HTTP/2 și, de asemenea, HTTP/3, care oferă alte avantaje în ceea ce privește performanța. HTTP/2 permite multiplexarea cererilor, ceea ce înseamnă că cererile multiple pot fi trimise simultan prin aceeași conexiune, economisind timp și resurse server.

Alegerea de a continua să utilizați Varnish, adaptându-l pentru utilizare cu HTTPS și HTTP2, sa dovedit a fi o decizie câștigătoare pentru noi. Această alegere a dus la o îmbunătățire semnificativă în ceea ce privește calitatea serviciilor oferite și a contribuit la dublarea profiturilor și a cifrei de afaceri din ultimul an. Succesul pe care l-am experimentat demonstrează că versatilitatea și performanța Varnish pot face cu adevărat diferența pe o piață competitivă precum găzduirea web.

Instalarea Varnish Supercache este diferită de a face ca Vernisul să funcționeze.

Implementarea Varnish Supercache nu se limitează la o instalare de bază - pentru a profita la maximum de Varnish necesită un proces mult mai complex.

S-ar putea să fii tentat să folosești Varnish printr-una dintre găzduirile care îl oferă ca soluție preconfigurată. Dar este vital să înțelegeți că instalarea sau achiziționarea Varnish ca serviciu de la un furnizor de găzduire nu garantează funcționalitatea completă a acestui instrument puternic de stocare în cache. Varnish necesită o configurare atentă pe server, în funcție de nevoile specifice ale proiectului dumneavoastră, precum și o setare precisă pe backend-ul site-ului dumneavoastră WordPress, pentru a asigura funcționarea corectă a tuturor funcțiilor de curățare a cache-ului (purge), sitemap-uri , din paginile AMP, articolele instantanee, paginile utilizatorului, gestionarea cookie-urilor și multe altele.

Dacă soluția care ți se propune nu este personalizată și nu include suportul unui administrator de sistem expert care te asiste în toate fazele inițiale – de la migrare, la configurare, la tuning – atunci este probabil să fii pe cale să cumperi ceva care ar putea cauza probleme serioase site-ului dvs. pe termen scurt sau mediu. De exemplu, neactualizarea sitemapurilor dvs. ar putea împiedica noile dvs. articole să fie indexate de Google; o defecțiune a AMP vă poate exclude din Știri Google; și alte probleme potențial și mai grave ar putea duce, în cazurile cele mai extreme, la dezactivarea site-ului dvs.

În cel mai bun caz, s-ar putea să ajungeți cu Varnish instalat pe serverul dvs., dar să nu reușiți să memorați corect datele în cache, permițând astfel tuturor solicitărilor să meargă direct la serverul web și, în consecință, la PHP și MySQL.

Dacă scopul tău este să optimizezi viteza unui site WordPress sau WooCommerce, să gestionezi vârfurile mari de trafic și un număr mare de utilizatori, te putem ajuta. Oferim cele mai bune solutii tehnologice si sistemice la cel mai bun pret.

Nu ezitați să ne contactați pentru a afla cum vă putem sprijini proiectul.