Con una piattaforma si pubblica un sito in un pomeriggio, ed è un vantaggio reale che non ha senso negare. La domanda utile non è quale approccio sia migliore in assoluto — non esiste una risposta — ma quali vincoli si accettano e quanto costano quando il progetto cambia. Provo a metterli in fila senza tifoseria.
Cosa si guadagna con una piattaforma#
Tempo iniziale, un pannello di amministrazione già pronto e testato da milioni di persone, aggiornamenti del nucleo gestiti da altri, e un ecosistema in cui quasi ogni problema comune è già stato risolto da qualcuno. Per un blog, una piccola vetrina o un catalogo con esigenze standard, riscrivere queste cose da zero non ha alcun senso economico — ed è un punto su cui vale la pena essere onesti anche quando si vende sviluppo su misura.
Il codice che non avete scritto e che servite comunque#
Perché il peso cresce per ACCUMULO e non per scelta. Tema generico Deve coprire tutti i casi d'uso previsti dal suo autore, quindi carica CSS e JavaScript anche per le sezioni che non usate. Un tema con 40 modelli di pagina serve il codice di tutti e 40. Ogni estensione aggiunge + il proprio foglio di stile (spesso su TUTTE le pagine) + il proprio JavaScript (idem) + le proprie query al database (a ogni richiesta) + a volte la propria copia di una libreria già presente Il risultato tipico di un sito con 15 estensioni: 18 fogli di stile, 26 script, 90+ query per pagina — e nessuna di queste scelte è mai stata presa da qualcuno. Sono la somma di quindici decisioni ciascuna ragionevole.Il punto interessante è che nessuna di queste scelte è stata presa da qualcuno. Ogni estensione, presa singolarmente, era ragionevole e risolveva un problema reale. È la somma a diventare il problema, e la somma non compare in nessuna decisione.
# Il conto si fa, non si stima. Due comandi su qualunque sito.# 1. Quanti file e quanti byte prima che compaia qualcosa:npx lighthouse https://esempio.it --form-factor=mobile \> --only-categories=performance --output=json \> | jq '.audits["network-requests"].details.items | length,> ([.[] | .transferSize] | add / 1024 | floor)'64 # richieste2840 # KB trasferiti# 2. Quanto di quel JavaScript viene effettivamente usato:# DevTools → Coverage → ricarica. La colonna rossa e' codice# scaricato, interpretato e mai eseguito. Su un sito a plugin# e' comunemente fra il 60% e l'80%.# Confronto: questo sito, stesso comando12 # richieste310 # KB trasferitiÈ anche la causa più frequente di Core Web Vitals non superati, e la più difficile da correggere — perché non c'è un colpevole singolo da rimuovere.
La superficie d'attacco#
Ogni estensione è codice di terzi che gira con gli STESSI PRIVILEGIdel sito: accesso al database, ai file, alle sessioni degli utenti.La dinamica che rende il rischio diverso da quello di un sito su misura: 1. Un ricercatore pubblica una vulnerabilità nel plugin X 2. Il plugin X è installato su decine di migliaia di siti 3. Esistono già scanner automatici che cercano quel plugin 4. Lo sfruttamento comincia entro ORE dalla pubblicazioneNon è mirato: è a tappeto, e il vostro sito non è stato scelto —è stato trovato. Da cui due conseguenze operative: → la manutenzione non è opzionale ed è soprattutto TEMPESTIVA: aggiornare in fretta, non "quando capita"; → ogni estensione installata "per provare" e mai rimossa resta una porta aperta, anche se disattivata (i file sono ancora lì e in molti casi ancora raggiungibili).Va detto il rovescio, per correttezza: un sito su misura non è sicuro per costruzione. È sicuro se chi l'ha scritto sa cosa sta facendo. Il vantaggio non è l'assenza di vulnerabilità, è che non siete un bersaglio noto e automatizzabile: nessuno pubblica un exploit per il vostro codice, perché il vostro codice esiste in una copia sola.
Portabilità#
Che cosa si porta via davvero, il giorno in cui si cambia. ✓ Portabile quasi sempre testi, immagini, elenco prodotti, anagrafica clienti, ordini in formato tabellare ~ Portabile con lavoro struttura delle pagine (va rifatta), URL (servono i redirect 301, o si azzera il lavoro SEO fatto), impostazioni ✗ Non portabile personalizzazioni fatte nel pannello, automazioni configurate a interfaccia, integrazioni proprietarie, e — sulle piattaforme chiuse — il codice, che non è mai stato vostroLa domanda da porre PRIMA di iniziare, non dopo: "Se fra tre anni volessi andarmene, che cosa mi porto via e in che formato?"Una risposta vaga è già l'informazione che cercavate.La riga sui redirect 301 merita un'annotazione, perché è il costo nascosto più caro di una migrazione: cambiare piattaforma quasi sempre cambia la struttura degli URL, e senza una mappa di reindirizzamenti completa si azzera tutto il lavoro di posizionamento accumulato su quelle pagine. Il traffico non cala del dieci per cento: sparisce, e ricostruirlo richiede mesi.
Dove il su misura costa di più#
// Il costo meno visibile del su misura, ed è simmetrico a quello// della piattaforma: il vincolo si sposta da un fornitore a UNA PERSONA.//// Un progetto su misura senza:// - un README che permetta a un estraneo di avviarlo// - convenzioni riconoscibili invece di soluzioni personali// - dipendenze standard e documentate// - un registro delle decisioni non ovvie//// ...è manutenibile solo da chi l'ha scritto. È un lock-in, solo// su una persona invece che su una piattaforma — e per certi versi// peggiore, perché una piattaforma non si ammala e non cambia lavoro.//// La contromisura è la stessa in entrambi i casi: chiedere, PRIMA// di iniziare, cosa si riceve alla consegna oltre al sito che// funziona. Vedi /blog/blueprint-architettura-replicabile.Investimento iniziale e tempi più lunghi sono evidenti e onesti. Il costo meno visibile è quello descritto sopra: senza documentazione e convenzioni riconoscibili, il progetto diventa manutenibile solo da chi l'ha scritto. È un vincolo simmetrico a quello della piattaforma, e per certi versi peggiore — una piattaforma non cambia lavoro e non smette di rispondere alle email.
La contromisura è la stessa in entrambe le direzioni: chiedere prima di iniziare cosa si riceve alla consegna oltre al sito funzionante. Il codice sorgente, gli accessi, la documentazione di avvio e pubblicazione, l'elenco delle dipendenze. Se la risposta è vaga, la risposta è già arrivata.
Il criterio#
Il criterio operativo, e l'unico che ho trovato affidabile: Contate quante delle vostre esigenze cadono FUORI dallo schema previsto dalla piattaforma. ZERO esigenze fuori schema → la piattaforma è la scelta razionale, e il su misura è spreco. Un blog aziendale, una vetrina con contatti, un catalogo semplice: sono problemi risolti, e riscriverli è pagare due volte per la stessa cosa. UNA O DUE → zona grigia. Ciascuna diventa un'estensione aggiuntiva o una forzatura che lavora contro lo strumento. Vale la pena contare il costo di quelle forzature, non solo quello iniziale. TRE O PIÙ → si sta usando la piattaforma per fare qualcosa per cui non è stata progettata. Da qui in poi ogni aggiornamento del core rischia di rompere le forzature, e il costo di manutenzione supera quello che il su misura avrebbe richiesto all'inizio.E la domanda vale anche al contrario: se state facendo scrivere dazero un blog senza requisiti particolari, state pagando per qualcosache esiste già e funziona meglio.| Piattaforma | Su misura | |
|---|---|---|
| Tempo alla prima pubblicazione | giorni | settimane |
| Costo iniziale | basso | alto |
| Peso servito | cresce per accumulo | solo ciò che serve |
| Core Web Vitals | difficili sopra le 10 estensioni | controllabili |
| Superficie d'attacco | ampia e nota | ridotta e non catalogata |
| Manutenzione | obbligatoria e tempestiva | periodica |
| Esigenze fuori schema | costo crescente per ciascuna | costo lineare |
| Portabilità | contenuti sì, il resto no | tutto, se documentato |
| Il vincolo è su | un fornitore | una persona |
| Chi può metterci mano | molti | chi legge la documentazione |
La conclusione onesta: la scelta non si decide sul tipo di progetto ma sulla distanza fra quello che vi serve e quello che la piattaforma già fa. Se quella distanza è zero, pagare per il su misura è spreco. Se è grande, la piattaforma non la colma: la si riempie di estensioni e di forzature, e si finisce per pagare due volte — una in licenze e una in manutenzione di un sistema che sta lavorando contro sé stesso.