Immagini, PHP e altri guadagni di velocità

Modulo 6: Velocità · Tempo di lettura: 9 minuti

Obiettivo della lezione: Dopo questa lezione saprà applicare i maggiori guadagni di velocità rimanenti e misurarne l'effetto.

Concetti chiave: ottimizzazione delle immagini, WebP e AVIF, lazy loading, l'immagine LCP, fetchpriority, versione PHP, pulizia del database (revisioni, transients, autoload), WP-Cron, cron reale, DISABLE_WP_CRON, font esterni, Heartbeat

Lavori nell'ordine giusto

Dopo una cache di pagina (lezione 6.2), questi sono i guadagni che rendono di più, approssimativamente in ordine di sforzo rispetto a effetto:

1. immagini in ordine;
2. una versione PHP aggiornata;
3. meno componenti esterni e plugin pesanti;
4. un database pulito;
5. attività pianificate su un cron reale.

Misuri prima e dopo ogni passaggio (lezione 6.1), altrimenti non saprà cosa ha aiutato. E faccia una cosa alla volta.

Immagini: il guadagno maggiore nel browser

Nella maggior parte delle pagine, le immagini costituiscono la parte più grande di ciò che un visitatore scarica. Quanto ha imparato nella lezione 4.4 qui dà i suoi frutti:

• Dimensione corretta: non carichi immagini più grandi del necessario e lasci che WordPress offra formati più piccoli tramite srcset.
• Compressione e formato: WebP è generalmente molto più piccolo di JPEG a parità di qualità; AVIF spesso ancora più piccolo. Un plugin può convertire le immagini esistenti e fornire la versione più piccola ai browser che la supportano. Verifichi se la conversione avviene sul Suo stesso server o presso un servizio esterno.
• Lazy loading, ma non per tutto. WordPress assegna automaticamente alle immagini loading="lazy", tranne alla prima grande immagine in alto. Quell'immagine è spesso l'elemento LCP (lezione 6.1): la porzione di contenuto più grande che il visitatore vede per prima. Se viene caricata in modo lazy, il browser aspetta proprio con quella, e il Suo LCP peggiora. Per questo motivo WordPress assegna spesso al candidato LCP fetchpriority="high", in modo che il browser lo recuperi per primo.

<img src="hero-1536x864.webp" width="1536" height="864"
     fetchpriority="high" alt="Officina con biciclette allineate">
<img src="team-768x512.webp" width="768" height="512"
     loading="lazy" alt="Il team davanti al negozio">

Un'insidia: alcuni temi, costruttori di pagine e plugin di ottimizzazione applicano il lazy loading anche alla prima immagine, oppure caricano l'immagine grande come sfondo tramite CSS (che viene scoperta più tardi). In PageSpeed Insights, nella sezione LCP, vede quale elemento è e se viene caricato in modo lazy.

PHP: velocità gratuita

Ogni nuova versione principale di PHP è più veloce della precedente, e i siti WordPress ne beneficiano immediatamente, senza modificare nulla nel Suo sito. Inoltre, le versioni vecchie non ricevono più aggiornamenti di sicurezza (lezione 8.4). Se passa a una versione più recente, verifichi che i Suoi plugin e il Suo tema la supportino, e lo faccia preferibilmente prima in un sito di staging.

Nelle impostazioni PHP, guardi anche a:

• OPcache: nella maggior parte degli hosting è attivo per impostazione predefinita. Una conseguenza: un file PHP modificato può richiedere un po' di tempo prima che PHP utilizzi la nuova versione.
• memory_limit: un valore troppo basso causa errori con pagine pesanti; un valore molto alto non rende il Suo sito più veloce.

Componenti esterni e plugin pesanti

Ogni componente di terze parti è una connessione aggiuntiva e un tempo di attesa in più: font di un servizio esterno, un video incorporato, un widget di chat, codici di tracciamento, pulsanti dei social media, una mappa. Domande per ogni componente:

• È necessario? Un video che quasi nessuno riproduce può anche essere sostituito con un'immagine con un link.
• Può essere locale? I font di solito può metterli sul Suo stesso server (con un plugin o tramite theme.json in un tema a blocchi). Questo elimina una connessione ed è meglio per la Sua privacy (lezione 9.3).
• Può essere posticipato? Un widget di chat o un video può caricarsi solo dopo un clic.

Per i plugin aiuta misurare con X-Ray (con hosting su CloudLinux) o con un plugin come Query Monitor (da attivare temporaneamente, visibile solo agli amministratori). Questi mostrano quale plugin costa più richieste al database o più tempo.

Pulire il database

Un database cresce con cose che non vede:

• Revisioni (lezione 4.1): ogni versione salvata di ogni pagina. Le limiti con WP_POST_REVISIONS e ripulisca quelle vecchie.
• Commenti di spam e nel cestino, e articoli nel cestino.
• Transients: dati temporanei dei plugin in wp_options, che a volte non vengono ripuliti.
• Autoload: le opzioni in wp_options con autoload attivo vengono caricate tutte insieme a ogni richiesta. I plugin che ha rimosso già da tempo a volte lasciano lì grandi quantità di dati. Salute del sito (lezione 5.4) avvisa se i dati autoload sono molto grandi.
• Tabelle di log dei plugin (statistiche, log di sicurezza, log email) che non vengono mai svuotate.

Può ripulire con un plugin di pulizia, con WP-CLI (wp transient delete --expired, wp post delete $(wp post list --post_type=revision --format=ids) --force), oppure con la funzione di ottimizzazione di phpMyAdmin per le tabelle stesse. Esegua sempre prima un backup. Non rimuova nulla di cui non sa cosa sia.

Attività pianificate: WP-Cron

WordPress ha attività che devono essere eseguite a un determinato orario: pubblicare un articolo pianificato, controllare gli aggiornamenti, far funzionare un plugin di backup. Questo si chiama WP-Cron. Per impostazione predefinita, WP-Cron non funziona secondo un orologio, ma a ogni visita: a ogni richiesta di pagina, WordPress controlla se c'è un'attività pronta. Due svantaggi:

• Con pochi visitatori, le attività vengono eseguite troppo tardi (un articolo pianificato appare solo alla prima visita successiva).
• Con molti visitatori, il controllo avviene molto spesso, e un'attività pesante può proprio rallentare la pagina di un visitatore.

Meglio: disattivi WP-Cron durante le visite e lasci che sia un vero e proprio cronjob del server a eseguirlo ogni cinque o dieci minuti. In wp-config.php (sopra "stop con la modifica"):

define( 'DISABLE_WP_CRON', true );

E nella schermata cron del Suo pannello di hosting, un'attività ogni 10 minuti:

*/10 * * * *  /usr/local/bin/php /home/gebruiker/domains/example.com/public_html/wp-cron.php >/dev/null 2>&1

Il percorso verso PHP e verso il Suo sito varia a seconda dell'hoster; consulti la guida del Suo pannello. Oppure usi WP-CLI: wp cron event run --due-now. Verifichi successivamente in Salute del sito che non ci siano attività pianificate in ritardo.

Heartbeat e l'area di amministrazione

La Bacheca di WordPress, finché rimane aperta, comunica con il server ogni 15-60 secondi (l'Heartbeat): per il salvataggio automatico, per segnalare che qualcun altro sta modificando lo stesso articolo, e per le notifiche. Se tiene dieci schede con l'area di amministrazione aperte tutto il giorno, si tratta di migliaia di richieste. Chiuda le schede che non utilizza. Alcuni plugin di cache possono rallentare l'Heartbeat; disattivarlo completamente non è necessario e interrompe il salvataggio automatico.

Riepilogo

• Dopo la cache di pagina: immagini, versione PHP, componenti esterni e plugin, database, cron. Misuri prima e dopo, un passaggio alla volta.
• Lazy loading per tutto tranne la grande immagine in alto; quella preferisce avere fetchpriority="high".
• Una versione PHP più recente è velocità gratuita, a condizione che i Suoi plugin la supportino.
• Ripulisca revisioni, transients, spam e grandi dati autoload, sempre con un backup.
• Imposti WP-Cron su un vero cronjob con DISABLE_WP_CRON e un'attività nel Suo pannello.

Quiz

Esercizio

Esercizio A6.3: Lazy loading e formati sulla Sua home page. Inserisca l'indirizzo del Suo sito. Il programma legge la home page e osserva le immagini: la prima grande immagine è priva di loading="lazy" (e preferibilmente ha fetchpriority="high"), le immagini successive hanno il lazy loading, e quale parte delle immagini è WebP o AVIF?

Esercizio D6.3: Prima e dopo. Misuri una pagina del Suo sito tre volte in PageSpeed Insights (mobile) e annoti il valore mediano di LCP, INP (o il valore di laboratorio Total Blocking Time se non ci sono dati sul campo), CLS e il TTFB dell'esercizio A6.1. Esegua poi un miglioramento tra quelli descritti in questa lezione (immagini, versione PHP, rimozione di un componente esterno, pulizia del database o un cron reale). Misuri di nuovo tre volte e annoti i nuovi valori. Descriva cosa ha fatto e se la differenza è maggiore della normale oscillazione tra misurazioni.

Per approfondire

Questi articoli descrivono i passaggi nei pannelli di WebOké; in altri pannelli funzionano in modo simile.

• Guida DirectAdmin 14.1: Scegliere la versione di PHP (Select PHP version)
• Guida DirectAdmin 12.7: Verificare, riparare e ottimizzare un database
• Guida DirectAdmin 15.1: Processi Cron: eseguire compiti automaticamente
• Creazione di un cronjob o attività (e cosa fare se non viene eseguita)
• Guida DirectAdmin 17.4: X-Ray: individuare le pagine lente
• Collegare WP-Cron al cron di sistema (developer.wordpress.org, Inglese): https://developer.wordpress.org/plugins/cron/hooking-wp-cron-into-the-system-task-scheduler/
• Lazy loading e LCP (web.dev, Inglese): https://web.dev/articles/lcp-lazy-loading