Găzduire și module WordPress
Optimizarea WordPress pentru viteză și securitate: o listă de verificare pentru performanță și module
WordPress este doar atât de rapid și de sigur pe cât este infrastructura pe care rulează. Iată lista practică de verificare pe care o aplicăm fiecărui site WordPress pe care îl găzduim — ce să stocați în memoria cache, ce să securizați și ce pluginuri își merită locul în comparație cu cele pe care platforma le face redundante.
WordPress este la fel de bun ca mediul pe care rulează
WordPress alimentează o mare parte a webului pentru că este flexibil, dar această flexibilitate este și motivul pentru care devine lent și nesigur: o instalare implicită interoghează baza de date de zeci de ori pe pagină, își transmite versiunea și stiva tehnologică oricui se uită și vă invită să adăugați module până când performanța și suprafața de atac se amplifică ambele în mod silențios. Nimic din toate acestea nu este atât un defect al WordPress, cât o consecință a rulării sale pe o infrastructură care nu face nimic pentru a ajuta.
Vestea bună este că aceleași câteva decizii rezolvă cea mai mare parte a problemelor și sunt decizii legate de stivă, mai degrabă decât de conținut. Utilizați o memorare în cache agresivă la nivelul potrivit, mențineți baza de date în afara căii critice, rulați doar acele câteva module care își merită cu adevărat locul, păstrați totul actualizat și izolați site-ul, astfel încât o problemă să rămână localizată. Acest articol reprezintă acea listă de verificare, în ordinea în care o aplicăm pentru fiecare site WordPress de pe platformă.
Stocați în cache pe server, nu doar într-un modul
Cea mai importantă pârghie pentru viteza WordPress este să nu rulați deloc WordPress pentru majoritatea vizitelor. O solicitare standard inițializează WordPress, rulează modulele dumneavoastră și interoghează baza de date înainte de a trimite un singur octet; o memorie cache pentru întreaga pagină servește pagina finalizată direct de pe serverul web la următoarea accesare, omițând întreaga inițializare. Locul în care se află acea memorie cache contează: un modul de cache se află în interiorul PHP, astfel încât PHP pornește înainte ca memoria cache să poată răspunde, în timp ce o memorie cache la nivel de server răspunde mai devreme în cadrul solicitării și păstrează paginile într-o formă pe care serverul o poate goli instantaneu.
Fiecare site WordPress pe care îl găzduim rulează pe LiteSpeed Enterprise cu LSCache la nivel de server, iar propriul nostru modul de cache conectează corect WordPress la acesta încă de la început — preinstalat și actualizat automat, astfel încât reprezintă un lucru în minus de configurat sau de menținut la zi. Pe o origine non-LiteSpeed, același modul pur și simplu nu emite anteturi de pagină completă și nu intervine în timp ce cache-ul de obiecte continuă să funcționeze, astfel încât un site migrat nu rămâne niciodată pe jumătate configurat. Regula practică pentru propria listă de verificare: un singur cache de pagină completă, la nivel de server, și nu suprapuneți un al doilea modul de cache peste acesta — intră în conflict.
Memoria cache pentru obiecte și baza de date
Nu orice solicitare poate fi o pagină statică. Sesiunile autentificate, panoul de administrare, căutarea, coșurile de cumpărături și orice fragment personalizat trebuie să ruleze PHP, iar pentru acestea obiectivul se mută de la evitarea aplicației la evitarea bazei de date. Un cache de obiecte per site — Redis, în cazul nostru — păstrează rezultatele citirilor repetate din baza de date în memorie, astfel încât aceleași opțiuni, tranzienți și căutări să nu fie interogate din baza de date la fiecare accesare. Efectul se manifestă exact acolo unde cache-ul de pagină întreagă nu poate ajuta: un panou de administrare mai rapid, coșuri mai rapide și o încărcare mult mai mică a bazei de date în condiții de trafic intens.
Cuvântul care contează este per-site. O memorie cache partajată pentru obiecte înseamnă că un site aglomerat sau scris prost poate evacua datele memorate în cache ale tuturor celorlalți și poate priva baza de date pentru vecinii săi; o memorie cache dedicată per site, asociată cu limite de bază de date per site, menține acea rază de impact sub control. Pe lista dumneavoastră de verificare, tratați o memorie cache persistentă pentru obiecte ca fiind obligatorie pentru orice site cu utilizatori autentificați sau cu un magazin și fiți precaut cu găzduirea în care aceasta este partajată între mai mulți chiriași.
Pluginurile care merită rulate — și cele pe care platforma le înlocuiește
Fiecare modul pe care îl adăugați reprezintă cod care rulează la solicitări și o ușă pe care cineva ar putea păși într-o zi, așa că obiectivul onest este cel mai mic număr de module care fac cel mai mult. O găzduire bună elimină necesitatea unei întregi categorii dintre acestea: cu stocare în memoria cache la nivel de server, o memorie cache a obiectelor gestionată și copii de rezervă la nivel de platformă, nu aveți nevoie de un modul de cache, de un modul separat de cache a obiectelor sau de un modul de backup — acele sarcini sunt realizate mai bine sub WordPress, iar rularea lor deasupra adaugă doar conflicte și suprasolicitare.
Ceea ce merită să rămână activ este micul set care adaugă capabilități autentice: pluginurile de care site-ul dumneavoastră are într-adevăr nevoie pentru a funcționa și — pe platforma noastră — cele două pluginuri de nivel de depozit oficial pe care le construim și le livrăm cu fiecare site. Pluginul nostru de cache conectează WordPress la memoria cache a serverului și gestionează golirea inteligentă, astfel încât o editare să curețe doar paginile necesare. Pluginul nostru pentru amprenta SEO elimină indiciile pe care o instalare implicită de WordPress le transmite — versiunea și eticheta generator, endpointurile de descoperire, XML-RPC, pingback-urile și antetul powered-by — la fiecare implementare, astfel încât o actualizare de plugin sau temă să nu le poată reintroduce pe furiș. Ambele sunt construite conform standardelor directorului de pluginuri WordPress.org, sunt gratuite și se actualizează automat.
Păstrarea WordPress în siguranță și la zi
Majoritatea compromiterilor WordPress nu sunt sofisticate; sunt vechi. Un nucleu, o temă sau un modul învechit, cu o vulnerabilitate cunoscută și publicată, reprezintă modalitatea covârșitor de comună prin care site-urile sunt afectate, ceea ce face ca menținerea la zi să fie cea mai valoroasă sarcină de securitate existentă — și cea mai anostă, motiv pentru care este omisă. Găzduirea administrată ar trebui să vă scutească de această grijă: aplicând patch-uri pentru stiva din spatele WordPress și făcând actualizările de nucleu și module sigure de aplicat, oferindu-vă o copie de testare pe care să le încercați și o copie de rezervă pentru revenire.
Pe lângă actualitate, așteptați-vă ca limitele să fie aplicate în locul dumneavoastră: scanarea împotriva programelor malware activată în mod implicit, astfel încât o infecție să fie depistată înainte de a fi descoperită de un vizitator, izolare pentru ca un site compromis să nu poată afecta altul, protecție DDoS la nivel de rețea periferică și TLS peste tot, cu certificate reînnoite automat. Nimic din toate acestea nu înlocuiește igiena de bază — date de autentificare puternice, acces bazat pe cel mai mic nivel de privilegii, eliminarea pluginurilor pe care nu le mai utilizați —, dar înseamnă că infrastructura nu este veriga slabă. Pe lista dumneavoastră de verificare, întrebarea pentru orice furnizor de găzduire este simplă: securitatea este o setare implicită sau un pachet suplimentar pe care îl cumpărați?
WooCommerce și paginile pe care nu trebuie să le includeți niciodată în memoria cache
Un magazin este locul în care stocarea agresivă în memoria cache aduce cel mai mare beneficiu și produce cele mai mari daune dacă este făcută naiv. Paginile de catalog, de produse și de categorii sunt paginile cu cel mai mare trafic și cele mai ușor de stocat în cache pe care le aveți, iar servirea lor din memoria cache a întregii pagini este cel mai bun lucru pe care îl puteți face pentru viteza unui magazin. Însă paginile de coș, de finalizare a comenzii și de cont sunt personale și nu trebuie servite niciodată dintr-o memorie cache partajată — dacă faceți asta, un cumpărător va vedea coșul altcuiva, ceea ce înseamnă atât un magazin defect, cât și o încălcare a confidențialității.
Modalitatea de a le avea pe ambele este să stocați pagina în memoria cache și să creați excepții pentru părțile dinamice. Edge Side Includes redau fragmentul de coș, totalurile din mini-coș și starea contului la fiecare solicitare, în timp ce restul paginii este servit din memoria cache, iar paginile de coș, finalizare a comenzii, contul meu și orice pagini cu nonce-uri sau sesiuni sunt excluse în mod implicit. Actualitatea conținutului este gestionată printr-o golire automată inteligentă care se declanșează atunci când se modifică un produs, un preț sau o comandă, astfel încât un preț învechit să nu persiste niciodată. Dacă utilizați WooCommerce, aceasta este partea din lista de verificare pe care trebuie să o implementați impecabil: o vitrină rapidă din memoria cache, un coș dinamic pentru fiecare utilizator și nicio dată personală stocată vreodată în cache.
Întrebări frecvente
Mai am nevoie de un modul de stocare în memoria cache precum WP Rocket?
Nu. Memorarea în cache a întregii pagini este gestionată la nivelul serverului web de LSCache de la LiteSpeed, propriul nostru modul de cache conectează WordPress la acesta și gestionează golirea inteligentă, iar în spatele acestuia se află o memorie cache de obiecte Redis pentru fiecare site. Adăugarea unui al doilea modul de memorare în cache a întregii pagini intră, de obicei, în conflict cu memoria cache de la nivel de server în loc să ajute, astfel încât nu este nici necesară, nici recomandată.
Ce pluginuri face platforma inutile?
Pluginurile de memorie cache, pluginurile separate de memorie cache pentru obiecte și pluginurile de rezervă sunt toate redundante aici, deoarece aceste sarcini sunt realizate la un nivel inferior WordPress — memorie cache la nivel de server, o memorie cache gestionată de obiecte per site și copii de rezervă ale platformei. Eliminarea lor reduce conflictele și suprafața de atac. Tot ceea ce merită păstrat sunt pluginurile de care site-ul dumneavoastră are cu adevărat nevoie pentru a funcționa, plus cele două pluginuri gratuite ale noastre pentru memorie cache și footprint, care vin preinstalate.
Memorarea în cache va afecta coșul meu WooCommerce sau paginile pentru utilizatorii conectați?
Nu. Coșul, finalizarea comenzii, contul meu și orice pagini cu nonce sau de sesiune sunt excluse din memoria cache în mod implicit, iar Edge Side Includes menține fragmentul de coș și totalurile active pe paginile care sunt altfel memorate în cache. Cumpărătorii văd întotdeauna propriul coș și o pagină de finalizare funcțională, în timp ce vitrina magazinului se încarcă în continuare din memoria cache, iar golirea automată inteligentă curăță paginile afectate atunci când se modifică un produs, un preț sau o comandă.
Cum mențineți WordPress în siguranță fără ca eu să îl administrez?
Aplicăm corecții la nivelul infrastructurii de sub WordPress, facem ca actualizările de nucleu și module să poată fi aplicate în siguranță cu medii de testare și restaurare printr-un singur clic, rulăm scanarea împotriva programelor malware și protecția DDoS activate în mod implicit, izolăm fiecare site astfel încât o compromitere să nu se poată răspândi și emitem și reînnoim automat certificatele TLS. Acest lucru elimină infrastructura ca verigă slabă; igiena de bază, cum ar fi acreditările puternice și eliminarea modulelor neutilizate, vă revine în continuare dumneavoastră.
Conexe
Încercați gratuit timp de 14 zile
Lansați primele site-uri gratuit timp de 14 zile — fără card necesar. Mutați un site sau o rețea existentă? Migrările sunt gratuite, fără nicio limită.
Începeți gratuit