Categoria: WordPress

Negli anni ho visto un’infinità di siti WordPress nati – e spesso morti – su un tema acquistato online.
La scena è sempre la stessa: il cliente, o l’agenzia, o il freelance alle prime armi, scorre ThemeForest come fosse Netflix, trova il “tema dei sogni”, clicca Compra ora, lo installa, smanetta un po’… e voilà: sito pronto.

All’inizio sembra amore vero: è responsive, ha demo spettacolari, integra plugin per qualsiasi cosa (anche per ciò che non sapevi di poter desiderare), e l’effetto wow è assicurato.

Peccato che sotto il cofano l’effetto sia più “meh”.

Temi per tutti… quindi per nessuno

Questi template non nascono per essere veloci o ottimizzati: nascono per essere venduti.
Devono sedurre chi compra, non chi dovrà mantenerli vivi negli anni.
E per farlo, rendono tutto configurabile: ogni colore, margine, font, ombra, sfumatura… tutto diventa un’opzione nel database.

Un font? Opzione.
La dimensione del font? Opzione.
Un padding di 4px solo su mobile per un bottone che compare in una sola landing? Ma certo: opzione.

Il risultato è che ti ritrovi centinaia di opzioni caricate ad ogni pagina, anche quando mostri solo tre righe di testo.

E attenzione: parliamo di temi venduti migliaia di volte. Facciamo un conto veloce: 6.000 copie a 59$ fanno più di 350.000 dollari. Se poi guardiamo i bestseller, arriviamo tranquillamente ai milioni. Non sono prodotti pensati per ottimizzare le performance del tuo progetto: sono prodotti pensati per vendere.

E non vengono quasi mai testati su siti con decine di migliaia di articoli o con carichi di traffico elevati. Stress test? Rarissimi.

Non è colpa tua. Non è colpa di WordPress

Non c’è nulla di “immorale” nell’usare un tema comprato.
Il problema è aspettarsi che un prodotto pensato per tutti sia automaticamente perfetto per un progetto serio.

Per un blog personale o un sito vetrina da 200 visite al mese, nessun problema, per un e-commerce, un portale editoriale o un sito con 100k visitatori/mese… beh, preparati a vedere il cronometro girare.

Il tema predefinito di WordPress

C’è una risorsa che molti snobbano: il tema predefinito di WordPress.

• È gratis;
• Usa solo funzionalità del core;
• Riceve aggiornamenti regolari, senza traumi;
• È sviluppato dagli stessi che hanno creato WordPress.

Onestamente: cosa chiedere di più?

E l’effetto wow? C’è, eccome.
Il punto è che non arriva “in scatola” come nelle demo di ThemeForest. Con il predefinito hai una struttura solida, pulita e ottimizzata. Ma per trasformarla in qualcosa di davvero accattivante serve occhio, competenza e cura nei dettagli.

È qui che entra in gioco il professionista: uno che sa sfruttare il Full Site Editing di Gutenberg, giocare con tipografia e layout, e costruire una grafica su misura senza perdere performance o rompere la struttura.

E sì, torniamo al punto di partenza: se il progetto è serio, serve qualcuno che sappia fare sul serio.

Si può usare anche un tema comprato? Sì, ma serve chirurgia

Se il tema è buono come base, puoi farlo funzionare anche su progetti ad alto traffico. Basta:

• rimuovere i plugin inutili (e spesso sono molti);
• rimuovere tutti gli hook che sul nostro progetto non servono;
• eliminare o riscrivere le opzioni salvate in autoload;
• spostare nel CSS quello che è previsto per essere memorizzato sul database;
• ottimizzare i caricamenti condizionali;
• e in alcuni casi, rifare da zero parti di codice che “funzionano” ma non “performano”.

Se il progetto è serio, il tema deve seguirlo

Un tema bestseller può guadagnare milioni. Ma non è stato progettato per reggere migliaia di utenti contemporanei.
Quando ogni millisecondo conta, caricare 300 opzioni per mostrare un blocco con tre icone non è proprio la migliore idea.

Meglio un tema pulito e modulare, che sia custom, uno starter come Sage o Underscores, o ancora meglio il tema predefinito di WordPress, e soprattutto un codice messo lì con criterio da chi sa dove mettere le mani.

In conclusione

I temi preconfezionati sono come i coltellini svizzeri: utili in mille situazioni, ma se devi fare il chirurgo, meglio avere strumenti dedicati.

E quando il traffico cresce, ogni scelta fatta “tanto per” all’inizio si presenta alla porta con il conto.

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.