De ce site-ul dvs. WordPress este atât de lent și un ghid la îndemână pentru accelerarea lucrurilor

Am vrut să încep acest post informându-vă că acesta NU este doar un alt articol generic „Cum să accelerați WordPress”.

Nu am de gând să regurgitez nimic din ce se poate găsi deja pe web. Nu am de gând să vă spun că ar trebui să instalați un plugin de cache, să activați compresia, să vă micșorați css / js etc.….

La urma urmei, ar trebui să știi cum să faci aceste lucruri deja. Și dacă nu, puteți găsi aceste informații generice pe alte sute de bloguri.

În schimb, acest articol conține tot ceea ce am personalizat / semi-personalizat pe care l-am implementat în ultima lună sau cam așa pentru a-mi accelera propriul blog WordPress și, în esență, pentru a împiedica accesul necinstit să-mi aducă serverul.

Iar motivul pentru care este „puțin cunoscut” este că tehnicile pe care urmează să le descriu vor fi foarte specifice propriului blog în funcție de tiparele de trafic pe care le vedeți.

Notă: dacă aveți un blog lent și chiar nu doriți să vă ocupați de niciunul dintre aspectele tehnice ale accelerării unui site web, atunci probabil că ar trebui să vă înscrieți pentru un serviciu precum WP Engine .

Acești tipi sunt specializați în găzduirea WordPress și se vor asigura că blogul dvs. rulează cât mai repede posibil. Dar, în mod firesc, acest lucru are un preț. Ar trebui să le verificați dacă această postare vă trece peste cap :)

Oricum, înainte de a vă putea explica cum și de ce am făcut ceea ce am făcut blogului meu, trebuie să înțelegeți câteva concepte fundamentale despre WordPress și cache pe care le voi descrie mai jos.

Câteva fapte WordPress interesante

Să presupunem că ați urmat deja toate liniile directoare despre cum să accelerați WordPress deja. Blogul tău se simte ferm. Webpagetest.org vă spune că blogul dvs. este rapid. Totul este bine, nu? Nu neapărat .

Obișnuiam să simt exact același lucru despre blogul meu. La urma urmei, urmez majoritatea protocoalelor standard de accelerare. Execut foarte puține pluginuri și blogul meu se simte destul de repede în condiții normale de utilizare din perspectiva unui cititor uman (rețelele publicitare sunt cele care încetinesc blogul meu, așa că am încărcat ultimele reclame).

Dar apoi am început să-mi analizez graficele de utilizare a procesorului și am observat deseori perioade de încărcare mare a serverului, în ciuda nivelurilor de trafic reduse până la moderate. Ocazional, serverul meu ar deveni chiar inutilizabil sau nu răspunde pentru perioade lungi de timp.

Rețineți, singurul motiv pentru care am început să acordați atenție acestor statistici a fost pentru că acum ceva timp îmi rulam magazinul online pe același server ca și blogul meu. Și periodic aș face ca clienții să se plângă că magazinul a fost extrem de lent. Când am făcut în sfârșit câteva săpături, am constatat că blogul meu WordPress optimizat, complet stocat în cache, îmi aducea serverul în genunchi!

Morala povestii? Doar pentru că un test de viteză îți spune că blogul tău este rapid nu înseamnă neapărat că totul este bine.

Iată câteva fapte amuzante despre WordPress și plugin-uri de cache, cum ar fi WP Super Cache și W3 Total Cache, de care ar trebui să fiți conștienți.

• Răspunsurile WordPress 404 sunt lente . Ori de câte ori blogul dvs. primește acces la o pagină care nu există, serverul dvs. sărac trebuie să încarce WordPress, să ruleze o grămadă de cod PHP, să facă o grămadă de interogări MySQL și apoi să scuipe pagina personalizată WordPress 404. Aceasta este o sarcină foarte intensivă, iar stocarea în cache nu vă va ajuta.
• Pluginul dvs. de cache nu funcționează foarte bine atunci când există parametri GET în adresa URL. De exemplu, obișnuiam să observ că blogul meu încetinește până la accesarea cu crawlere de fiecare dată când trimit o explozie în lista mea de e-mailuri. În teorie, cu stocarea în cache a fișierelor statice, serverul meu ar trebui să fie aproape invincibil.

  Dar, deoarece Aweber introduce parametri de urmărire în URL, niciunul dintre fișierele mele nu este super cache. Drept urmare, WordPress trebuie să genereze un fișier cache nou (chiar dacă acesta există deja), să îl zipeze și să îl trimită de fiecare dată. Cea mai rea parte este că aceste fișiere memorate în cache sunt folosite o singură dată, ceea ce îl face să risipească resursele serverului

• Accesele necinstite sunt lente. Deoarece accesele necinstite necesită ca WordPress să se încarce în mod implicit, un bot sau un crawler rău care decide să-ți spame site-ul cu cereri greșite poate să-ți dea jos blogul destul de ușor.
• Pluginul dvs. de cache poate avea o eroare sau o incompatibilitate cu modul în care v-ați configurat blogul . De exemplu, timp de 3 ani am crezut că WP Super Cache face ceea ce trebuie până când am început să mă uit la jurnalele mele și am observat o eroare în cod. Din cauza modului în care am configurat lucrurile, am avut o problemă în care WP Super Cache îmi spăla prea des memoria cache.

Punctul cheie pe care încerc să-l subliniez cu punctele glonț de mai sus este că ori de câte ori un acces non-standard are loc pe blogul dvs., acesta folosește o mulțime de resurse de server, indiferent de modul în care ați configurat blogul dvs. WordPress. Și aceste tipuri de accesuri vă vor aduce serverul în genunchi, nu traficul obișnuit.

Detectarea acceselor necinstite

Prima cheie pentru optimizarea blogului dvs. WordPress este înțelegerea tiparelor de trafic pe care blogul dvs. le primește. Sunt dispus să pariez că 99% dintre utilizatorii WordPress nu fac asta. În schimb, urmăresc și instalează orbește diverse pluginuri și presupun că totul funcționează corect. Nu te simți rău, am fost la fel.

Așadar, primul pas este să aflăm ce naiba se întâmplă. Există multe modalități de a face acest lucru, dar cea mai ușoară modalitate este de a utiliza modul de depanare oferit de pluginul WP SuperCache. Ce face acest mod? Practic, de fiecare dată când un acces este gestionat direct de WordPress (intensiv în resurse), acesta va apărea în jurnalul WP Super Cache. Iată cum activați acest mod.

Sub fila de depanare a pluginului WP Super Cache, pur și simplu faceți clic pe caseta de selectare „Depanare activată” și sunteți bine să plecați!

După activarea înregistrării, puteți face clic pe linkul „fișier jurnal” care vă va indica un fișier care detaliază traficul WordPress. Va arăta similar cu textul de mai jos.

15:03:46 /?utm_source=fwisp.com supercache dir:
15:03:46 /?utm_source=fwisp.com No wp-cache file exists. Must generate a new one.
15:03:46 /?utm_source=fwisp.com In WP Cache Phase 2
15:03:46 /?utm_source=fwisp.com Setting up WordPress actions
15:03:46 /?utm_source=fwisp.com Supercache caching disabled. Only using wp-cache. Non empty GET request.
15:03:46 /?utm_source=fwisp.com USER AGENT (Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)) rejected. Not Caching

Important de reținut este că, de fiecare dată când vedeți ceva în acest jurnal, este un lucru rău, deoarece înseamnă că WordPress trebuie să funcționeze. Și pentru că WordPress este un porc de resurse, doriți ca acesta să facă cât mai puțin lucru posibil.

Ce să căutați în jurnale

Jurnalele WP Super Cache sunt grozave deoarece vă spun tot ce se întâmplă. Dar cantitatea mare de informații poate fi copleșitoare, dacă nu știi ce să cauți. Iată la ce ar trebui să fiți atenți în aceste jurnale.

• 404 Erori - Practic, acestea sunt accesări la pagini care nu există pe blogul dvs. Fiecare acces 404 gestionat de WordPress ocupă o mulțime de resurse de server, așa că doriți să le blocați, dacă este posibil
• Accesuri o singură dată - Acestea sunt solicitări care determină serverul să memoreze în cache și să comprime pagini care vor fi utilizate doar o dată (mai multe despre aceasta mai târziu)
• Ciudate explozii de trafic - Acestea sunt, de obicei, roboți care vă lovesc blogul simultan
• Comportament ciudat în cache - cache-urile dvs. se înroșesc când ar trebui? În orice circumstanțe, totul este stocat în mod corespunzător?

După ce am păstrat un jurnal al traficului blogului meu pentru o perioadă de 2 săptămâni, am descoperit o mulțime de ineficiențe pe care le voi descrie mai jos.

Roboții mi-au lovit arhivele

Primul lucru pe care l-am făcut a fost să mă uit la jurnalele serverului meu pentru perioade de încărcare mare a procesorului. Apoi, am analizat jurnalele mele de super cache în aceste perioade exacte pentru a vedea dacă se întâmplă vreo afacere amuzantă. Se pare că, o dată la două zile, cam așa, un grup de roboți ar veni și arunca toate paginile de arhivă ale blogului meu în același timp!

Deoarece aceste pagini de arhivă nu sunt memorate în cache în mod implicit, o grămadă de accesuri simultane au fost suficiente pentru a crește încărcarea serverului meu și a face lucrurile extrem de lente. Și, ocazional, a provocat chiar blocarea serverului meu.

Așa că am aruncat o privire mai atentă asupra rezultatului HTML și am observat că aveam o grămadă de linkuri de arhivă ca parte a antetului meu WordPress. Prin urmare, roboții și alte crawler-uri web ar veni și ar încerca să răsfoiască arhivele.

După o mare căutare de Google, am constatat că alți câțiva webmasteri au probleme similare.

Când vedem probleme de încărcare cu site-ul dvs. de mai multe ori, există un număr mare de accesări pentru adresele IP ale serverului proxy și teoria este că aceste proxy vă cache site-ul și accesează toate acele linkuri de arhivă. Multe dintre adresele IP pe care le vedem atunci când site-ul dvs. cauzează probleme de încărcare sunt IP-urile corporative, educaționale și proxy guvernamentale / militare care par să preia conținut atunci când cineva accesează un site.

Soluție: verificați dacă aveți declarația php „wp_get_archives” în codul de antet pentru blogul dvs. și eliminați-o. După ștergerea acestui mic fragment, toate accesările mele la arhivă au dispărut.

Roboții accesau fișiere inexistente

Al doilea lucru major pe care l-am observat a fost că există o grămadă de roboți care accesează fișiere de pe serverul meu care nu existau. Problema este că de fiecare dată când are loc un acces la fișier, serverul dvs. trebuie să încarce WordPress, să execute o grămadă de cod PHP și apoi să emită o pagină de 404.

Soluția la această problemă este să editați fișierul .htaccess (Google, dacă nu știți ce este) și să adăugați următoarele rânduri.

RewriteCond% {REQUEST_FILENAME}! -F
RewriteCond% {REQUEST_FILENAME}! -D
RewriteCond% {REQUEST_URI}! (Robots \ .txt | sitemap \ .xml (\. Gz)?)
RewriteCond% {REQUEST_FILENAME} \. (Css | js | html | htm | rtf | rtx | svg
| svgz | txt | xsd | xsl | xml | asf | asx | wax | wmv | wmx | avi | bmp | class | divx | doc
| docx | exe | gif | gz | gzip | ico | jpg | jpeg | jpe | mdb | mid | midi | mov | qt | mp3 |
m4a | mp4 | m4v | mpeg | mpg | mpe | mpp | odb | odc | odf | odg | odp | ods | odt | ogg | pdf
| png | pot | pps | ppt | pptx | ra | ram | rar | swf | tar | tif | tiff | wav | wma | wri |
xla | xls | xlsx | xlt | xlw | zip) $ [NC]
RewriteRule. * - [L]

Odată ce aceste linii sunt inserate în fișierul dvs. .htaccess, serverul dvs. web va verifica mai întâi dacă există un fișier. Dacă nu, va emite un răspuns 404 FĂRĂ încărcarea WordPress.

Roboții accesau adrese URL care nu existau

Ceea ce este regretabil în legătură cu modul în care este scris WordPress este că, dacă există un acces la un articol care nu există în baza de date, serverul dvs. va trebui să încarce WordPress, să execute o grămadă de cod PHP și să facă o grămadă de căutări MySQL înainte de a emite un 404 răspuns.

Dacă vă uitați atent la jurnalele dvs., veți observa probabil anumite modele de acces pe care le puteți exclude înainte de a ajunge vreodată la WordPress.

De exemplu, am observat că o grămadă de roboți accesează site-ul meu cu adresa URL www.mywifequitherjob.com/some-article/www.facebook.com/like.php/… . Și de fiecare dată, serverul meu ar încărca WordPress și va emite un răspuns 404.

Deci, în loc să am WordPress să gestioneze aceste solicitări, am adăugat următoarele linii în fișierul .htaccess

RewriteCond% {REQUEST_FILENAME}! -F
RewriteCond% {REQUEST_FILENAME}! -D
RewriteCond% {REQUEST_URI} www \ .facebook \ .com / plugins [NC]
RewriteRule. * 404.html [L, R = 404]

În rândurile de mai sus, serverul meu web caută „www.facebook.com/plugins” în URL și emit imediat un răspuns 404 fără a încărca WordPress. Pe măsură ce parcurgeți jurnalele, veți găsi multe accesări necinstite, precum cel pe care l-am descris mai sus. Scrieți o regulă .htaccess pentru fiecare și aceste accesări nu vă vor mai încărca serverul.

Roboții au lovit comentariile mele Link-uri

Vă amintiți când v-am spus că adresele URL cu parametrii GET sunt gestionate diferit de pluginul dvs. de cache? Am descoperit că au existat o grămadă de roboți care au lovit articolele mele cu setul de parametri „Răspuns la comentariu”.

Când se întâmplă acest lucru (în funcție de setările de cache), wordpress se încarcă și un fișier cache / zip este difuzat, chiar dacă probabil nu va mai fi accesat niciodată. Aceasta este o risipă de resurse.

Exemplu preluat din jurnalul meu
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 No wp-cache file exists. Must generate a new one.
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 Gzipping buffer.

Soluția este de a redirecționa toți roboții și crawlerele cu acești parametri GET către pagina principală a articolului. Iată codul pe care l-am adăugat în fișierul .htaccess.

RewriteCond% {QUERY_STRING} replytocom
RewriteCond% {HTTP_USER_AGENT} ^ (. *) (Bot | crawl | spider | slurp) [NC]
RewriteRule. * Https: //mywifequitherjob.com% {REQUEST_URI}? [L]

Acest cod caută parametrul GET „replytocom” și apoi elimină acest parametru de la adresa URL finală înainte de a prezenta accesul la WordPress.

Crawlerele accesau postări fără o bară finală

Nu sunt sigur de ce este cazul, dar am observat o grămadă de webcrawler-uri care păreau că încearcă în mod legitim să acceseze articolele de pe blogul meu fără o bară finală în adresa URL.

După cum știți sau nu, o adresă URL care este scrisă ca http://yourblog.com/article/ este diferită de o adresă URL scrisă ca http://yourblog.com/article .

Ca rezultat, atunci când se întâlnește o adresă URL fără o bară finală, WordPress trebuie să intervină, să ruleze o grămadă de cod PHP și apoi să emită o redirecționare 301 către articol cu ​​bară finală. Pentru a scoate WordPress din imagine, puteți introduce pur și simplu următoarea regulă în fișierul dvs. .htaccess.

# Adăugați o bară finală
RewriteCond% {REQUEST_FILENAME}! -F
RewriteCond% {REQUEST_URI}! (. *) / $
RewriteCond% {QUERY_STRING}!. * =. *
RewriteRule ^ (. *) $ 1 $ / [L, R = 301]

Prin adăugarea unei bare oblice, trimiteți redirecționarea 301 la adresa URL corectă înainte ca aceasta să ajungă la WordPress, care va economisi resursele procesorului.

Am găsit o eroare în WP Super Cache

Spre deosebire de majoritatea oamenilor, nu am blogul meu WordPress instalat în rădăcina directorului meu public_html. În plus, prima pagină a blogului meu nu este nici pagina mea de „postări”. Când aveți blogul configurat la fel ca mine, există o eroare în WP Super Cache în care toate fișierele cache ar putea fi șterse prematur, chiar dacă preîncărcați memoria cache.

Nu sunt sigur dacă autorul pluginului este conștient de această problemă, dar practic am constatat că de fiecare dată când un comentariu spam a fost trimis pe blogul meu, întregul meu cache ar fi spălat în mod eronat. Deoarece primesc tot timpul spam pentru comentarii și trackback, cache-ul meu a fost golit constant, ceea ce a făcut ca cache-ul să fie mult mai puțin eficient.

Așa că am petrecut un weekend depanând această problemă și am dezvoltat în cele din urmă o soluție. Dacă vreunul dintre voi are aceleași probleme, anunțați-mă și vă voi arăta soluția mea. Morala poveștii de aici este să nu presupui niciodată că plugin-ul tău de cache funcționează doar. Trebuie să te uiți la jurnale!

Dezactivați pluginurile intensive pentru CPU

Chiar dacă ați urmat toți pașii mei de mai sus, este imposibil să filtrați toate accesările necinstite înainte ca acestea să ajungă pe blogul dvs. WordPress.

Prin urmare, veți primi întotdeauna accesări pe site-ul dvs. care nu vor fi gestionate eficient. Nu există nici o cale de a o înconjura.

Dar cel mai important lucru de realizat este că cel mai probabil nu veți avea o problemă cu lățimea de bandă, veți avea o problemă cu CPU.

Ca urmare (și acest lucru poate fi contraintuitiv), de fapt nu doriți să faceți ceva intensiv în procesor, cum ar fi „reducerea” sau „comprimarea” paginilor dvs. din mers. Minimizarea și compresia ajută la lățimea de bandă în detrimentul utilizării procesorului.

Ultimul lucru pe care doriți să îl faceți este reducerea și memorarea în cache a acceselor necinstite. De fapt, ar trebui să luați în considerare probabil să nu micșorați sau să comprimați adresele URL cu parametrii GET.

Cel mai important, nu ar trebui să rulați niciun plugin cu procesor intensiv pe site-ul dvs. WP-Engine are o listă excelentă de plugin-uri cu procesor intensiv pe care probabil ar trebui să le încercați să le evitați.

Pe măsură ce parcurgeam lista de pluginuri, am observat că foloseam un plugin de „postări similare”. Și când am aruncat o privire asupra codului sursă, am fost consternat să descopăr că plugin-ul făcea text complet comparativ pentru a găsi articole similare, care este un procesor major de procesare și nu scalabil.

De îndată ce găsesc un înlocuitor adecvat, acest plugin merge cu siguranță la coșul de gunoi.

Morala povestii

Doar pentru că un test de viteză online îți spune că blogul tău este rapid nu înseamnă prea mult în marea schemă a lucrurilor.

Nu mă înțelege greșit. Viteza de încărcare a paginii este importantă pentru motoarele de căutare și pentru clienții obișnuiți, dar trebuie să țineți cont și de accesele necinstite care vă pot ocoli memoria cache și vă pot aduce serverul în genunchi.

Deci, nu instalați doar cache-ul și alte pluginuri de accelerare orbește. Alocați-vă ceva timp pentru a vă analiza traficul și a scrie cât mai multe reguli .htaccess posibil pentru a reduce la minimum munca pe care WordPress trebuie să o îndeplinească. Mult noroc!