WordPress lento: da 10 a 3 secondi senza cambiare hosting

Un cliente mi scrive che il sito è lento.

Non “lentino”. Lento che apri una pagina, conti fino a dieci, e a volte non è ancora finita.

È un sito di corsi online con dentro anche un negozio. Roba pesante: area riservata, lezioni, carrello, e una discreta collezione di plugin che negli anni si è accumulata.

La prima idea, quella che viene a tutti, era una sola: cambiamo server. Ne prendiamo uno più grosso, magari cambiamo proprio hosting, e amen.

Sarebbe stato l’intervento più costoso e più inutile che potessi proporre. Ora ti spiego perché, perché è una scena che vedo ripetersi in continuazione.

Il sintomo che ti frega

La prima cosa che guardo non è il sito. È il carico del server.

Ed era basso. RAM che avanzava, disco che avanzava, CPU tranquilla come una domenica mattina.

Qui scatta la cosa controintuitiva, quella che quasi nessuno ti dice. Se il server è tranquillo ma le pagine sono lente, il problema non è la potenza. Il server non è intasato. Sta facendo troppo lavoro per ogni singola richiesta, oppure sta aspettando qualcosa.

C’era anche un secondo indizio, ancora più utile. Il sito da visitatore anonimo volava. Da utente loggato, invece, era una tragedia.

Il motivo è semplice, ma va capito bene. Tutti i sistemi di cache (quelli che rendono i siti veloci) servono la stessa pagina già pronta ai visitatori anonimi. Chi è loggato salta tutto. Carrello, area corsi, wp-admin: ogni volta la pagina viene ricostruita da zero dal PHP. Se ricostruirla costa tanto, chi è dentro lo paga per intero, sempre.

Ecco perché il titolare, che è quasi sempre loggato, giurava che il sito fosse una lumaca. E aveva ragione lui, non gli strumenti che dicevano “tutto ok”. Il pannello di amministrazione, in certi momenti, ci metteva venti o trenta secondi ad aprire una pagina, a seconda di cosa caricava. Lì dentro non c’è cache che tenga: è tutto codice eseguito sul momento.

La regola che ha orientato tutto il resto

Me la sono scritta, perché vale per una montagna di casi.

Carico basso più pagine lente vuol dire una cosa sola: non è un problema di capacità. E se non è un problema di capacità, aggiungere core o migrare non lo risolve. Al massimo scali del trenta o quaranta per cento un problema che va ridotto del novanta.

Tradotto in soldi: spendi per un server doppio, il sito va un po’ meglio, e dopo due settimane sei di nuovo lì a lamentarti. Con la differenza che ora paghi il doppio.

Quindi prima di preventivare una migrazione, si misura. Sempre.

La misura che vale cinque minuti

C’è un test che separa nettamente un problema dell’applicazione da un problema del server. Confronti una pagina servita dalla cache con la stessa pagina costruita in tempo reale.

Ed è qui che ho fatto il primo errore, quello che voglio raccontarti perché ci cascano in tanti. Le prime misure le stavo prendendo passando dalla CDN davanti al sito. Risultato: tempi bassissimi, roba tipo un decimo di secondo. Peccato che stavo misurando la copia già pronta tenuta dalla CDN, non il sito vero. È come cronometrare un cuoco assaggiando un piatto che aveva cucinato ieri.

Appena ho misurato l’origine vera, forzando la generazione della pagina, è saltato fuori il numero onesto: diversi secondi solo per iniziare a rispondere. Su una pagina che dalla cache ne impiegava zero virgola.

A quel punto il campo era ristretto. Non era la rete, non era la CDN, non era il database (l’ho verificato, non l’ho dato per scontato: le query erano velocissime). Era il PHP che ci metteva un’eternità a mettere in piedi il sito ad ogni richiesta.

Il colpevole: un pezzo che quasi nessuno guarda

Ogni volta che WordPress gira, il PHP deve compilare il codice dei plugin e del tema. È un lavoro ripetitivo e stupido, e per non rifarlo mille volte esiste una cache apposta, l’OPcache, che tiene da parte il codice già compilato.

Quando funziona, non ci pensi mai. Quando è troppo piccola, diventa il collo di bottiglia di tutto.

E qui il sito era il caso da manuale. L’OPcache era pieno. Non “quasi pieno”: pieno, con la memoria satura e più della metà delle richieste che non trovavano il codice pronto e dovevano ricompilarlo. Su un sito con quella quantità di plugin, ricompilare ogni volta significa proprio i secondi che il titolare vedeva scorrere.

Adesso arriva il dettaglio che mi ha fatto perdere tempo, e che ti risparmio. Alzare la memoria dell’OPcache non basta, se sono saturi anche altri due parametri: il numero di file che può tenere in cache e lo spazio per le stringhe condivise. Erano pieni pure quelli. E sull’hosting di questo cliente, dal pannello puoi cambiare solo la memoria. Gli altri due si toccano solo aprendo un ticket al supporto.

Detto in un altro modo: se non sai che esistono quegli altri due, alzi la memoria, vedi che non cambia niente, e concludi che “non era l’OPcache”. Ci ero arrivato pure io, per un attimo. Era l’OPcache, eccome. Era solo mal dimensionato in tre punti invece che in uno.

📦 Per i più tecnici: i tre parametri da guardare insieme

Non basta opcache.memory_consumption. Se il resto è saturo, alzare solo la memoria non sposta niente.

• opcache.memory_consumption: quanta memoria ha la cache. Se è piena, ricompila.
• opcache.max_accelerated_files: quanti file può tenere. Un sito con molti plugin ne ha decine di migliaia, e se lo slot è pieno i file in eccesso restano fuori dalla cache.
• opcache.interned_strings_buffer: lo spazio per le stringhe condivise. Satura silenziosamente e rallenta senza dare errori evidenti.

Vanno letti col sito caldo (dopo un po’ di traffico) e via web, non da riga di comando: la CLI usa una cache separata e ti dà numeri che non c’entrano niente.

Gli errori che ho fatto (la parte più utile del racconto)

Perché te li dico? Perché la lista dei “cosa non rifare” vale più della soluzione.

Uno l’ho già raccontato: misurare dalla CDN e vedere numeri finti.

Il secondo: a un certo punto ho misurato con uno strumento a riga di comando. Comodissimo, se non fosse che quella modalità usa una cache tutta sua, diversa da quella che serve il sito vero. Ho rischiato di giudicare inutile un intervento che invece funzionava. Da lì la regola: le performance si misurano come le vede un visitatore, via web, non da dentro il server.

Il terzo: avevo puntato subito il dito contro un plugin di analisi, convinto fosse lui a rallentare tutto. Ipotesi ragionevole, e sbagliata. L’ho verificato disattivandolo e non cambiava nulla. Anche qui: prima si prova, poi si accusa.

Nessuno di questi errori è grave preso da solo. Insieme, però, sono il motivo per cui indagini “a naso” durano giorni invece che ore.

Quando invece il problema è davvero l’hosting

C’è un caso in cui la mia diagnosi cambia, ed è importante.

Su questo cliente potevo intervenire su quei parametri, o farli sistemare aprendo un ticket a un tecnico vero. Ma su tanti hosting economici quei valori non li tocchi proprio. E se apri una richiesta al supporto, oggi ti risponde un bot che ti gira tre frasi fatte e ti saluta.

Se ti ritrovi in quella situazione (non puoi cambiare i parametri e dall’altra parte non c’è nessuno che lo faccia per te), allora sì: il problema è l’hosting, e cambiarlo ha senso. Ma non per prendere “più potenza”. Per prendere un hosting gestito serio, dove quelle leve esistono e dietro c’è qualcuno che le muove.

Io per questo tipo di lavori uso Cloudways: è managed hosting su cloud veri (DigitalOcean, Vultr, AWS), i parametri li imposti o te li fanno impostare, e non ti ritrovi murato da un piano condiviso da due euro. Non è la soluzione a ogni lentezza (l’hai visto: spesso la soluzione è di configurazione, non di server), ma è il punto di partenza giusto per un sito che deve lavorare.

Cosa ti porti a casa, se il tuo sito è lento

Se hai un sito con area riservata o un e-commerce e ti sembra lento, prima di firmare un preventivo per migrare fatti una domanda: il server è davvero saturo, o sta solo lavorando male?

Guarda il carico. Se è basso mentre le pagine arrancano, occhio: non è un problema di potenza, e chiunque ti proponga di comprare un server più grosso senza aver misurato ti sta vendendo la soluzione sbagliata.

Il risultato, in questo caso, è che il sito è passato da oltre dieci secondi ad alcuni secondi. Per un’area di formazione, dove le persone entrano per seguire un corso e non è una landing su cui atterra traffico pubblicitario, va benissimo così. Nessuna migrazione, nessun hardware nuovo, nessun plugin tolto. Solo tre parametri messi a posto e qualche errore di misura evitato.

La parte che voglio ti resti non è il nome del parametro. È il metodo: misura prima di spendere, e diffida di chi ti dà la diagnosi senza aver guardato dentro.