Seguici su Telegram, ne vale la pena ❤️ ➡ @trovalost
Vai al contenuto

Ottimizzare WordPress: wp_options, tempi di caricamento e dimensioni ottimizzate delle immagini

Tag:

Come fare a ridurre il tempo di caricamento di WordPress? Domande che ci siamo già  posti in altre occasioni, in effetti: non voglio annoiarvi con le solite cose già  scritte, e preferisco invece andare ad affrontare il discorso da un’ottica pratica che ho affrontato questo fine settimana (mio malgrado).

Colgo spunto per questo articolo da un’ottimizzazione “spinta” che ho effettuato di recente sul sito di un cliente, seguito un cambio di hosting determinato da un’evidenza lampante (ne parlerò a breve, e non so ancora se ci sia da ridere o da piangere). Un mix di ottimizzazioni che hanno ridotto, nella pratica, i tempi di caricamento di un ordine di grandezza (da 10-12 secondi a 1.2-1.8 secondi). C’è anche un cambio di hosting di mezzo, ma non solo questo, purtroppo (o per fortuna, ai fini dell’articolo).

Ottimizzare il TTFB di WordPress

JsfK7ny

Il grafico sopra è tratto da una delle analisi che ho fatto via Pingdom e parlava chiaro: l’obiettivo principale era quello di ridurre il TTFB. Ne ho già  parlato qui, in altro contesto, e qui mi concentrerò sulle ottimizzazioni per database (quelle per JS e CSS, in effetti, sono state ampiamente fin troppo trattate da altri). Per chi non avesse chiaro cosa sia il TTFB, si tratta del tempo necessario perchè il server invii il primo byte della pagina web: di solito non è controllabile direttamente, e può considerarsi un indice di qualità  indiretto dell’hosting che state utilizzando (più è breve, più è veloce a caricare nella prima fase meglio è, chiaramente). Se su server ottimali il TTFB è tipicamente di poche decine di millisecondi, su server critici (per non dire peggio…) arriva anche a diversi secondi.

La fase di precarica è distinta da quella di avviamento del core e del template di WordPress, mentre il tempo globale percepito dall’utente medio è ovviamente la somma dei vari contributi. In genere – e nei casi migliori – le varie fasi si avvicendano nell’ordine dei millisecondi, per cui non sarà  scontato percepirle aprendo la pagina con il browser. Nei casi peggiori strumenti come Firefox Developer possono aiutarvi a vedere diagrammi di Gantt delle varie componenti come quelli prodotti da Pingdom.

Nota sul cambio di hosting

La cosa davvero singolare (per dirla poeticamente) è stata che testando lo stesso sito su un hosting gratuito senza SSL (da cui avrei usufruito anche di HTTP/2, almeno in teoria) ottenevo prestazioni già  migliori, in partenza, di quelle sul server originale con SSL (da circa 150 euro all’anno). Questa è la dimostrazione di una cosa importante, in questo campo: il miglior hosting che possiate sognare non è per forza proporzionale al prezzo che pagate. In genere, è sempre opportuno che disponga di opzioni facili da configurare, di buona connettività  e di strumenti affidabili a disposizione, perchè di offerte mastodontiche con database che crolla ogni mezz’ora – come di fatto mi succedeva nel secondo caso – non abbiamo davvero bisogno.

Occhio, non voglio invitarvi ad usare hosting gratuiti perchè migliori di quelli a pagamento (in genere è falso, e l’ho scritto molte volte): dico soltanto che non sempre le promesse vengono mantenute e (come avvenuto nel mio caso) non c’è stato il tempo di affrontare debitamente questo aspetto, presi da requisiti che cambiavano troppo spesso, idee abbandonate e poi riprese e altre cosette che hanno “disturbato” la riuscita al 100% del lavoro fino a quel momento. Alla fine ho deciso di migrare tutto su un hosting di V-Hosting, e sembra che le cose funzionino finalmente a dovere, per la cronaca.

Ottimizzazioni effettuate

Ovviamente non è bastato cambiare hosting, in questo caso, ma sono dovuto intervenire anche su altri aspetti. Ad esempio:

  1. ho cercato di ridurre le chiamate HTTP(S), sfruttando lazy loading delle immagini e cercando di non appesantire la home, in particolare;
  2. ho inserito numerosi transient per tutte le sezioni critiche di caricamento dei contenuti, quindi lato codice e theme child / plugin;
  3. ho sfruttato al massimo W3Cache come plugin per la gestione dei vari tipi di cache (pagina, database, ecc.);
  4. varie ed eventuali, che non sto ad elencare (localizzare tutti i file JS e CSS sul server, evitare di caricare risorse dall’esterno che rallentavano ecc.)

Ottimizzare le wp_options: motivazioni

Perchè ottimizziamo proprio le wp_options? Nel caso del sito in esame, e seguendo il flusso delle operazioni che WP effettua nel boot (le ho descritte qui, per i più curiosi) si nota come l’operazione di accesso alle option del sito avvenga prima che inizi il caricamento del template. Punto critico sospetto, quindi, su cui potenzialmente intervenire.

Per quanto possa aver trascurato dettagli tecnici importanti, l’analisi che vi propongo cerca di suggerirvi un modo per ottimizzare il vostro sito in WordPress in termini di velocità  cercando, in sostanza, di togliere di mezzo il superfluo dalla wp_options: ovviamente vi conviene avere un backup del database a portata di mano, in modo da ripristinarlo velocemente in caso di cancellazioni inopportune. Togliere il superfluo dalle wp_options, come vedremo tra un istante, aiuta a ridurre i tempi di caricamento.

Un passo indietro: il boot (o avvio) di WordPress

In pratica ad ogni chiamata di una pagina WP avvengono varie cose, tra cui:

  1. il processo di inizializzazione del sito;
  2. la pre-carica delle opzioni (questo è il punto in cui si perdeva tempo);
  3. la pre-carica delle librerie di WP;
  4. la pre-carica del template;
  5. finalmente la consegna del primo byte e, a quel punto, il progressivo caricamento dei contenuti della pagina richiesta.

Il problema

Motivo per cui mi è sembrato lecito supporre che una tabella wp_options molto popolata potesse essere una concreta causa di rallentamento del nostro sito in WordPress: in particolare, da quello che ho letto, per via di un inghippo previsto sulla colonna autoload, che non possiede un indice MySQL per cui ogni query che riguardi, ad es., le proprietà  caricate in automatico (autoload=yes), il che può essere estremamente dispendioso come tempo (il blog PressJitsu lo spiega molto bene, per chi fosse interessato).

Le soluzioni

A questo punto, per il sito “lumaca” in esame, qualsiasi operazione che richieda il pre-caricamento di opzioni di WP è soggetta a rallentamento nel caso in cui la wp_options sia troppo piena di dati, e potete rendervene conto da soli utilizzando strumenti open source come Query Monitor (un ottimo tool di analisi e profilazione delle prestazioni per capire: quanto impiega a caricare le pagine, quali query sono eseguite, quali sono critiche e quali duplicate; il tutto in tempo reale mentre visualizzate il sito).

Ai più, in questa sede, interessa sapere che più è popolata la tabella wp_options, più è probabile che il sito possa rallentare; vi anticipo che non ci sono plugin per effettuare questa pulitura in automatico, perchè il criterio è molto soggettivo, varia da sito a sito e richiede necessariamente la mano di un esperto per essere eseguita (i principianti sono avvisati: rischiate di rendere il vostro sito inservibile, quindi se proprio volete fate i test su una copia in locale, prima)

Eliminare i transient superflui o scaduti

I transient sono il primo tipo di dato da eliminare dalla wp_options, spesso i plugin che ci sono in giro li usano massicciamente, che sono una sorta di cache del database atta a velocizzare certe operazioni; fanno benissimo a farlo, solo che il più delle volte gli sviluppatori dimenticano di farli cancellare alla disinstallazione del plugin. Tra questo ed eventuali usi dei transient (alcuni theme, ad esempio, ne fanno uso per velocizzare le WP_Query) tendono ad accumulare nella wp_options dati sostanzialmente inutili nel tempo, anche perchè i transient dopo un tempo prefissato scadono e rimarranno là¬, parcheggiati per sempre nel database ad occupare spazio (e a farci perdere tempo in fase di caricamento del sito, tra l’altro).

Eliminare le opzioni generate da vecchi plugin inutilizzati

Altri dati che si possono rimuovere (non sempre, dipende dai casi) sono stati impostati lato codice, quindi via plugin, mediante add_option() e update_option(): anche qui si tratta di opzioni certamente innocue ed utili, anzi spesso necessarie a far funzionare i plugin. In altri casi, pero’, anche qui succede che i plugin si cambiano, e le opzioni degli stessi permangono perchè i programmatori si sono dimenticati di toglierli di mezzo alla disinstallazione.

Advanced: aggiungere un indice alla colonna autoload

Ho trovato, infine, un’approccio ulteriore alla riduzione dei tempi di caricamento delle options di WordPress, ed è stata anche avanzata dal sistemista di un noto servizio di hosting allo staff di sviluppatori: inserire una index sulla colonna autoload, cosa che non mi risulta essere stata fatta ma che, in via sperimentale, potreste pensare di fare anche voi (ammesso che abbiate una wp_options con più di qualche migliaio di righe) direttamente da PHPMyAdmin:

ALTER TABLE wp_options ADD INDEX (autoload);

Attenzione perchè, in questo caso, a seconda dello storage engine che usa il vostro database (InnoDB o MyISAM, ad esempio) il comportamento potrebbe essere variabile: in generale, comunque, l’aggiunta non dovrebbe creare problemi ma è sempre opportuno non effettuare queste modifiche su siti pubblici o in produzione, ma sempre su copie di test, prima. La discussione originale è ancora aperta ed è qui, per chi volesse informarsi meglio sull’argomento; al momento in cui scrivo, in particolare, non mi sembra sia stata ancora stata inserita in WordPress.

Le immagini erano lente!

Caso drammatico per molti blog fotografici, specie nel caso in cui non dispongano di troppa banda o la stessa sia a consumo: il sito è lento, poi se ci sono fotografi di mezzo con scarse competenze in fatto di fotoritocco, la frittata è completa. Vi mandano foto di 1 MB ciascuna, e sarà  difficile renderle visionabili nel sito senza costringere l’utente ad attendere diversi secondi.

La soluzione: post-ottimizzazione delle immagini

Quello che ho fatto per migliorare questo aspetto è subito detta: ho messo a scaricare via FileZilla la cartella wp-content/uploads, contenente tutte le foto del sito. Una volta fatto questo, ho creato una copia della cartella in locale (in modo da disporre delle risoluzioni originali delle immagini) ed eseguito nella cartella in questione il comando da terminale:

find . -type f -name ‘*.jpg’ -exec sips -s formatOptions 50 –resampleHeight 960 {} \;

un comando disponibile per utenti Mac, mutuato da FreeBSD (dovrebbe esserci anche per Linux, non ho verificato) che permette di comprimere in blocco le immagini, nello specifico riducendo del 50% le dimensioni (nota: 960px è l’altezza massima delle immagini per dispositivi iPhone, principale target di chi usa il sito). Alla fine ho ricaricato le immagini compresse sul sito, rigenerato le cache ed il sito, come immaginerete, ha ripreso nuova vita.

Ovviamente, almeno in teoria, per le immagini future sarà  necessario ripetere il procedimento per le nuove foto inserite.

👇 Da non perdere 👇

Questo portale esiste da 4460 giorni (12 anni), e contiene ad oggi 6366 articoli (circa 5.092.800 parole in tutto) e 12 servizi online gratuiti. – Leggi un altro articolo a caso
Non ha ancora votato nessuno.

Ti sembra utile o interessante? Vota e fammelo sapere.

Leggi anche:
Questo sito contribuisce alla audience di sè stesso.
Il nostro network informativo: Lipercubo.it - Pagare.online - Trovalost.it.