Indice dei contenuti dell'articolo:
Il titolo è volutamente provocatorio, perché riassume in poche parole una narrazione che oggi sentiamo sempre più spesso: WordPress sarebbe lento, brutto, vecchio, scritto con tecnologie superate e destinato a essere rimpiazzato da nuovi CMS sviluppati rapidamente con l’aiuto dell’intelligenza artificiale, magari usando stack più “moderni” come Node.js, Go, MongoDB, Redis, architetture headless, microservizi, code asincrone e database NoSQL.
La tesi, in apparenza, sembra perfino ragionevole. WordPress nasce in un’altra epoca del Web. Nasce quando il concetto di “applicazione web moderna” era molto diverso da quello attuale, quando il blogging era ancora una delle forme principali di pubblicazione online, quando PHP era il linguaggio di riferimento per mettere rapidamente in piedi siti dinamici e quando il classico stack LAMP, ovvero Linux, Apache, MySQL e PHP, rappresentava una scelta semplice, economica, disponibile praticamente ovunque e alla portata di molti. WordPress nasce nel 2003 come fork di b2/cafelog, realizzato da Matt Mullenweg e Mike Little, con l’obiettivo dichiarato di offrire un sistema elegante per la pubblicazione personale; oggi il progetto ufficiale lo descrive ancora come software basato su PHP e MariaDB e licenziato GPL.
Il problema è che, partendo da questa verità storica, molti arrivano a una conclusione sbagliata: se WordPress è nato nel 2003, allora è necessariamente inadatto al 2026. Se è scritto in PHP, allora è per forza lento. Se usa MySQL o MariaDB, allora è per forza meno moderno di MongoDB. Se non nasce asincrono come Node.js, allora non può reggere il traffico. Se l’AI oggi può generare in pochi giorni un CRM, un gestionale o un prototipo SaaS, allora dovrebbe poter generare anche un CMS editoriale migliore di WordPress.
Questa è la classica situazione in cui si rischia di reinventare la ruota, confondendo la modernità dello stack con la maturità del prodotto, e la velocità di sviluppo iniziale con la sostenibilità reale di una piattaforma nel tempo.
WordPress nasce in un Web completamente diverso
Per capire WordPress bisogna tornare al contesto in cui è nato. All’inizio degli anni Duemila il Web non era dominato da framework JavaScript, container, orchestratori Kubernetes, pipeline CI/CD, API headless e database distribuiti. I CMS dell’epoca erano sistemi spesso complessi, pesanti, nati per comunità, portali, forum, gestione contenuti e pubblicazione collaborativa. Drupal, ad esempio, affonda le proprie radici nel 2001, mentre Joomla nascerà nel 2005 come fork del CMS Mambo.
In quel panorama, WordPress non nasce per essere “il CMS universale definitivo”. Nasce con un obiettivo molto più concreto: rendere semplice pubblicare contenuti. Blog, articoli, pagine, archivi, categorie, commenti, feed RSS, permalink comprensibili, temi personalizzabili. La sua forza iniziale non era l’astrazione ingegneristica da manuale universitario, ma la capacità di installarsi facilmente su hosting economici, parlare con MySQL, usare PHP, funzionare su Apache e permettere a una persona non tecnica di pubblicare online senza dover diventare uno sviluppatore.
È facile oggi guardare a quella scelta e dire: “Avrebbero dovuto usare Go, Node.js, MongoDB, Redis, un’architettura asincrona e un sistema a eventi”. Il punto è che quelle tecnologie, nel 2003, o non esistevano ancora o non erano minimamente nel perimetro realistico di un CMS open source generalista. Go è stato annunciato pubblicamente da Google nel 2009, Node.js nasce anch’esso nel 2009, MongoDB arriva alla prima versione nel 2009 e Redis inizia sempre in quel periodo.
Dire oggi che WordPress avrebbe dovuto nascere su tecnologie che all’epoca non erano disponibili è un esercizio teorico, non una critica tecnica. È come rimproverare a un’automobile progettata negli anni Settanta di non avere un motore elettrico con batterie allo stato solido. Può essere interessante come discussione accademica, o al pub con qualche amico nerd con hamburger e una birra, ma non cambia la realtà: WordPress ha vinto perché ha risolto un problema reale con gli strumenti disponibili nel suo tempo.
MySQL, MyISAM, InnoDB e il senno di poi
Un’altra critica frequente riguarda il database. WordPress nasce in un periodo in cui MySQL era la scelta più naturale per applicazioni web economiche e diffuse. Oggi parliamo con disinvoltura di InnoDB, transazioni, isolamento, foreign key, MVCC, crash recovery, cluster, replica avanzata, query planner evoluti e motori ottimizzati. Ma il MySQL dei primi anni Duemila era un prodotto diverso, e per molto tempo MyISAM è stato uno storage engine estremamente diffuso.
MyISAM aveva limiti importanti: niente transazioni, niente foreign key, lock a livello tabella, nessun MVCC. La documentazione MySQL elenca esplicitamente l’assenza di supporto a foreign key e transazioni per MyISAM, mentre InnoDB supporta vincoli di integrità referenziale, locking più granulare e livelli di isolamento transazionale.
Anche qui, con il senno di poi, possiamo dire che sarebbe stato meglio progettare ogni cosa sopra un database transazionale maturo, con schema rigoroso, vincoli, relazioni e garanzie ACID applicate in modo sistematico. Ma il punto non è stabilire che cosa avremmo fatto oggi. Il punto è comprendere che WordPress ha costruito il proprio successo dentro un ecosistema tecnico, economico e culturale specifico: hosting condivisi, PHP ovunque, MySQL ovunque, FTP, poca automazione, poche competenze sistemistiche disponibili per l’utente medio e un bisogno enorme di strumenti semplici per pubblicare.
Oggi MySQL è cambiato, MariaDB è diventato un’alternativa molto diffusa, Percona Server ha proposto miglioramenti e ottimizzazioni, InnoDB è la norma per installazioni serie, e le infrastrutture moderne permettono tuning, replica, caching, monitoring, slow query log, profiling e analisi molto più raffinate. Però WordPress conserva una forte compatibilità storica e una propria astrazione database, $wpdb, che non equivale a un ORM moderno e non usa PDO come interfaccia standard. La documentazione ufficiale descrive wpdb come la classe usata per interagire con il database WordPress senza scrivere direttamente ogni dettaglio di connessione, pur restando dentro la logica storica del CMS.
La tentazione moderna: rifare WordPress con AI, Node.js, Go, MongoDB e Redis
Da qualche anno, e in modo ancora più marcato con l’esplosione degli strumenti AI per lo sviluppo software, si è diffusa una convinzione: se oggi l’intelligenza artificiale può produrre codice rapidamente, allora è possibile progettare da zero un nuovo CMS editoriale, più veloce di WordPress, più moderno, più pulito, più scalabile e magari vendibile a blog, aziende, testate giornalistiche e portali informativi stanchi di un WordPress ritenuto lento e macchinoso.
Il ragionamento commerciale è semplice: prendiamo i difetti percepiti di WordPress — query lente, plugin pesanti, backend datato, codice legacy, assenza di asincronicità nativa — e li trasformiamo in una proposta di mercato.
Ti migriamo da WordPress a un CMS moderno, sviluppato custom, ottimizzato per l’editoria, con tecnologie cloud-native, API first, headless, MongoDB, Redis, Node.js o Go. Basta crash con qualche centinaio di utenti online. Basta plugin ammazza-server. Basta PHP.
Il problema è che questa promessa confonde diversi piani. Un conto è generare un prototipo. Un conto è sviluppare un backend che salva articoli, autori, tag e immagini. Un conto è mostrare benchmark sintetici in cui una API scritta in Go risponde in pochi millisecondi. Un altro conto, completamente diverso, è costruire un CMS usabile ogni giorno da redazioni vere, con permessi, revisioni, anteprime, workflow, SEO, media library, compatibilità editoriale, migrazioni, ruoli, integrazioni, newsletter, push notification, advertising, paywall, multilingua, redirect, canonical, sitemap, feed, commenti, import/export, sicurezza, aggiornamenti e supporto continuativo.
L’AI può accelerare lo sviluppo, ma non sostituisce l’esperienza di prodotto. Può aiutare a scrivere codice, documentare funzioni, generare test, creare interfacce, suggerire query, trovare bug e perfino profilare colli di bottiglia. Ma non crea automaticamente un ecosistema, non crea fiducia, non crea marketplace, non crea una community di sviluppatori, non crea competenze diffuse sul mercato e non garantisce che il software generato oggi sarà manutenibile tra cinque anni.
WordPress non è solo codice: è un ecosistema
Il punto più sottovalutato da chi vuole “rifare WordPress” è proprio questo: WordPress non è soltanto un CMS scritto in PHP. WordPress è un ecosistema tecnico, economico e professionale.
Da una parte c’è il Core, con il suo ciclo di release, le API, gli hook, i filtri, gli shortcode, l’editor a blocchi, la REST API, la retrocompatibilità e l’enorme quantità di codice testato sul campo. La documentazione ufficiale descrive il sistema di hook come basato su Actions e Filters, cioè punti di estensione che consentono a plugin e temi di agganciarsi al comportamento del Core; allo stesso modo, la Shortcode API e la REST API sono pezzi fondamentali della capacità di WordPress di essere esteso e integrato.
Dall’altra parte esiste un mercato enorme: plugin gratuiti, plugin premium, temi free, temi commerciali, marketplace come ThemeForest, page builder, servizi SaaS integrati, agenzie specializzate, freelance, sistemisti, sviluppatori, designer, consulenti SEO, copywriter, editor, esperti di performance, esperti di sicurezza e hosting provider che conoscono WordPress in modo profondo.
La directory ufficiale dei temi WordPress dichiara oltre 14.000 temi gratuiti, mentre l’ecosistema plugin supera ampiamente le decine di migliaia di estensioni disponibili tra repository ufficiale, marketplace e sviluppatori indipendenti.
Questo significa che quando un’azienda sceglie WordPress non sta scegliendo soltanto un CMS realizzato in PHP. Sta scegliendo un ecosistema in cui quasi ogni problema comune è già stato affrontato da qualcuno. Vuole il multilingua? Esistono soluzioni mature. Vuole newsletter? Esistono integrazioni. Vuole notifiche push? Esistono plugin e servizi. Vuole un builder visuale come Elementor o Visual Composer? Esistono. Vuole e-commerce? WooCommerce. Vuole community? BuddyPress, BuddyBoss e soluzioni correlate. Vuole e-learning? LearnPress, LearnDash e alternative. Vuole un tema editoriale professionale? Con poche decine di euro può partire da un tema commerciale e adattarlo.
Un CMS custom scritto da zero può anche essere più elegante sul piano architetturale, ma parte da zero proprio dove WordPress è più forte: adozione, estensioni, conoscenza diffusa, interoperabilità e fiducia.
I numeri contano: WordPress è ancora dominante
Secondo W3Techs, a fine giugno 2026 WordPress è usato dal 41,5% di tutti i siti web analizzati e detiene il 59,2% del mercato tra i siti di cui è noto il CMS; la stessa fonte indica anche una presenza significativa di installazioni WordPress 7, pur con WordPress 6 ancora molto diffuso.
Questi numeri sono importanti perché mostrano una cosa: WordPress non è una nicchia nostalgica. Non è il CMS del “blogger della domenica” rimasto fermo al 2008. È un’infrastruttura di pubblicazione globale, usata da hobbisti, professionisti, PMI, enti pubblici, brand internazionali, media company e testate editoriali.
Il progetto WordPress è arrivato al ramo 7.0, con interventi ufficiali anche su performance, accessibilità, gestione dei pattern, caricamento degli stylesheet e miglioramenti dell’esperienza admin. WordPress, dichiara l’uso da parte di editori e brand come Al Jazeera, News Corp, USA TODAY Sports Media Group e altri; TechCrunch è presente nello Showcase ufficiale WordPress come pubblicazione enterprise; Vox Media ha annunciato la migrazione a WordPress VIP per i propri siti precedentemente basati su Chorus e Pinnacle.
Anche in Italia, Il Fatto Quotidiano azienda a cui abbiamo fatto consulenza tra i nostri clienti è un caso interessante: già nel 2014 un articolo pubblicato sullo stesso sito lo indicava come giornale online di successo basato su WordPress, e il sito attuale espone ancora risorse sotto percorsi wp-content, segnale tecnico compatibile con una base WordPress o con componenti WordPress ancora presenti nello stack.
Il vero concetto fondamentale: un sito editoriale è quasi sempre heavy read
Per discutere seriamente di performance bisogna partire da una distinzione fondamentale: un CMS editoriale è quasi sempre un sistema heavy read. Significa che il numero di letture è enormemente superiore al numero di scritture.
Una redazione può pubblicare 50, 100, 300 articoli al giorno. Un grande sito può aggiornare homepage, categorie, tag, autori e contenuti live con frequenza alta. Ma il traffico pubblico è composto quasi interamente da letture: utenti che aprono articoli, pagine categoria, homepage, gallery, tag, ricerche, feed, contenuti correlati. Rispetto alle visite pubbliche, le operazioni di scrittura — inserimento articoli, upload immagini, revisioni, modifiche, pubblicazioni — sono una minima parte.
Questo cambia tutto. Se un articolo viene pubblicato, letto da centinaia di migliaia di utenti e rimane sostanzialmente invariato per giorni, settimane o mesi, la domanda vera non è: “Quanto è veloce PHP a generare questa pagina ogni volta?”. La domanda vera è: perché dovrei rigenerarla ogni volta?
Qui entrano in gioco Varnish, oggi nel mondo open source associato anche alla transizione verso Vinyl Cache, le cache HTTP, le CDN, il full page caching, gli edge cache, gli oggetti persistenti in Redis, il tuning del database e la corretta invalidazione. Varnish è descritto dalla documentazione come un web application accelerator, ovvero un reverse proxy HTTP di caching installato davanti al server origin, capace di servire contenuti dalla cache senza tornare ogni volta al backend. Nel 2026 il progetto open source è stato rinominato Vinyl Cache, con cambiamenti anche nei pacchetti e nei nomi di servizio in alcune distribuzioni.
A quel punto la domanda “Node.js è più veloce di PHP?” diventa meno rilevante di quanto sembri. Se una pagina pubblica viene servita da cache HTTP, l’utente non sta interrogando PHP, non sta interrogando MySQL, non sta eseguendo il tema WordPress, non sta caricando plugin lato server. Sta ricevendo una risposta già pronta da un reverse proxy o da una CDN.
In questo scenario, che MongoDB risponda in 20 millisecondi e MySQL in 300, o che Go generi una risposta in 5 millisecondi e PHP in 100, può essere interessante in casi specifici, ma non è necessariamente decisivo per il traffico pubblico. Se l’articolo viene cachato per ore, giorni o settimane, il collo di bottiglia non è più il linguaggio. Diventa la strategia di caching, l’invalidazione, il comportamento sulle pagine non cacheabili, il traffico autenticato, la qualità del frontend, il peso degli asset, la CDN, le immagini, il JavaScript, la pubblicità, i tracciamenti e la stabilità dell’infrastruttura.
“WordPress è lento perché i plugin sono lenti”: una mezza verità
Dire che WordPress è lento perché i plugin sono lenti è una mezza verità. Esistono plugin scritti male, plugin che fanno query assurde, plugin che caricano asset ovunque, plugin che usano admin-ajax.php per qualunque cosa, plugin che tracciano visualizzazioni articolo con una richiesta dinamica a ogni pageview, plugin che invalidano cache inutilmente, plugin che schedulano cron pesanti, plugin che salvano log in tabelle senza indici e plugin che trasformano un sito editoriale in un esperimento di autolesionismo sistemistico.
Ma questa non è una condanna di WordPress. È una condanna dell’uso incompetente di WordPress. Un coltello può tagliare il pane o ferire qualcuno: non è il coltello a decidere.
La competenza di chi progetta, sviluppa e gestisce WordPress sta anche nel saper dire di no. No al plugin “Post Views Counter” che aggiorna il database a ogni visita su un sito da milioni di pageview. No al page builder caricato su template dove non serve. No al plugin SEO duplicato con un altro plugin SEO. No a cinque plugin per inserire script nel footer. No a plugin abbandonati. No a moduli che generano query non indicizzate su tabelle enormi. No a sistemi di statistiche interni quando esistono strumenti esterni più adatti. No a temi commerciali pieni di funzioni inutili attivate tutte insieme.
WordPress performa bene quando viene trattato come software serio. Tema leggero, plugin selezionati, query profilate, object cache persistente, full page cache, CDN, database configurato correttamente, PHP-FPM dimensionato, OPcache attivo, immagini ottimizzate, log monitorati, cron gestito da sistema e non affidato al traffico casuale, separazione tra backend e frontend quando serve.
Node.js non è una bacchetta magica: il caso Ghost insegna
Spesso si cita Ghost come esempio di CMS moderno, costruito su Node.js e pensato per pubblicazione professionale, newsletter e membership. Ghost si presenta ufficialmente come piattaforma per editori professionali e, nelle installazioni di produzione supportate, indica MySQL 8 come database supportato insieme a Node.js LTS, nginx e Ubuntu.
Ghost è un buon prodotto, con una sua filosofia chiara, e in alcuni casi può essere una scelta sensata. Ma l’esperienza pratica insegna che “Node.js” sulla brochure non significa automaticamente “più veloce di WordPress” in ogni scenario reale.
In un caso concreto, su un progetto con oltre 800 mila post legati al significato dei nomi, abbiamo riscontrato che la combinazione WordPress, MariaDB e Varnish/Vinyl Cache risultava più efficace, più gestibile e più performante rispetto a Ghost con Node.js e MySQL. Non perché Ghost sia scritto male, ma perché il punto non era il linguaggio. Il punto era il modello dei dati, le query, il caching, il volume, le abitudini editoriali, gli strumenti disponibili, la facilità di intervento e il comportamento dell’intero stack.
Questo porta a una conclusione molto concreta: non è Node.js in sé a fare la differenza, così come non è PHP in sé a condannare un progetto. La differenza la fa l’architettura complessiva. E, molto spesso, il database resta il collo di bottiglia principale nelle parti non cacheabili: backend, ricerche, filtri, dashboard, statistiche, importazioni, correlazioni, tassonomie, query editoriali, API dinamiche.
Il database resta il collo di bottiglia, anche nel mondo NoSQL
Quando un sito rallenta, la risposta più comoda è cambiare tecnologia. MySQL è lento? Passiamo a MongoDB. PHP è vecchio? Passiamo a Go. WordPress è monolitico? Facciamo microservizi. Il problema è che cambiare tecnologia senza capire il collo di bottiglia significa solo spostare il problema.
Una query lenta resta una query lenta anche se la chiami “aggregation pipeline”. Un indice mancante resta un indice mancante anche in un database documentale. Un modello dati sbagliato resta sbagliato anche se è memorizzato in BSON. Una pagina non cacheabile che fa cinquanta chiamate a servizi esterni resta lenta anche se il backend è scritto in Rust, Go o Node.js.
Il lavoro serio è meno glamour: slow query log, EXPLAIN, profiling, cardinalità, indici composti, normalizzazione dove serve, denormalizzazione dove conviene, tabelle aggregate, cache applicativa, invalidazione corretta, riduzione delle query, eliminazione di join inutili, separazione dei workload, replica per letture selettive, code per operazioni asincrone, job schedulati, monitoraggio continuo.
In questo contesto l’intelligenza artificiale può diventare utilissima. Un buon modello LLM può aiutare a leggere un piano di esecuzione, suggerire indici, individuare pattern di query inefficiente, spiegare perché un join esplode, proporre una tabella di appoggio, generare script di migrazione, scrivere test, confrontare piani prima e dopo una modifica. Ma anche qui vale la stessa regola: l’AI accelera il tecnico competente, non sostituisce la competenza.
Il grande equivoco: ignorare cache e CDN perché il linguaggio è veloce
Uno degli errori più gravi dei nuovi CMS “veloci” è pensare che, usando un linguaggio performante, si possa ignorare la cache. È un errore concettuale.
Un sito editoriale ad alto traffico non deve reggere il traffico generando dinamicamente ogni pagina a ogni richiesta. Deve reggerlo servendo la maggior quantità possibile di contenuto da cache. Questo vale per WordPress, per Drupal, per Ghost, per un CMS in Go, per un backend custom in Node.js e per qualunque piattaforma editoriale seria.
Le fondamenta sono sempre simili:
- cache HTTP davanti all’origin, con Varnish/Vinyl Cache, NGINX caching o soluzioni equivalenti;
- CDN per distribuire asset statici, immagini, pagine cacheabili e traffico geografico;
- object cache con Redis o Memcached per ridurre il carico sul database;
- database tuning con indici, buffer pool adeguato, slow query log e replica quando necessario;
- frontend leggero, perché spesso la lentezza percepita è causata da JavaScript, advertising, tracking e immagini non ottimizzate;
- invalidazione selettiva, per non svuotare tutta la cache a ogni aggiornamento editoriale.
Se questi elementi mancano, anche il CMS più moderno rischia di crollare. Se questi elementi sono presenti, WordPress può gestire traffico enorme con costi ragionevoli e con una semplicità operativa che molte soluzioni custom non riescono a eguagliare.
Che cosa si perde quando si passa a un CMS custom
La parte meno raccontata della migrazione verso un CMS proprietario o custom è ciò che si perde.
Si perde, innanzitutto, l’ecosistema dei plugin. Non solo i plugin “banali”, ma tutto quel patrimonio di soluzioni già pronte per casi reali: gestione SEO, redirect, sitemap, feed, schema markup, multilingua, newsletter, moduli, integrazioni CRM, editor visuali, gestione ruoli, editorial workflow, import/export, media handling, ottimizzazione immagini, sicurezza, backup, cache, e-commerce, membership, paywall, advertising, analytics.
Si perde l’ecosistema dei temi. Un tema commerciale da 50 o 60 dollari, magari acquistato su un marketplace, non è la soluzione ideale per ogni progetto, ma per molte PMI o piccoli editori rappresenta la differenza tra andare online in due settimane e spendere mesi in design, frontend, componenti, template, responsive, test e rifiniture.
Si perde la disponibilità di figure professionali. Trovare uno sviluppatore WordPress, un sistemista che conosce WordPress, un consulente SEO che sa come funziona WordPress, un designer che ha già lavorato con WordPress, è relativamente facile. Trovare qualcuno che conosca un CMS custom sviluppato da una piccola software house o da un team interno è un altro discorso.
Si perde anche la libertà di uscita. WordPress è open source, documentato, diffuso, ispezionabile. Un CMS SaaS o PaaS custom può essere comodo finché il rapporto funziona. Ma cosa succede quando aumentano i costi? Quando il fornitore cambia priorità? Quando serve una funzionalità non prevista? Quando il supporto peggiora? Quando l’azienda viene acquisita? Quando si vuole tornare a WordPress, Drupal o un altro sistema open source?
È qui che vale una regola molto semplice: i matrimoni sono facili, divertenti e pieni di sorrisi; sono i divorzi che fanno piangere. Entrare in una piattaforma proprietaria è spesso semplice. Uscirne può significare esportare milioni di contenuti, riscrivere URL, preservare redirect, migrare media, ricostruire tassonomie, salvare metadata SEO, mantenere canonical, convertire embed, rigenerare sitemap, riconciliare utenti, commenti, permessi e storico editoriale.
WordPress è general purpose, ed è proprio questa la sua forza
Molti criticano WordPress perché non è verticale. Non è nato come CMS esclusivo per grandi redazioni. Non è nato come e-commerce. Non è nato come LMS. Non è nato come social network. Non è nato come marketplace. Non è nato come piattaforma headless enterprise.
Ed è vero. Ma proprio questa è una delle ragioni della sua forza. WordPress è un CMS general purpose, estremamente estendibile, che nel tempo è stato portato a fare cose molto diverse: blog personali, magazine, siti corporate, portali, community, e-commerce con WooCommerce, piattaforme di e-learning, membership, siti istituzionali, landing page, documentazione, intranet leggere e molto altro.
Questa flessibilità non è banale. Gli hook, i filtri, gli shortcode, i custom post type, le tassonomie, i template, la REST API, l’editor a blocchi e l’enorme compatibilità retroattiva sono il risultato di anni di stratificazione. Possiamo criticare alcune scelte, possiamo trovare parti del Core meno eleganti rispetto ai canoni moderni, possiamo preferire altri pattern architetturali. Ma non possiamo liquidare WordPress come “spaghetti code” senza riconoscere la complessità ingegneristica di un software che deve continuare a funzionare su milioni di siti, con migliaia di combinazioni diverse di temi, plugin, hosting, versioni PHP, database e workflow.
Un grado di astrazione e compatibilità simile è difficile da progettare anche per sviluppatori senior con vent’anni di esperienza. Pensare che possa essere replicato in pochi mesi da “vibe coders” guidati da Claude Code, Cursor o strumenti simili è ingenuo. Si può creare un prototipo convincente. Si può creare un MVP interessante. Si può creare un CMS verticale per un caso specifico. Ma ricreare WordPress come ecosistema è un’altra cosa.
Quando WordPress non basta: le alternative enterprise esistono già
Questo non significa che WordPress sia sempre la scelta giusta. Esistono casi in cui una grande media company, una redazione multinazionale, un gruppo editoriale con forti esigenze print-digital, sistemi di advertising complessi, paywall avanzati, integrazioni legacy, workflow legali e redazionali estremamente strutturati può aver bisogno di soluzioni verticali enterprise.
Il punto è che quel mercato non è vuoto. Non c’è un buco enorme che aspetta il CMS generato dall’AI da una piccola software house improvvisata. Esistono già piattaforme come Eidosmedia, Arc XP, Brightspot, Stibo DX / CUE, Atex, Naviga, Ring Publishing, WoodWing e altre soluzioni pensate specificamente per l’editoria professionale.
Eidosmedia dichiara clienti come Financial Times, The Wall Street Journal, The Times, The Boston Globe e Le Figaro. Brightspot cita Los Angeles Times, U.S. News & World Report e POLITICO tra i clienti media. Atex è indicata da Google News Initiative come soluzione usata da testate come la Repubblica, El País, Daily Mail, Metro e Sydney Morning Herald. Naviga si presenta come piattaforma end-to-end per editori e media company, con clienti e casi legati a DallasNews, Newsquest e Bonnier. Stibo DX / CUE è stata scelta da Mediahuis come piattaforma centrale per siti e app news. Ring Publishing si posiziona come content experience platform modulare e cloud-native per creazione, distribuzione e automazione editoriale.
In altre parole: se un editore vuole davvero andare oltre WordPress per esigenze enterprise, il mercato propone già alternative mature, costose, verticali e strutturate. Il nuovo CMS custom “più veloce di WordPress” deve quindi competere su due fronti: contro WordPress, che è open source, economico, diffuso e flessibile; e contro soluzioni enterprise già riconosciute dal mercato editoriale.
Il vero problema non è WordPress: sono gli sviluppatori improvvisati e i falsi sistemisti
Arriviamo al punto più scomodo. Molte installazioni WordPress sono lente, instabili e fragili non perché WordPress sia inadeguato, ma perché sono state progettate, sviluppate o gestite male.
Temi pieni di funzioni inutili. Plugin installati senza criterio. Hosting sottodimensionati. Nessuna cache HTTP. Nessuna CDN. Database mai ottimizzato. Tabelle autoload enormi. Cron lasciato al traffico. Query lente ignorate. Backup non testati. Ambienti staging assenti. Aggiornamenti fatti in produzione senza controllo. Immagini caricate da 8 MB. JavaScript pubblicitario ingestibile. Plugin nulled. Sicurezza delegata al caso. E poi, quando tutto crolla, la colpa sarebbe di WordPress.
Noi, nel mondo dei CMS, ci siamo passati da PHP-Nuke, Mambo, Joomla, Drupal, WordPress, Typo3 e anche Ghost. Abbiamo visto portali reggere traffico importante con stack apparentemente “vecchi” e abbiamo visto progetti modernissimi collassare perché nessuno aveva pensato alla cache, al database, alla CDN, agli indici, ai job asincroni, ai log e alla manutenzione.
La verità è che la tecnologia non salva un progetto gestito male. Un CMS in Go scritto male può essere peggiore di un WordPress configurato bene. Un backend Node.js senza cache può costare più di un WordPress servito da Varnish/Vinyl Cache. MongoDB senza modellazione corretta può diventare un incubo. Redis usato come stampella per nascondere query sbagliate può solo rimandare il problema.
WordPress è lento, brutto e obsoleto?
WordPress può essere lento. Può essere brutto. Può essere obsoleto. Ma non per definizione.
È lento quando viene usato senza cache, con plugin pesanti, temi sovraccarichi, database non ottimizzato e hosting inadatto. È brutto quando viene lasciato con template scadenti, UX improvvisata e frontend costruito senza criterio. È obsoleto quando viene trattato come un blog del 2008 invece che come una piattaforma editoriale moderna, estendibile, cacheabile e integrabile.
Ma un WordPress progettato correttamente può essere veloce, stabile, sicuro, scalabile e perfettamente adatto a blog, magazine, portali editoriali e testate giornalistiche. Può essere usato in modalità classica, headless, ibrida, con CDN, con Varnish/Vinyl Cache, con Redis, con MariaDB o MySQL ottimizzati, con frontend custom e workflow editoriali avanzati.
Il punto non è difendere WordPress per partito preso. Il punto è evitare l’errore opposto: attaccarlo per moda, per snobismo tecnologico o per vendere una soluzione custom che, nella maggior parte dei casi, sarà meno completa, meno estendibile, meno supportata e più rischiosa.
Conclusione: reinventare WordPress ha senso solo se si sa davvero cosa si sta facendo
Nessuno vieta a una software house, a un team di sviluppatori o a una startup di creare un nuovo CMS. Nessuno vieta di provare a costruire una soluzione migliore, più verticale, più moderna, più adatta a un certo tipo di redazione. L’innovazione nasce anche da tentativi coraggiosi.
Ma bisogna essere onesti. Nella maggior parte dei casi, rifare WordPress “perché WordPress è lento” significa partire da una diagnosi sbagliata. Se il problema è la mancanza di cache, la soluzione non è MongoDB. Se il problema è un plugin che fa query pessime, la soluzione non è Go. Se il problema è un tema da 20 MB di asset, la soluzione non è Node.js. Se il problema è l’assenza di competenza sistemistica, la soluzione non è un CMS custom: è competenza sistemistica.
WordPress rimane, oggi, una delle migliori soluzioni possibili per blogging, editoria online, magazine, siti informativi e molti progetti content-driven. Non perché sia perfetto, ma perché combina maturità, ecosistema, libertà, estendibilità, costi sostenibili, competenze disponibili e scalabilità reale quando viene gestito bene.
Se una testata ha esigenze talmente complesse da superare WordPress, allora probabilmente deve valutare piattaforme enterprise già presenti sul mercato, con budget, contratti, SLA, migrazioni e lock-in ben compresi. Se invece il problema è che WordPress “crasha con poche centinaia di visite online”, molto spesso non serve un nuovo CMS: serve qualcuno che sappia davvero configurare WordPress, il database, PHP-FPM, Varnish/Vinyl Cache, Redis, CDN, plugin, tema e infrastruttura.
La realtà è meno affascinante dello slogan, ma molto più utile: non è WordPress a non essere all’altezza dell’editoria moderna. Spesso non sono all’altezza coloro che lo installano, lo sviluppano o lo amministrano senza conoscerlo davvero.
