Perché il tuo sito WordPress è così lento e una pratica guida per accelerare le cose

Volevo iniziare questo post facendoti sapere che questo NON è solo un altro articolo generico "Come velocizzare WordPress".

Non ho intenzione di rigurgitare qualcosa che si può già trovare sul web. Non ti dirò che dovresti installare un plug-in di memorizzazione nella cache, abilitare la compressione, minimizzare il tuo css/js ecc….

Dopotutto, dovresti già sapere come fare queste cose. E se non lo fai, puoi trovare queste informazioni generiche su centinaia di altri blog.

Invece, questo articolo contiene tutto ciò che è personalizzato/semi-personalizzato che ho implementato nell'ultimo mese o giù di lì per velocizzare il mio blog WordPress e sostanzialmente impedire che accessi non autorizzati facciano crollare il mio server.

E il motivo per cui è "poco conosciuto" è perché le tecniche che sto per descrivere saranno molto specifiche per il tuo blog a seconda dei modelli di traffico che stai vedendo.

Nota: se hai un blog lento e non vuoi davvero occuparti di nessuno degli aspetti tecnici dell'accelerazione di un sito web, allora dovresti probabilmente iscriverti a un servizio come WP Engine .

Questi ragazzi sono specializzati nell'hosting di WordPress e si assicureranno che il tuo blog funzioni il più velocemente possibile. Ma naturalmente, questo ha un prezzo. Dovresti controllarli se questo post ti passa per la testa :)

Ad ogni modo, prima di poterti spiegare come e perché ho fatto ciò che ho fatto al mio blog, devi comprendere alcuni concetti fondamentali su WordPress e sul caching che descriverò di seguito.

Alcuni fatti interessanti su WordPress

Supponiamo che tu abbia già seguito tutte le linee guida su come velocizzare WordPress. Il tuo blog sembra scattante. Webpagetest.org ti dice che il tuo blog è veloce come l'inferno. Va tutto bene vero? Non necessariamente .

Mi sentivo esattamente allo stesso modo riguardo al mio blog. Dopotutto, seguo la maggior parte dei protocolli standard di accelerazione. Eseguo pochissimi plugin e il mio blog si sente abbastanza veloce in condizioni di utilizzo normale dal punto di vista di un lettore umano (Le reti pubblicitarie sono ciò che rallenta il mio blog, quindi carico gli annunci per ultimo).

Ma poi ho iniziato ad analizzare i miei grafici di utilizzo della CPU e spesso ho notato periodi di carico elevato del server nonostante i livelli di traffico da bassi a moderati. Occasionalmente, il mio server diventava persino inutilizzabile o non rispondeva per lunghi periodi.

Nota, l'unico motivo per cui ho iniziato a prestare attenzione a queste statistiche è stato perché qualche tempo fa gestivo il mio negozio online sullo stesso server del mio blog. E periodicamente i clienti si lamentavano che il negozio era estremamente lento. Quando finalmente ho fatto qualche ricerca, ho scoperto che il mio blog WordPress ottimizzato e completamente memorizzato nella cache stava mettendo in ginocchio il mio server!

Morale della storia? Solo perché un test di velocità ti dice che il tuo blog è veloce non significa necessariamente che tutto vada bene.

Ecco alcuni fatti divertenti su WordPress e sui plug-in di memorizzazione nella cache come WP Super Cache e W3 Total Cache di cui dovresti essere a conoscenza.

• Le risposte 404 di WordPress sono lente . Ogni volta che il tuo blog riceve un accesso a una pagina che non esiste, il tuo povero server deve caricare WordPress, eseguire un mucchio di codice php, fare un sacco di query MySQL e poi sputare la tua pagina WordPress 404 personalizzata. Questa è un'attività che richiede molte risorse e la memorizzazione nella cache non sarà di aiuto.
• Il tuo plug-in di memorizzazione nella cache non funziona molto bene quando ci sono parametri GET nell'URL. Ad esempio, ho notato che il mio blog rallentava a passo d'uomo ogni volta che inviavo un'esplosione alla mia lista di e-mail. In teoria con la memorizzazione nella cache dei file statici, il mio server dovrebbe essere quasi invincibile.

  Ma poiché Aweber inserisce i parametri di tracciamento nell'URL, nessuno dei miei file viene memorizzato nella cache. Di conseguenza, WordPress deve generare un nuovo file di cache (anche se esiste già), comprimerlo e inviarlo ogni volta. La parte peggiore è che questi file memorizzati nella cache vengono utilizzati solo una volta, il che lo rende uno spreco di risorse del server

• Gli accessi non autorizzati sono lenti. Poiché gli accessi non autorizzati richiedono il caricamento di WordPress per impostazione predefinita, un bot o un crawler dannoso che decide di inviare spam al tuo sito con richieste errate può eliminare il tuo blog abbastanza facilmente.
• Il tuo plug-in di memorizzazione nella cache potrebbe avere un bug o un'incompatibilità con il modo in cui hai impostato il tuo blog . Ad esempio, per 3 anni ho pensato che WP Super Cache stesse facendo la cosa giusta finché non ho iniziato a guardare i miei registri e ho notato un bug nel codice. A causa del modo in cui ho impostato le cose, ho avuto un problema in cui WP Super Cache scaricava la mia cache troppo spesso.

Il punto chiave che sto cercando di fare con i punti elenco sopra è che ogni volta che si verifica un accesso non standard sul tuo blog, utilizza molte risorse del server, indipendentemente da come hai impostato il tuo blog WordPress. E sono questi tipi di accesso che metteranno in ginocchio il tuo server, non il traffico normale.

Rilevamento di accessi non autorizzati

La prima chiave per ottimizzare il tuo blog WordPress è comprendere i modelli di traffico che il tuo blog riceve. Sono disposto a scommettere che il 99% degli utenti di WordPress non lo fa. Invece, seguono ciecamente e installano vari plugin e presumono che tutto funzioni correttamente. Non sentirti male, ero allo stesso modo.

Quindi il primo passo è scoprire cosa diavolo sta succedendo. Ci sono molti modi per farlo, ma il modo più semplice è usare la modalità di debug fornita dal plugin WP SuperCache. Cosa fa questa modalità? Fondamentalmente, ogni volta che un accesso viene gestito direttamente da WordPress (ad uso intensivo di risorse), verrà visualizzato nel registro WP Super Cache. Ecco come abilitare questa modalità.

Nella scheda di debug del tuo plug-in WP Super Cache, fai semplicemente clic sulla casella di controllo "Debug abilitato" e sei a posto!

Una volta abilitata la registrazione, puoi fare clic sul collegamento "file di registro" che ti indirizzerà a un file con i dettagli del tuo traffico WordPress. Sarà simile al testo qui sotto.

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

La cosa importante da notare è che ogni volta che vedi qualcosa in questo registro, è una cosa negativa perché significa che WordPress deve funzionare. E poiché WordPress è un divoratore di risorse, vuoi che svolga il minor lavoro possibile.

Cosa cercare nei registri

I log di WP Super Cache sono fantastici perché ti dicono tutto quello che sta succedendo. Ma l'enorme quantità di informazioni può essere schiacciante a meno che tu non sappia cosa cercare. Ecco a cosa dovresti prestare attenzione in questi log.

• Errori 404 – Fondamentalmente questi sono accessi a pagine che non esistono sul tuo blog. Ogni accesso 404 gestito da WordPress occupa molte risorse del server, quindi se possibile vorrai eliminarle sul nascere
• One Time Accesses - Queste sono richieste che fanno sì che il tuo server memorizzi nella cache e comprima le pagine che verranno utilizzate solo una volta (ne parleremo più avanti)
• Strani raffiche di traffico : di solito si tratta di bot che martellano il tuo blog tutto in una volta
• Strano comportamento di memorizzazione nella cache: le tue cache vengono svuotate quando dovrebbero? Tutto viene memorizzato correttamente nella cache in tutte le circostanze?

Dopo aver tenuto un registro del traffico del mio blog per un periodo di 2 settimane, ho scoperto molte inefficienze che descriverò di seguito.

I bot stavano martellando i miei archivi

La prima cosa che ho fatto è stata guardare i log del mio server per i periodi di carico elevato della CPU. Quindi, ho analizzato i miei registri della super cache durante questi stessi identici periodi per vedere se c'era qualche attività divertente in corso. Si scopre che una volta ogni due giorni circa, un gruppo di bot veniva a martellare tutte le pagine dell'archivio del mio blog allo stesso tempo!

Poiché queste pagine di archivio non sono memorizzate nella cache per impostazione predefinita, un mucchio di accessi simultanei è stato sufficiente per aumentare il carico del mio server e rendere le cose estremamente lente. E occasionalmente, ha persino causato l'arresto anomalo del mio server.

Quindi ho dato un'occhiata più da vicino al mio output HTML e ho notato che avevo un sacco di collegamenti all'archivio come parte dell'intestazione di WordPress. Pertanto, bot e altri web crawler sarebbero arrivati ​​e avrebbero cercato di sfogliare gli archivi.

Dopo una lunga ricerca su Google, ho scoperto che alcuni altri webmaster avevano problemi simili.

Quando vediamo problemi di caricamento con il tuo sito molte volte, c'è un gran numero di hit per gli IP del server proxy e la teoria è che questi proxy mettono in cache il tuo sito e colpiscono tutti quei link di archivio. Molti degli IP che vediamo quando il tuo sito sta causando problemi di caricamento sono IP proxy aziendali, educativi e governativi/militari che sembrano recuperare i contenuti quando qualcuno accede a un sito.

Soluzione: controlla se hai l'istruzione php "wp_get_archives" nel codice dell'intestazione per il tuo blog e rimuovila. Dopo aver eliminato questo piccolo frammento, tutti i miei accessi all'archivio sono scomparsi.

I bot accedevano a file inesistenti

La seconda cosa importante che ho notato è che c'erano un sacco di bot che accedevano a file sul mio server che non esistevano. Il problema è che ogni volta che si verifica un accesso a un file, il tuo server deve caricare WordPress, eseguire una serie di codice PHP e quindi pubblicare una pagina 404.

La soluzione a questo problema è modificare il file .htaccess (Google questo se non sai cos'è) e aggiungere le seguenti righe.

RiscriviCond %{REQUEST_FILENAME} !-f
RiscriviCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !(robots\.txt|sitemap\.xml(\.gz)?)
RiscriviCond %{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]

Una volta che queste righe sono state inserite nel tuo file .htaccess, il tuo server web verificherà prima se un file esiste. In caso contrario, emetterà una risposta 404 SENZA caricare WordPress.

I bot accedevano a URL che non esistevano

La cosa sfortunata del modo in cui è scritto WordPress è che se c'è un accesso a un articolo che non esiste nel tuo database, il tuo server dovrà caricare WordPress, eseguire un mucchio di codice PHP e fare un sacco di ricerche MySQL prima di emettere un 404 risposta.

Se osservi attentamente i tuoi log, probabilmente noterai alcuni modelli di accessi che puoi escludere prima che raggiungano WordPress.

Ad esempio, ho notato che un gruppo di bot stava accedendo al mio sito con l'URL www.mywifequitherjob.com/some-article/www.facebook.com/like.php/… . E ogni volta, il mio server caricava WordPress ed emetteva una risposta 404.

Quindi, invece di lasciare che WordPress gestisca queste richieste, ho aggiunto le seguenti righe al mio file .htaccess

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

Nelle righe sopra, il mio server web cerca "www.facebook.com/plugins" nell'URL e invia immediatamente una risposta 404 senza caricare WordPress. Mentre esamini i tuoi log, troverai molti accessi non autorizzati come quello che ho descritto sopra. Scrivi una regola .htaccess per ciascuno e questi accessi non caricheranno più il tuo server.

I bot stavano martellando i miei link ai commenti

Ricordi quando ti ho detto che gli URL con parametri GET sono gestiti in modo diverso dal tuo plug-in di memorizzazione nella cache? Ho scoperto che c'erano un sacco di bot che martellavano i miei articoli con il set di parametri "rispondi al commento".

Quando ciò accade (a seconda delle impostazioni di memorizzazione nella cache), wordpress viene caricato e viene servito un file memorizzato nella cache/zip anche se probabilmente non sarà più possibile accedervi. Questo è uno spreco di risorse.

Esempio tratto dal mio registro
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.

La soluzione è reindirizzare tutti i bot e i crawler con questi parametri GET alla pagina principale dell'articolo. Ecco il codice che ho aggiunto al mio file .htaccess.

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

Questo codice cerca il parametro GET "replytocom" e quindi rimuove questo parametro dall'URL finale prima di presentare l'accesso a WordPress.

I crawler accedevano ai post senza una barra finale

Non sono sicuro del motivo per cui questo è il caso, ma ho notato un gruppo di webcrawler che sembravano tentare legittimamente di accedere agli articoli sul mio blog senza una barra finale nell'URL.

Come forse saprai o meno, un URL scritto come http://yourblog.com/article/ è diverso da un URL scritto come http://yourblog.com/article .

Di conseguenza, quando viene rilevato un URL senza barra finale, WordPress deve intervenire, eseguire un gruppo di codice PHP e quindi emettere un reindirizzamento 301 all'articolo con la barra finale. Per eliminare WordPress dall'immagine, puoi semplicemente inserire la seguente regola nel tuo file .htaccess.

# Aggiungi barra finale
RiscriviCond %{REQUEST_FILENAME} !-f
RiscriviCond %{REQUEST_URI} !(.*)/$
RiscriviCond %{QUERY_STRING} !.*=.*
Riscrivi regola ^(.*)$ $1/ [L,R=301]

Aggiungendo una barra finale, stai emettendo il reindirizzamento 301 all'URL corretto prima che raggiunga WordPress, il che farà risparmiare risorse della CPU.

Ho trovato un bug in WP Super Cache

A differenza della maggior parte delle persone, non ho il mio blog WordPress installato nella radice della mia directory public_html. Inoltre, la prima pagina del mio blog non è nemmeno la mia pagina di "post". Quando hai configurato il tuo blog nello stesso modo in cui lo faccio io, c'è un bug in WP Super Cache in cui tutti i tuoi file di cache potrebbero essere eliminati prematuramente anche se precarichi la cache.

Non sono sicuro che l'autore del plug-in sia a conoscenza di questo problema, ma in pratica ho scoperto che ogni volta che veniva pubblicato un commento spam sul mio blog, l'intera cache veniva svuotata erroneamente. Dal momento che ricevo continuamente commenti e trackback spam, la mia cache veniva costantemente svuotata, il che rendeva la memorizzazione nella cache molto meno efficiente.

Quindi ho trascorso un fine settimana a eseguire il debug di questo problema e alla fine ho sviluppato una soluzione alternativa. Se qualcuno di voi ha gli stessi problemi, me lo faccia sapere e vi mostrerò la mia soluzione. La morale della storia qui è di non dare mai per scontato che il tuo plug-in di memorizzazione nella cache funzioni. Devi guardare i log!

Disattiva i plug-in ad alta intensità di CPU

Anche se hai seguito tutti i passaggi precedenti, è impossibile filtrare tutti gli accessi non autorizzati prima che raggiungano il tuo blog WordPress.

Pertanto, riceverai sempre visite al tuo sito che non verranno gestite in modo efficiente. Non c'è modo di aggirarlo.

Ma la cosa importante da capire è che molto probabilmente non avrai un problema di larghezza di banda, avrai un problema di CPU.

Di conseguenza (e questo potrebbe essere controintuitivo), in realtà non vuoi fare nulla di intensivo per la CPU come "minimizzare" o "comprimere" le tue pagine al volo. La riduzione e la compressione aiutano con la larghezza di banda a scapito dell'utilizzo della CPU.

L'ultima cosa che vuoi fare è minimizzare e memorizzare nella cache gli accessi non autorizzati. In effetti, dovresti probabilmente considerare di non minimizzare o comprimere gli URL con i parametri GET.

Ancora più importante, non dovresti eseguire alcun plug-in ad alta intensità di CPU sul tuo sito. WP-Engine ha un ottimo elenco di plug-in ad alta intensità di CPU che dovresti probabilmente cercare di evitare.

Mentre stavo esaminando il mio elenco di plug-in, ho notato che stavo usando un plug-in di "post simili". E quando ho dato un'occhiata al codice sorgente, sono rimasto sbalordito nello scoprire che il plug-in stava facendo confronti completi per trovare articoli simili, il che è un grande consumo di CPU e non è scalabile.

Non appena trovo un sostituto adatto, questo plugin andrà sicuramente nella spazzatura.

Morale della storia

Solo perché un test di velocità online ti dice che il tuo blog è veloce non significa molto nel grande schema delle cose.

Non fraintendermi. La velocità di caricamento della pagina è importante per i motori di ricerca e per i tuoi clienti abituali, ma devi anche tenere conto degli accessi non autorizzati che potrebbero aggirare la tua cache e mettere in ginocchio il tuo server.

Quindi non installate alla cieca la vostra cache e altri plug-in di accelerazione. Prenditi del tempo per analizzare il tuo traffico e scrivere quante più regole .htaccess possibili per ridurre al minimo il lavoro che WordPress deve eseguire. Buona fortuna!