Il plugin da 49 euro l'anno può costare mesi. Non sul bonifico: sul runtime, sulle CVE, sul giorno in cui non si aggiorna più.
Il costo vero di un plugin non è il canone. È il JavaScript che finisce in ogni pagina, la query extra sul database, la patch che arriva in ritardo, e il giorno in cui l'autore smette di rispondere. Il listino è la voce più facile da leggere. È anche la meno informativa.
In breve: un plugin è codice di terzi in produzione. Pesa su tre conti: runtime (byte, CPU, query), operatività (aggiornamenti, conflitti, test) e rischio (superficie di attacco, abbandono, lock-in). Il prezzo, quando c'è, è quasi sempre la voce più piccola. Si tiene bassa la superficie, non si colleziona funzioni.
Cosa trovi in questo articolo
Il prezzo è un acconto, non il totale
Chi sceglie un plugin guarda tre cose: se fa la funzione, se si installa in cinque minuti, quanto costa all'anno. È un criterio da vetrina. In produzione il plugin diventa parte dello CMS: gancio sul ciclo di vita della pagina, tabelle nel database, cron, chiamate HTTP verso un SaaS, a volte un proprio pannello. Tutto questo resta acceso anche nei giorni in cui quella funzione non serve a nessuno.
Il canone copre la licenza, non il lavoro. Ogni aggiornamento del nucleo del CMS va provato contro quel plugin. Ogni conflitto con il tema o con un altro modulo è tempo di debug. Ogni funzione "gratis" che inietta uno slider, una chat, un pixel, un font da un CDN di terzi, è peso sul client. Nessuna di queste voci compare nel listino. Tutte compariranno nel backlog, o in un incidente.
Il pezzo sta nel cluster Prodotto per questo: scegliere un plugin è una decisione di perimetro, non di catalogo. Si sta accettando un fornitore in più, con un ciclo di vita che non si controlla.
Runtime: JavaScript, query, peso in pagina
Molti plugin non "stanno nel backend". Scrivono nel frontend. Aggiungono CSS, JavaScript, font, iframe, web beacon. web.dev documenta da anni che lo JavaScript di terzi compete per banda, per parse e per il thread principale. Non è un dettaglio di front-end. È il tempo che passa tra il tap e la pagina che risponde, lo stesso contratto descritto nella guida sulla performance del sito.
Il danno tipico non è un file da 2 MB visibile nel listino. È l'accumulo. Un plugin di form che carica un validatore. Un popup che carica un editor. Un "optimizer" che riscrive l'HTML. Un tag manager già gonfio. Ognuno, da solo, sembra innocuo. Insieme spostano LCP e INP. Lighthouse ha una voce dedicata ai third-party: non è un punteggio da inseguire, è un elenco di colpevoli nominati.
C'è anche il lato server. Plugin che fanno una query a ogni richiesta, che non usano cache, che scrivono opzioni autoload nel database, che lanciano cron aggressivi. Il sito "è lento" e si parla di RAM. Prima si chiede: quale modulo sta interrogando il database su ogni hit della home. Senza quella domanda si compra potenza per coprire una SELECT inutile.
Sicurezza: superficie, ritardo di patch, abbandono
OWASP, nel Top 10, classifica da anni i componenti vulnerabili o non aggiornati tra i rischi applicativi. La scheda A06:2021 lo dice senza giri: si è vulnerabili se non si sa cosa si sta usando, se non si scansiona, se non si patcha in tempo. Un CMS con venti plugin è venti superfici, venti cicli di rilascio, venti autori. Non uno.
Il ritardo di patch è il costo nascosto più concreto. Il nucleo del CMS ha un vendor visibile e una cadenza. Il plugin ha un autore, a volte uno solo, a volte una società che ha cambiato priorità. Tra la pubblicazione di una CVE e l'update del modulo possono passare giorni o mesi. In quel finestra il sito è esposto anche se "il CMS è aggiornato". Le patch del nucleo non coprono il codice di terzi. La guida sulle patch di sicurezza parte da questo ritmo: criticità subito, il resto in finestra, mai "quando capita".
Poi c'è l'abbandono. Plugin senza commit da anni, incompatibili con la versione corrente del CMS, con un ticket di supporto chiuso e mai ripreso. Restano installati perché "fanno ancora quella cosa". In realtà fanno quella cosa e tengono aperta una superficie che nessuno patcha più. La directory del CMS, quando esiste, mostra la data dell'ultimo aggiornamento: è un dato operativo, non un dettaglio da scheda prodotto. Un modulo fermo mentre il nucleo avanza è un debito con data di scadenza ignota.
Non serve una CVE specifica per prendere sul serio il rischio. Serve un inventario: nome, versione, autore, ultima release, se ha accesso al database, se esegue PHP o JavaScript sul pubblico. Senza inventario non si patcha. Si spera.
Lock-in: uscire costa più che entrare
Installare è un clic. Disinstallare è un progetto. I dati finiscono in tabelle custom, shortcode nell'HTML, block type nel contenuto, rewrite nell'URL, hook che altri plugin danno per scontati. Il giorno in cui il vendor alza il prezzo, chiude il prodotto o pubblica un'ultima versione "legacy", non si "toglie il plugin". Si migra un pezzo di prodotto.
Questo è lock-in, e non è un problema solo dei SaaS. Un plugin che scrive 10.000 shortcode negli articoli ha lo stesso effetto di un formato proprietario. Il costo di uscita va stimato il giorno dell'ingresso, non il giorno della rottura. La domanda utile è: se questo modulo sparisce tra dodici mesi, i contenuti restano leggibili in un formato nostro?
Come tenere bassa la superficie
La mossa non è "zero plugin". È un perimetro. Funzioni di base (contenuti, media, form essenziali, SEO tecnico minimo) stanno nel nucleo o in pochi moduli governati. Il resto o è un differenziatore da sviluppare, o non entra.
Ridurre la superficie è una scelta di prodotto. Si può tenere un CMS estendibile e governare l'elenco con inventario e owner. Oppure si sceglie una piattaforma che tiene nel nucleo le funzioni ricorrenti, come la piattaforma KeideaCMS, e si estende solo ciò che è davvero specifico del sito. Il punto non è il marchio. È quanti pezzi di terzi devono restare in produzione per fare il mestiere della pagina. Meno pezzi, meno cicli di patch, meno JavaScript di cui non si è autori.
Prima di aggiungere un modulo: quale problema misura, chi lo manutiene, cosa succede se lo si toglie, quanto JavaScript e quante query introduce, quando è stato aggiornato l'ultima volta. Se una di queste risposte manca, non è un plugin. È una scommessa.
Ha senso quando. Non serve quando
Ha senso un plugin quando copre un problema commodity, ha un vendor visibile, un ritmo di release, e i dati restano esportabili. Un gateway di pagamento mantenuto, un connettore verso un sistema già scelto, una libreria con test e changelog. In quei casi comprare è più onesto che riscrivere.
Non serve quando la funzione è un extra di marketing ("un'altra slider", "un popup", "un contatore di visite" già coperto dall'analytics), quando l'autore è irreperibile, quando il modulo chiede privilegi ampi per fare poco, quando per "risolvere la lentezza" si aggiunge un optimizer sopra un tema già pesante. Lì si sta pagando rumore.
Errori da evitare
Scegliere sul prezzo. Il modulo da pochi euro l'anno può costare una settimana di incidente. Il modulo a pagamento può costare lo stesso, se è abbandonato.
Installare per provare e lasciare attivo. Il plugin di test resta in produzione. La superficie non torna indietro da sola.
Aggiornare il CMS e saltare i plugin. Si ottiene un nucleo "a posto" e una superficie vecchia. L'attaccante non è obbligato a entrare dal nucleo.
Mettere un optimizer sopra il disordine. Si nasconde il peso, si rompe l'ordine di caricamento, si perde il controllo su cosa è deferrito.
Non avere un inventario. Senza nome, versione e owner, le patch sono un rito, non un processo.
In sintesi
Un plugin è codice di terzi con un ciclo di vita che non si possiede. Il canone è l'acconto. Il totale è runtime, patch, conflitti e, un giorno, l'uscita. Si tiene un inventario, si misura il JavaScript e le query, si patcha con lo stesso ritmo del nucleo, si rifiuta ciò che non ha autore. Meno rumore, più metodo: la funzione entra se sopravvive a quelle domande. Altrimenti resta fuori.
Fonti
web.dev, Loading third-party JavaScript.
Chrome for Developers, Lighthouse: Reduce the impact of third-party code.
WordPress.org, Security (ruolo di nucleo, temi e plugin nella superficie).
Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.
