Guide

Dal sito tagliato in Photoshop all’AI: oltre 30 anni di sviluppo web

Ho iniziato nel 1995, quando una pagina nasceva come immagine, si tagliava in pezzi e si rimontava in HTML. Gli strumenti sono cambiati radicalmente; il dovere di costruire un sito utile, veloce, sicuro e comprensibile no.

La risposta breve

Builder, CMS e AI hanno abbassato la soglia per pubblicare, non quella necessaria per progettare bene. Un sito su misura non è migliore perché scritto a mano: lo diventa quando il controllo sul codice serve a eliminare dipendenze inutili, rispettare requisiti reali e verificare ogni scelta. È questo, non la nostalgia, il cuore del metodo GLP.

Gian Luca Partengo
Sviluppatore web dal 1995 · siti su misura · Aggiornato: 29 luglio 2026

Non è una storia di strumenti: è una storia di responsabilità

Il Web è diventato più facile da pubblicare e molto più difficile da governare. Ogni generazione ha risolto un limite e introdotto nuove dipendenze.

Esperienza diretta

Dal 1995 ho visto cambiare quasi tutto

Ho lavorato con pagine statiche, layout a tabelle, immagini ritagliate, script, animazioni Flash, PHP, database, CMS, e-commerce, builder, framework e strumenti AI. Ogni passaggio sembrava rendere obsoleto quello precedente.

Eppure il risultato continua a dipendere dalle stesse domande: a chi serve il sito, cosa deve far capire, quanto deve durare, chi controlla i dati, come viene mantenuto e come si verifica che funzioni.

01Prima capire il problema
02Poi scegliere l’architettura
03Ridurre ciò che non serve
04Misurare il risultato reale

La tecnologia è una conseguenza delle decisioni di progetto, non il punto di partenza.

1995: il sito nasceva come immagine e diventava una tabella

Schermi piccoli, connessioni lente, browser incompatibili e CSS ancora immaturo: il controllo visivo si otteneva pagando un prezzo alto in peso, rigidità e manutenzione.

Il layout in Photoshop

Si disegnava l’intera pagina come una composizione grafica. Il layout veniva poi ritagliato manualmente in immagini; in seguito gli strumenti Slice e Save for Web formalizzarono quel flusso.

Le tabelle come griglia

Le celle HTML tenevano insieme logo, menu, fondi, pulsanti e spaziatori trasparenti. Funzionava visivamente, ma mescolava contenuto e presentazione in un markup fragile.

Ogni kilobyte contava

Con il modem, un’immagine non ottimizzata significava attesa evidente. Palette, compressione, dimensioni e numero di richieste non erano dettagli: determinavano se la pagina arrivava davvero.

La compatibilità si costruiva a mano

Netscape e Internet Explorer interpretavano parti del Web in modo diverso. Testare più browser e risolvere eccezioni era parte integrante dello sviluppo.

JavaScript: la pagina smette di essere soltanto una pagina

Nato in Netscape nel 1995 e avviato alla standardizzazione ECMA nel 1996, JavaScript portò logica e reazione dentro il browser.

Rollover e menu

Le prime interazioni visibili cambiavano immagini al passaggio del mouse, aprivano menu o controllavano piccoli comportamenti dell’interfaccia.

Validazione nel browser

I moduli potevano segnalare errori prima dell’invio, migliorando la risposta percepita. La verifica lato server restava comunque indispensabile.

Applicazioni sempre più ricche

Da semplici effetti si è arrivati a interfacce complesse, aggiornamenti asincroni e applicazioni che eseguono una parte sostanziale della logica sul client.

Nuovo potere, nuovo debito

Ogni script aggiunge capacità, ma anche peso, superficie di errore, dipendenze, rischi di sicurezza e possibili ostacoli a scansione e accessibilità.

La lezione ancora valida

JavaScript va usato per ciò che richiede davvero comportamento, non per ricreare in modo più fragile ciò che HTML e CSS sanno già fare.

CSS: contenuto e presentazione iniziano a separarsi

Il lavoro su CSS iniziò nel 1994 e CSS1 divenne una raccomandazione W3C nel 1996. Da lì il layout poté uscire gradualmente dalle tabelle.

Cambio strutturale

La grafica non doveva più vivere dentro il contenuto

HTML poteva descrivere titoli, paragrafi, elenchi, link e tabelle di dati; CSS poteva occuparsi di colori, spazi, allineamenti, tipografia e disposizione visiva.

La separazione rese possibili manutenzione più coerente, riuso delle regole, media differenti e, nel tempo, layout flessibili senza trasformare ogni pagina in un mosaico.

Markup più significativo

La struttura torna a raccontare il contenuto. È una base decisiva per motori di ricerca, tecnologie assistive e sistemi AI.

Design riutilizzabile

Una regola può governare molte pagine e componenti, riducendo incoerenze e modifiche ripetitive.

Adattamento ai media

Lo stesso documento può presentarsi in modo diverso su schermo, stampa e dispositivi con caratteristiche differenti.

Meno immagini decorative

Gradienti, bordi, ombre, layout e animazioni native hanno progressivamente sostituito molti asset raster prima indispensabili.

Flash: libertà visiva straordinaria, contenuto dentro un recinto

Tra la fine degli anni Novanta e i Duemila, Flash permise esperienze difficili da ottenere con il Web aperto dell’epoca. Il prezzo era dipendere da un plugin e da un formato proprietario.

Ambito	Cosa permetteva	Cosa rendeva fragile
Direzione artistica	Controllo molto preciso di grafica, suono, tipografia e sequenze.	Contenuti meno nativi, più difficili da adattare e dipendenti dal runtime.
Animazione e interazione	Esperienze ricche quando HTML, CSS e JavaScript offrivano molto meno.	Prestazioni, accessibilità e usabilità spesso subordinate all’effetto.
Distribuzione	Un ambiente coerente fra browser che interpretavano il Web in modo diverso.	Indicizzazione e accesso al contenuto dipendevano da tecniche e supporti specifici.
Durata	Un ecosistema enorme di strumenti, professionisti e contenuti interattivi.	Quando il plugin è terminato, la compatibilità è terminata con lui.

PHP e database: il sito diventa un sistema

PHP nacque nel 1994 e il codice fu rilasciato nel 1995. La pagina poteva essere generata sul server in base a dati, utenti e operazioni.

01
Moduli che fanno qualcosa
Una richiesta poteva essere validata, inviata, salvata e trasformata in un processo reale, non limitarsi a un collegamento email.
02
Contenuti da database
News, cataloghi, schede e archivi potevano essere aggiornati senza duplicare manualmente intere pagine HTML.
03
Aree riservate
Sessioni, autenticazione e permessi aprirono la strada a servizi personali, intranet e applicazioni gestionali.
04
E-commerce
Prodotti, carrelli, ordini e pagamenti trasformarono il sito in un’infrastruttura commerciale collegata a processi aziendali.
05
Template e componenti
Header, footer e funzioni condivise ridussero duplicazione e incoerenza, anticipando modelli più strutturati.
06
Responsabilità sul server
Con la dinamicità arrivarono gestione degli input, sicurezza, aggiornamenti, backup, logging e controllo dei dati.

CMS: pubblicare diventa accessibile a chi non scrive codice

WordPress, Joomla, Magento e altri sistemi hanno reso temi, plugin, cataloghi e redazioni disponibili a moltissime organizzazioni. È stata una democratizzazione reale.

WordPress

Nato nel 2003, ha reso semplice gestire contenuti e ampliare il sito con temi e plugin. La flessibilità dell’ecosistema è anche la fonte della sua variabilità tecnica.

Joomla

Dal 2005 ha offerto un CMS open source strutturato per portali, contenuti e permessi, con una comunità e un modello estendibile.

Magento

Ha portato nel Web open source un e-commerce ricco e altamente configurabile; oggi la sua evoluzione enterprise prosegue come Adobe Commerce.

Temi e plugin

Accelerano funzioni comuni, ma ogni estensione porta codice, aggiornamenti, compatibilità, qualità e responsabilità che il proprietario del sito deve governare.

Il CMS non è il progetto

È un’infrastruttura. Può essere la scelta giusta quando l’autonomia editoriale e l’ecosistema compensano manutenzione e complessità; diventa un problema quando viene usato per evitare analisi, architettura e competenza.

Wix, no-code e piattaforme: esserci diventa quasi istantaneo

Wix nasce nel 2006, passa da Flash a HTML5 e poi integra sviluppo visuale e AI. La promessa è corretta: molte persone possono pubblicare senza costruire l’infrastruttura.

Il vero scambio

Meno complessità iniziale, meno controllo finale

Hosting, editor, componenti, aggiornamenti e distribuzione vengono riuniti in un servizio. Per landing temporanee, prototipi, iniziative molto piccole o bisogni standard può essere una soluzione proporzionata.

Il limite emerge quando il progetto richiede comportamento specifico, portabilità, controllo fine del markup, prestazioni, integrazioni, governance dei dati o una vita più lunga delle decisioni della piattaforma.

Velocità di avvio

Template e componenti pronti riducono il tempo necessario per mettere online una prima versione.

Costi prevedibili all’inizio

L’abbonamento sembra semplice da valutare, ma funzioni, crescita, applicazioni e migrazione vanno considerate sull’intero ciclo di vita.

Confini della piattaforma

Ciò che non rientra nei componenti previsti può richiedere compromessi, codice aggiuntivo o non essere realizzabile come progettato.

Portabilità limitata

Contenuti e dominio possono essere recuperabili, ma il sito come sistema e come design raramente si trasferisce altrove senza essere ricostruito.

Per costi, proprietà, SEO e criteri pratici leggi anche Wix, fai da te o sito professionale?.

Mobile e responsive design: non esiste più una pagina di dimensione fissa

Nel 2010 Ethan Marcotte diede un nome a un approccio basato su griglie fluide, immagini flessibili e media query. Il sito doveva adattarsi al contesto, non imporre il proprio canvas.

01Contenuto prioritario
02Layout fluido
03Interazioni adatte al dispositivo
04Prestazioni sulla rete reale

Responsive non significa “ridurre il desktop”: significa progettare gerarchie e comportamenti che restano utili in condizioni diverse.

Framework, API, headless e cloud: più potenza, più livelli da governare

Il Web moderno può distribuire interfaccia, contenuti, dati, autenticazione e funzioni su sistemi differenti. È straordinario quando il problema lo richiede; è debito inutile quando serve solo a seguire una moda.

Componenti e design system

Riuso e coerenza aumentano quando i componenti hanno contratti chiari, varianti controllate e responsabilità definite.

Rendering nel client o nel server

Ogni scelta cambia tempi di caricamento, indicizzazione, resilienza e complessità. Non esiste un modello corretto per tutti i siti.

API e servizi

Separare sistemi facilita integrazioni e scalabilità, ma moltiplica punti di guasto, dipendenze e monitoraggio.

Toolchain e manutenzione

Build, pacchetti, versioni e vulnerabilità possono superare la complessità del contenuto che dovrebbero servire.

Architettura proporzionata

La maturità non si misura dal numero di tecnologie, ma dalla capacità di giustificare ogni livello e rimuovere ciò che non produce valore.

AI: produrre codice è più veloce, verificare il prodotto è più importante

Oggi modelli e agenti possono proporre layout, scrivere componenti, tradurre contenuti, creare test e collegare strumenti. Il costo della prima bozza scende; la responsabilità della decisione resta.

Nuova accelerazione

L’AI moltiplica capacità e difetti

Con un obiettivo, un contesto e controlli solidi accelera ricerca, prototipazione, implementazione e verifica. Senza questi elementi produce rapidamente codice plausibile, incoerente o superfluo.

Un output che “sembra un sito” non dimostra correttezza di routing, sicurezza, accessibilità, SEO, privacy, prestazioni, dati strutturati, integrazioni o manutenzione.

Generazione

Bozze, varianti e attività ripetitive richiedono meno tempo, liberando risorse per analisi e controllo.

Contesto

Regole di progetto, fonti canoniche e architettura determinano se l’AI produce qualcosa di coerente o una nuova eccezione.

Verifica

Lint, test, browser reali, audit e revisione umana trasformano una proposta probabilistica in un rilascio affidabile.

Responsabilità

Chi pubblica risponde del risultato. L’AI è uno strumento operativo, non un soggetto a cui delegare qualità, legge o decisioni aziendali.

Il paradosso: strumenti migliori, siti spesso peggiori

Non è mai stato così facile mettere online qualcosa. Proprio per questo è facile confondere la presenza con un prodotto digitale capace di lavorare.

Codice in eccesso

Temi, librerie e componenti generici caricano funzioni che la pagina non usa e che qualcuno dovrà comunque aggiornare.

Prestazioni delegate

Ottimizzazioni automatiche cercano di compensare un’architettura pesante invece di rimuovere la causa del peso.

SEO cosmetica

Un plugin compila campi, ma non crea struttura informativa, intento, esperienza, autorevolezza o contenuti originali.

Sicurezza per accumulo

Aggiungere estensioni di protezione non elimina dipendenze obsolete, configurazioni errate o processi di aggiornamento assenti.

Accessibilità come widget

Un pannello di preferenze può aiutare alcune persone, ma non corregge markup, tastiera, focus, alternative testuali e processi.

Design senza obiettivo

Effetti, animazioni e sezioni riempiono lo spazio anche quando rallentano la comprensione e allontanano la conversione.

La presenza online non è il risultato

Il risultato è un sito che viene trovato, capito, usato, mantenuto e collegato ai processi dell’azienda. Tutto il resto è materiale, non valore.

Perché il codice su misura conta ancora

Non perché sia artigianale in senso romantico, ma perché rende possibile decidere esattamente cosa entra nel prodotto, come funziona e come viene verificato.

01

Prestazioni

Asset, richieste, font, script e rendering vengono dimensionati sul contenuto reale invece di ereditare un tema generalista.

02

Sicurezza

Una superficie più piccola e dipendenze selezionate riducono i punti da aggiornare, monitorare e difendere.

03

SEO e GEO

HTML semantico, URL, metadati, dati strutturati e contenuto server-side possono seguire il modello informativo del progetto.

04

Accessibilità

Tastiera, focus, nomi accessibili, contrasto e riduzione del movimento si progettano nei componenti, non si applicano come vernice finale.

05

Proprietà e portabilità

Codice, contenuti e dati non dipendono dall’editor visuale o dal piano commerciale di una singola piattaforma.

06

Evoluzione

Nuove funzioni entrano nell’architettura esistente secondo regole comuni, senza trasformare ogni esigenza in un plugin isolato.

Approfondisci prestazioni, sicurezza e la preparazione del sito per agenti AI.

Builder, CMS o sito su misura: la scelta corretta dipende dal costo dell’errore

Budget e velocità contano, ma vanno confrontati con durata, differenziazione, integrazioni, rischio e valore del canale digitale.

Approccio	Quando ha senso	Limite principale	Controllo
Builder / no-code	Prototipo, iniziativa breve, bisogno standard e budget iniziale minimo.	Confini della piattaforma, portabilità e crescita.	Basso–medio
CMS	Redazione autonoma, ecosistema di funzioni e processi editoriali articolati.	Manutenzione, estensioni, qualità variabile e superficie tecnica.	Medio–alto
Sito su misura	Brand, prestazioni, sicurezza, SEO/GEO, integrazioni e durata sono strategici.	Richiede analisi, competenza e investimento iniziale reale.	Massimo

Nessuna tecnologia salva un progetto sbagliato

Una soluzione semplice può essere perfetta per un obiettivo semplice. Quando il sito deve generare fiducia, contatti o vendite nel tempo, il risparmio iniziale va confrontato con limiti, rilavorazioni e opportunità perse.

Il metodo GLP oggi: oltre trent’anni di evoluzione, senza accumularne il peso

Uso strumenti moderni, compresa l’AI, dentro un CORE proprietario e un processo verificabile. Il codice a mano è il mezzo per ottenere controllo; il metodo decide come usarlo.

01
Obiettivi e perimetro
Prima di scrivere codice definisco pubblico, azioni, contenuti, requisiti, vincoli, lingue, integrazioni e responsabilità.
02
Architettura semantica
URL, navigazione, heading, entità, link interni e dati strutturati vengono progettati come un sistema leggibile da persone, motori e AI.
03
Codice essenziale
Ogni dipendenza deve giustificare il proprio costo. HTML server-side, CSS e JavaScript restano proporzionati alle funzioni effettive.
04
Accessibilità di base
Struttura semantica, tastiera, focus, moduli etichettati, riduzione delle animazioni e preferenze di accessibilità sono previste nel CORE.
05
Sicurezza e privacy
Input, header, permessi, dipendenze, tracciamento e terze parti vengono ridotti e configurati sul perimetro reale.
06
SEO e GEO tecniche
Canonical, hreflang quando serve, sitemap, metadati, schema e contenuti indicizzabili vengono integrati nella struttura, non aggiunti alla fine.
07
Test e qualità
Lint, test mirati, controlli di routing, responsive e browser reali precedono il rilascio. Il controllo live Lighthouse ha obiettivo 100 e soglia interna minima 98 per categoria.
08
Evoluzione governata
Git, deploy selettivo, cache, monitoraggio e manutenzione rendono ogni modifica tracciabile, limitata e verificabile.

Scopri i servizi e i pacchetti disponibili oppure guarda i progetti realizzati.

Fonti primarie e documentazione verificata

La cronologia unisce la mia esperienza professionale a fonti W3C, Adobe e documentazioni ufficiali. Le date descrivono passaggi tecnici, non confini netti: le ere del Web si sono sovrapposte.

W3C — La storia del World Wide Web
Invenzione del Web, primo browser e server, nascita del W3C e principali passaggi della piattaforma aperta.

Apri la fonte
W3C Wiki — The history of the Web
CERN, Mosaic, Netscape, Internet Explorer, browser wars e movimento per gli standard.

Apri la fonte
Adobe — Slicing web pages
Il flusso documentato per dividere una grafica in immagini e ricomporla tramite HTML e CSS.

Apri la fonte
MDN — Basi delle tabelle HTML
Perché le tabelle furono usate storicamente per il layout e perché creano problemi di accessibilità, manutenzione e adattamento.

Apri la fonte
W3C — Storia dei CSS
Dalle prime proposte del 1994 alla raccomandazione CSS1 del dicembre 1996.

Apri la fonte
MDN — JavaScript
Origine in Netscape nel 1995 e avvio del processo di standardizzazione ECMA nel 1996.

Apri la fonte
PHP — History of PHP
Creazione nel 1994, rilascio del codice nel 1995 ed evoluzione verso applicazioni dinamiche basate su database.

Apri la fonte
Adobe — Fine vita di Flash Player
Termine del supporto il 31 dicembre 2020 e passaggio a standard aperti come HTML5, WebGL e WebAssembly.

Apri la fonte
WordPress — Storia del progetto
Nascita nel 2003 ed evoluzione di temi, plugin, pagine statiche e piattaforma editoriale.

Apri la fonte
Joomla — Venti anni di progetto
Origini nel 2005 e sviluppo della comunità open source e dell’ecosistema CMS.

Apri la fonte
Wix — La storia dell’azienda
Dalla nascita nel 2006 all’editor Flash, HTML5, ADI, sviluppo visuale e Wix Studio.

Apri la fonte
A List Apart — Responsive Web Design
L’articolo di Ethan Marcotte del 2010 che definì griglie fluide, immagini flessibili e media query come approccio unitario.

Apri la fonte

Fonti controllate il 29 luglio 2026. Prodotti, versioni e documentazioni continuano a evolvere; la guida distingue i fatti documentati dalla mia esperienza professionale iniziata nel 1995.

Domande frequenti

Risposte dirette per distinguere tecnica, metodo e marketing quando si valuta come costruire un sito.

Un sito scritto a mano è sempre migliore?

No. Codice confuso scritto a mano può essere peggiore di un buon CMS. Il vantaggio nasce quando il su misura è guidato da architettura, standard, test e manutenzione e usa il controllo per ridurre compromessi.

Perché negli anni Novanta si usavano le tabelle per il layout?

Perché i browser offrivano poche capacità di layout coerenti e CSS era appena nato. Le tabelle permettevano di bloccare immagini e spazi, ma mescolavano struttura e presentazione.

Flash era davvero tutto negativo?

No. Ha reso possibili esperienze avanzate e ha formato una generazione di designer e sviluppatori. Il suo limite strategico era racchiudere contenuti e interazioni in un runtime proprietario.

WordPress è una cattiva scelta?

Non in assoluto. Può essere adatto a processi editoriali ed ecosistemi che ne sfruttano davvero i vantaggi. È sproporzionato quando si ereditano temi, plugin e manutenzione per realizzare poche pagine specifiche.

Wix va bene per un’attività professionale?

Può bastare per obiettivi semplici e standard. Va valutato con cautela quando differenziazione, portabilità, prestazioni, integrazioni e controllo del ciclo di vita sono importanti.

L’AI sostituirà chi sviluppa siti?

Riduce il tempo di molte attività operative e cambia il mestiere. Non elimina però analisi, responsabilità, verifica, sicurezza, accessibilità, strategia dei contenuti e governo dell’architettura.

Un sito moderno deve usare un framework JavaScript?

No. Deve usarlo se interazioni, stato e scala lo giustificano. Per molti siti informativi, HTML server-side e JavaScript mirato sono più semplici, veloci e resilienti.

Cosa significa davvero “sito su misura”?

Significa che architettura, componenti, contenuti e integrazioni sono progettati sul perimetro reale. Non significa riscrivere inutilmente standard, crittografia o librerie mature.

Perché meno dipendenze migliorano la sicurezza?

Ogni dipendenza aggiunge codice, aggiornamenti e possibili vulnerabilità. Ridurle non rende invulnerabili, ma restringe la superficie da conoscere e mantenere.

Un CMS è più facile da aggiornare per il cliente?

Spesso sì per i contenuti, se l’interfaccia e i ruoli sono progettati bene. Va distinto l’aggiornamento editoriale dalla manutenzione tecnica di core, temi, plugin, backup e compatibilità.

Come si misura la qualità di un sito?

Con obiettivi e verifiche: accessibilità, prestazioni, stabilità, sicurezza, indicizzazione, dati strutturati, percorsi utente, conversioni e facilità di manutenzione. Un punteggio solo non basta.

Perché il metodo GLP parte dal codice essenziale?

Perché ciò che non entra nel progetto non rallenta, non si rompe, non richiede aggiornamenti e non amplia la superficie di rischio. Le funzioni si aggiungono quando hanno un’utilità verificabile.