Un plugin performante è un plugin che non ha un impatto sostanziale sulle prestazioni globali di WordPress. In questo capitolo descriveremo alcuni accorgimenti 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 a cui non si dovrebbero 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 del sorgente che comporti operazioni intensive, come query ripetute al database.
Un altro aspetto da tenere presente sin dall’inizio consiste nel 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 di un plugin, è tuttavia importante per escludere l’eventualità che i rallentamenti siano causati da codice errato.
Se un plugin utilizza il database con tabelle personalizzate (come ad esempio un'estensione 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 dato, quindi sono molto indicate per velocizzare alcune operazioni ripetute (come ad esempio la generazione e la visualizzazione di stringhe HTML o CSS).
Un altro aspetto, stavolta più controverso, sono i task programmati usando le API Cron. PHP infatti 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 Web, 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, come per esempio connessioni molto lente che aiutano a capire dove intervenire per migliorare la situazione.
Il codice CSS e JavaScript va fornito in due formati: uno compresso e minimizzato da usare effettivamente sul sito Internet ed un formato non compresso per le eventuali modifiche da parte dell’utente (se si segue la licenza GPL).
Le immagini da usare con i CSS devono essere ottimizzate. Se usate le icone, è preferibile impiegare le sprite CSS per ridurre al minimo le richieste GET.
Se si utilizzano invece dei Web font per generare le icone, il peso complessivo dei file dovrà essere limitato. Si tenga presente che un Web font viene rilasciato in diversi formati (TTF, SVG, EOT ecc.).
In questo caso la regola da seguire è semplice: inserire il codice CSS e JavaScript solo dove è richiesto e non in tutto il sito Internet. 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, ad esempio:
#my-plugin-booking-form {
}In JavaScript:
(function( $ ) {
$.MyPluginBooking = {};
//…
})( jQuery );Le ambiguità generano rallentamenti, perché i browser devono comunque risolverle, mentre la specificità implica velocità.
Conclusione
Con dei semplici accorgimenti possiamo creare plugin snelli che non hanno un grande impatto sulle prestazioni complessive di WordPress; Nel prossimo capitolo verrà affrontato il discorso relativo a plugin e sicurezza.