L’installazione sconsiderata dei plugin su WordPress

Sono sempre stato un accanito critico dell’installazione sconsiderata di plugin su WordPress per numerosi motivi, ma ora lo sono diventato ancora di più.

Negli ultimi mesi sono stato al lavoro su un plugin performance critical pensato per i clienti del mio servizio di server in cloud per WordPress, ServerWP Cloud. Come mio solito, prima di mettermi a scrivere codice, ho studiato plugin analoghi, andando non solo a leggere il codice sorgente ma dando anche uno sguardo a tutte le opzioni salvate dagli stessi. Il mio obiettivo era concentrarmi soprattutto sull’ottimizzazione delle performance, pesando ogni singolo millisecondo in più che ogni funzione potrebbe comportare al caricamento.

Ebbene, quello che ho trovato è qualcosa che già immaginavo, soprattutto facendo spesso manutenzione per i vari clienti, ovvero che anche plugin famosi, di noti e stimati sviluppatori, sorprendentemente spesso nemmeno loro fanno attenzione a tanti piccoli dettagli che invece avrebbero un impatto notevole sulle prestazioni, specialmente lato server. Uno dei punti più critici? La gestione delle opzioni nella tabella wp_options di WordPress (la vera performance killer). E di questo problema, quando inizia a diventare grave, vi avvisa anche WordPress sulla pagina “Salute del sito”.

Un esempio lampante: la funzione update_option ha un terzo parametro, l’autoload. Che cos’è? In pratica, tutte le opzioni con autoload impostato su yes vengono caricate automaticamente ad ogni caricamento di pagina. Questo significa query aggiuntive al database, quindi rallentamenti, soprattutto su installazioni shared o comunque con risorse limitate.

Il problema è che, invece di riservare l’autoload solo per le opzioni effettivamente necessarie su ogni pagina (tipo il nome del sito o l’URL base), molti plugin salvano decine di opzioni superflue con autoload attivo. E il risultato è che, ogni volta che apriamo una qualsiasi pagina del sito, ci portiamo dietro query inutili per opzioni che magari servono solo su una pagina su cui eventualmente è presente uno shortcode, su una pagina dell’admin, o peggio, che non servono più perché il plugin è stato disinstallato ma ha lasciato i suoi residui nel database.

E sì, succede spesso che gli sviluppatori si “dimentichino” di agganciare alla disinstallazione del plugin anche la cancellazione delle opzioni salvate. Così tu installi un plugin, non ti piace, lo cancelli… ma nel database le sue opzioni restano lì, così come anche le tabelle custom eventualmente create dal plugin.

In questi casi diventa anche difficile individuare e pulire queste opzioni orfane, perché spesso i nomi sono poco leggibili o poco riconducibili al plugin d’origine. E andare a rimuoverle a mano può essere rischioso: potresti cancellare opzioni di plugin ancora attivi, causando malfunzionamenti.

La stessa situazione spesso si verifica anche con intere classi, caricate a prescindere se servano o meno e con i postmeta.

Ma cosa sono, in pratica, i postmeta? Sono dati aggiuntivi dei post, dei metadata, che WordPress associa ai contenuti (post, pagine, prodotti, ecc.) per memorizzare informazioni extra. Il core di WordPress, di suo, ne usa una decina, ad esempio: _edit_lock, _edit_last, _thumbnail_id, il template delle pagine, l’immagine in evidenza… insomma, pochi metadata essenziali. Il resto lo fanno i plugin, e lì spesso succede il disastro. Per farvi un esempio, con una decina di postmeta di default, se abbiamo un database con 100.000 post, i postmeta diventano un milione, ma se abbiamo plugin che impostano 20 postmeta aggiuntivi la tabella postmeta arriva ad avere 3 milioni di record.

Ogni volta che salvi un post, ci sono plugin che scrivono decine e decine di metadati per ogni piccolo elemento visivo o impostazione. Una galleria? Dieci righe di meta. Un blocco testo? Altre dieci. Un modulo? lo stesso. E il problema, ancora una volta, è che questi metadati non vengono cancellati quando il plugin viene disinstallato. Rimangono lì.

Come ho raccontato, nel lavorare al mio plugin, ho adottato un approccio maniacale all’ottimizzazione: ogni funzione, ogni riga, ogni chiamata è stata pesata. Mi sono messo lì a ragionare sul costo in millisecondi di una funzione, su come potevo ottenere lo stesso risultato ma con meno overhead.
E sì, lo ammetto, in certi momenti mi è anche venuto da ridere (o da piangere?) pensando: “Ma tanto, questo plugin girerà su siti che hanno installati 40 plugin che da soli buttano via 20 millisecondi per caricare opzioni inutili…”.

Mi sono detto: “Che senso ha che mi sbatta per risparmiare un millisecondo, se poi il plugin potrebbe girare su siti WordPress che caricano 3 builder visuali e un plugin che salva 60 postmeta per ogni post?”. Per un attimo ho anche pensato di lasciar perdere l’ossessione per l’ottimizzazione estrema, eppure, nonostante tutto questo, sono andato avanti sulla mia strada, risparmiando ogni millisecondo che era possibile risparmiare, perché questo avrebbe pesato meno sul server. Anche quando mi veniva da pensare che tanto i plugin già installati su quei WordPress avrebbero sprecato dieci volte tanto, anche quando mi dicevo che forse era tempo perso.

Perché quando si lavora con le performance, ogni dettaglio conta. Anche se sembra insignificante, anche se nel mucchio si perde.
L’obiettivo era nonostante tutto di avere un plugin leggero, scritto bene, nonostante l’importante contributo, in termini di performance, che con le sue funzionalità avrebbe aggiunto a WordPress, performance raggiunte anche in contesti già appesantiti da altri plugin.

Ma la verità è che serve buon senso e serve consapevolezza.

Bisogna installare il minor numero possibile di plugin, solo quelli davvero necessari. E devono essere plugin sviluppati da team affidabili, con recensioni reali, supporto attivo, sviluppatori presenti sui forum, non plugin abbandonati, buttati su repo anni fa e mai più aggiornati.

Nella mia esperienza come Core Developer di WordPress attribuisco sempre la massima importanza alle performance ed alla sicurezza, utilizzo i transient e la cache ed evito scrupolosamente l’utilizzo delle query con ordinamento random. A proposito di queste ultime, sono un’altra performance killer, e di strategie per evitare il loro peso ne esistono… io stesso ne ho ideate alcune.

Ad ogni modo, ogni tanto, una pulizia al database va fatta. Bisogna prendersi il tempo di analizzare cosa c’è dentro wp_options e wp_postmeta, capire quali opzioni e metadati sono orfani o inutilizzati, e sbarazzarsene. Non è semplice, spesso è noioso, ma fa la differenza.

E attenzione: anche sviluppatori bravi, magari con grande esperienza su PHP o altri framework, possono fare disastri se non conoscono bene WordPress ed il Codex. Non basta saper sviluppare in PHP e sapere cosa fa WordPress, bisogna conoscere l’ambiente in cui si lavora, le sue regole, i suoi limiti, i suoi punti critici.

Altrimenti, anche la cosa più banale può diventare un problema. E il primo a pagarne il prezzo è sempre il server.