WordPress: introduzione alla performance nei plugin

WordPress: introduzione alla performance nei plugin

Un plugin performante è un plugin che non ha un impatto sostanziale sulle prestazioni globali di WordPress. In questo articolo parleremo di alcuni accorgimenti preliminari da adottare per creare plugin performanti.

Il backend

WordPress dispone di numerose action che vengono invocate ogni qualvolta si accede ad una sezione del backend. Esistono action generiche che vengono invocate su più sezioni ed action specifiche che vengono invocate solo su determinate sezioni.

Una buona pratica è quella di limitare al massimo il codice collegato ad action generiche ed usare invece le action più specifiche attraverso filtri ed hook.

La action su cui in assoluto a cui non si dovrebbe mai associare troppe routine è init. Come suggerisce il suo nome, questa action è la radice di tutto il flusso del codice di WordPress ed è sempre invocata.

WordPress, quindi, eseguirà sempre il nostro codice, anche dove non ce ne sarebbe bisogno. Su questa action non andrebbe mai legato codice che comporti operazioni intensive, come query ripetute al database.

Un altro aspetto da tenere presente sin dall’inizio è verificare cosa accade nel backend una volta attivato il nostro plugin impostando in wp-config.php la costante WP_DEBUG su true. Anche se questa opzione non serve a monitorare la performance del nostro plugin, è tuttavia importante per escludere l’eventualità che i rallentamenti siano causati dal codice errato.

Se il vostro plugin utilizza il database con tabelle personalizzate (come ad esempio un plugin che gestisce le prenotazioni online per un sito) tramite la classe wpdb, una buona regola è quella di mettere in cache quelle query per cui non è sempre necessario avere un refresh immediato.

Il caching delle query può essere implementato con le Transients API di WordPress:

global $wpdb;
$results = get_transient( ‘prenotazioni’ );
if( $results ) {
  // loop sui risultati
} else {
  $res = $wpdb->get_results( “SELECT * FROM prenotazioni” );
  set_transient( ‘prenotazioni’, $res, HOUR_IN_SECONDS );
} 

In questo caso abbiamo messo in cache i risultati della query per 1 ora. Quando il tempo è scaduto, il valore della chiave prenotazioni torna ad essere false ed il processo si ripete con dei nuovi risultati.

In generale queste API possono essere usate per memorizzare qualsiasi tipo di dati, quindi sono molto indicate per velocizzare alcune operazioni ripetute (come ad esempio la generazione e visualizzazione di stringhe HTML o CSS).

Un altro aspetto, stavolta più controverso, sono i task programmati usando le API Cron.

PHP non ha la capacità di attivarsi in un determinato momento in modo autonomo: c’è sempre bisogno di una richiesta GET su un file specifico che eseguirà il codice. Nello specifico, WordPress usa il file wp-cron.php per i suoi cron jobs.

Il problema è che questi cron si attivano quando si visualizza una qualsiasi sezione di un sito, sia nel backend che nel frontend. In pratica la routine di verifica avviene sempre, e questo ha un impatto sulla performance.

Quindi se si vogliono utilizzare i cron nei plugin si dovrebbe sempre tenere presente questa particolarità per evitare di sovraccaricare inutilmente WordPress.

Il frontend

Nel frontend bisogna applicare un modello specifico di ottimizzazione che parte sempre dalle condizioni peggiori per poi scalare verso condizioni migliori.

Le condizioni peggiori sono quelle rappresentate da un sito poco performante e lento a rispondere.

Se sviluppiamo in locale abbiamo bisogno di un applicativo come Sloppy per emulare le condizioni peggiori di cui parlavamo.

Applicativi come Sloppy emulano connessioni molto lente e ci aiutano a capire dove possiamo intervenire per migliorare la situazione.

Il codice CSS e JavaScript va fornito in due formati: un formato compresso e minimizzato da usare effettivamente sul sito ed un formato non compresso per le eventuali modifiche da parte dell’utente (se seguite la licenza GPL).

Le immagini da usare con i CSS devono essere ottimizzate. Se usate le icone, è preferibile usare le sprite CSS per ridurre al minimo le richieste GET.

Se usate invece dei web font per generare le icone, il peso complessivo dei file dovrà essere limitato. Tenete presente che un web font viene rilasciato in diversi formati (TTF, SVG, EOT ecc.).

La regola da seguire è semplice: inserire il codice CSS e JavaScript solo dove è richiesto e non in tutto il sito. Se sappiamo ad esempio che il nostro codice verrà usato solo nei custom post type di tipo prenotazioni possiamo scrivere:

if( is_singular( 'prenotazioni' ) ) {
  wp_register_script( ‘booking’, plugins_url() . ‘/my-plugin/js/booking.min.js’, false, ‘1.0’, true );
wp_enqueue_script( ‘booking’ );
}

Gli script JavaScript andrebbero sempre inseriti prima della chiusura dell’elemento <body> per velocizzare il caricamento delle pagine. Ecco perché usiamo l’ultimo parametro della funzione wp_register_script() impostato su true.

Inoltre se non possiamo limitare l’uso del codice a sezioni specifiche, è sempre buona norma creare un namespace per il codice CSS e JavaScript usando i prefissi per evitare conflitti. Esempio:

#my-plugin-booking-form {
}

In JavaScript:

(function( $ ) {
  $.MyPluginBooking = {};
  //…
})( jQuery );

Le ambiguità generano rallentamenti perché i browser devono comunque risolverle: la specificità implica velocità.

Conclusione

Con dei semplici accorgimenti possiamo creare plugin snelli che non hanno un grande impatto sulle prestazioni complessive di WordPress. Si tratta di semplici best practices che richiedono uno sforzo minimo per essere implementate.

Torna su