Sunteți, desigur, conștienți de faptul că acest blog este alimentat de WordPress. Cu ceva timp în urmă am început să mă îngrijorez serios de viteza acestui motor. În primul rând, am fost îngrijorat de cantitatea de memorie folosită de el. De exemplu, când boturile de căutare încep să meargă pe blog. WordPress poate manca cu ușurință 1 GB de memorie RAM. În al doilea rând, am fost îngrijorat de timpul pentru care utilizatorul se încarcă paginile. În cazul în care intrați în cache, nu există probleme, dar în caz contrar pagina poate fi generată cu ușurință 1-2 secunde.
Pentru a optimiza blogul, am luat următorii pași.
Mai întâi, dezactivați toate pluginurile suplimentare. Dacă pluginul poate fi înlocuit cu o bucată de cod într-un șablon sau într-un șir din fișierul .htaccess, înlocuiți-l. În cazul meu, au fost doar următoarele nouă plug-in-uri - l AddQuicktag, CodeColorer, Disqus, Google Sitemaps XML, Limit Conectare Incercarile, RusToLat, WP-Optimize, WP-PageNavi, WP Super Cache. În mod strict vorbind, este posibil, de asemenea, să scăpăm de cele mai multe dintre ele, dar așa cum vom vedea în curând, acest lucru nu este necesar.
Mai departe. Verificăm dacă sunt utilizate în șablon o duzină de fișiere CSS sau JS. imagini grele și așa mai departe. Fișierele CSS sunt combinate și ambalate cât mai mult posibil, JS este rulat prin Google Closure Compiler (există o aplicație și o versiune online). Uităm, dacă este posibil să reducem dimensiunea codului HTML. De exemplu, am observat că în titlurile posturilor folosesc următorul cod:
Am înlocuit-o cu:
... salvând astfel vizitatorii câteva duzini de trafic. De asemenea, dimensiunea paginii a fost ușor redusă prin utilizarea următorului cod în funcțiile.php:
În plus, acest cod reduce numărul de linkuri pe care boturile de căutare încearcă să le parcurgă. Apoi am început anteturile HTTP. Din resturile pure (care este vizibil atunci când treci cache-ul) au găsit:
X-Pingback poate fi tăiat astfel:
funcția remove_pingback_header # 40; $ anteturi # 41; # 123;
unset # 40; $ anteturi # 91; 'X-Pingback' # 93; # 41; ;
returnați $ anteturi;
# 125;
add_filter # 40; 'Wp_headers'. 'Remove_pingback_header' # 41; ;
Dar codul pentru tăiere Link:
funcția empty_shortlink # 40; $ shortlink. id id. $ context. $ allow_slugs # 41; # 123;
retur NULL;
# 125;
add_filter # 40; 'Get_shortlink'. 'Empty_shortlink'. 10. 4 # 41; ;
De asemenea, pentru a nu scorma versiunea PHP (antetul X-Powered-By), îl scriem în fișierul php.ini:
Se pare că după această modificare trebuie să reporniți Apache. În același timp, am verificat lista extensiilor PHP și modulele Apache. Ca rezultat, am dezactivat 5 module de module / extensii de care nu am nevoie.
S-ar părea că acum le oferim utilizatorilor doar static bypassing PHP, dar cantitatea de memorie folosită nu se grăbește să scadă. Aparent, PHP face ceva. Apoi am decis să adaug următorul cod la index.php:
$ fid = fopen # 40; "/path/to/index-php.txt". "A" # 41; ;
fwrite # 40; $ fid.
data # 40; "Y-m-dH: i: s" # 41;. "\ t".
$ _SERVER # 91; 'REQUEST_URI' # 93;. "\ t".
$ _SERVER # 91; 'REMOTE_ADDR' # 93;. "\ t".
$ _SERVER # 91; 'HTTP_USER_AGENT' # 93;. "\ n" # 41; ;
fclose # 40; $ fid # 41; ;
Sa dovedit faptul că blog-ul merge o mulțime de bărci, care sunt în căutarea forumuri uzate, solicita pagina / articol-nume în locul / articol-nume /, precum și fișiere non-existente cu nume precum Apple-touch-icon.png și așa mai departe. Toate aceste solicitări au trecut de cache direct în WordPress. Pentru a combate această problemă, am adăugat următoarele în .htaccess:
Deoarece unii vizitatori vin la un blog cu tot felul de gunoi într-un șir de interogări, cum ar fi utm_source =. De asemenea, am configurat redirecționări cu URL-uri care conțin câteva argumente în interogare, pe aceeași adresă URL, dar fără argumente:
RewriteCond%! = ""
Codecolorer RewriteCond!
RewriteCond%! ^ (P | pagina_id | previzualizare) =
RewriteCond%! ^ / Wp- (admin | login | cron | include)
RewriteRule ^ (. *) $ / $ 1? [R = 301, L]
Mai exact, pentru roboții de căutare Google din robots.txt, am adăugat:
Dezactivați: * / feed
Nu permiteți: * / trackback
Neagă: * / comentariu
În cele din urmă, pentru vizitatorii care au solicitat o pagină inexistentă, a văzut normală locul mesajul de eroare „404 Not Found», am început o pagină specială și prescrisă în .htaccess:
În acest stadiu, a fost destul de evident că WordPress nu primește cereri inutile, în majoritatea cazurilor paginile sunt luate, în general, din cache-ul ocolind PHP. Cu excepția posibilelor excepții ale feedurilor RSS, deoarece WP Super Cache nu știe cum să le cacheze din anumite motive. Trebuie remarcat faptul că volumul de memorie folosit pe server a scăzut deja în mod semnificativ (a fluctuat în jur de 100-200 MB, cu vârfuri rare până la 300-400 MB), dar nu am fost mulțumit de rezultatul devreme.
A trebuit să aștept un timp, dar rezultatul merita:
Reducerea cantității de utilizare a memoriei se produce deoarece „grele» Apache nu se ocupă cu transferul de date către client, în schimb face „ușor» Nginx, a ridicat la nivel local. Apache îndeplinește rapid, oferă date către Nginx și ieșiri. Astfel, în același timp, există mai puține procese Apache care rulează și există mai multă memorie liberă.
Dar cu ce viteză este încărcarea paginilor:
Să spunem, nu este mai lent decât încărcarea principală a paginii Yandex. Și toate acestea sunt cele mai obișnuite găzduire de la RU-CENTER. Bănuiesc că nu voi putea să mă mut pe un server dedicat foarte curând.
Pe lângă optimizările descrise mai sus, am experimentat și următoarele.
Am încercat să transfere imagini și fișiere toate acolo pentru a Dropbox, dar o specială a salva de memorie sau de alt câștig de la ea și nu a văzut din spate așa cum a fost. Am încercat să păstreze în pagina gzip'ovannye memoria cache și să le dea o formă pentru vizitatori (de altfel, funcționează chiar și fără mod_gzip). De asemenea, nu am văzut niciun profit, în plus, paginile necomprimate trebuie încă să fie stocate în cache, în cazul în care clientul nu are suport gzip. Am decis să nu înșel și să deconectez acest caz. Am încercat să dezactivez wp-cron în WordPress și să îl înregistrez în crontab. Am rupt totul și nu am profitat, am întors totul înapoi. De asemenea, am încercat plug-in-ul WP-Minify, care optimizează codul HTML al paginilor. Un lucru minunat, dar la momentul încărcării pagina are un efect redus, dar viteza de generare crește cu aproximativ 100 ms. Oprit și eliminat.
Am găsit, de asemenea, un plugin cool Really Static, care permite generarea de site-uri statice pe WordPress. Și apoi cel puțin pe narod.ru, cel puțin pe GitHub se umple. Sau, pentru a fi mai convenabil, puteți să ridicați WordPress pe un subdomeniu cu acces limitat prin parolă, iar pe domeniul principal al domeniului numai static. Voi deveni o zece mii, trebuie să mă mai uit la ea, dar pentru moment va fi mai incomod decât bine.
Deci, încă mai credeți că WordPress este un motor de frână? Sau încă nu știți cum să-l utilizați?
Îți place postul? Trimiteți-le altora:
Articole similare
Trimiteți-le prietenilor: