Siti web statici e dinamici: differenze, esempi e come scegliere

La differenza principale tra siti web statici e dinamici riguarda quando e dove viene generato il loro contenuto. Le pagine statiche vengono preparate prima che un visitatore le richieda. Le pagine dinamiche generano o recuperano i contenuti al momento della richiesta, su un server o nel browser del visitatore.

Questa distinzione influisce sulla pubblicazione, sull’hosting, sulla memorizzazione nella cache e sull’accesso alle informazioni in tempo reale. Non indica se un sito web può contenere animazioni, accettare l’invio di moduli o offrire un’esperienza di acquisto. Queste funzionalità dipendono dal codice e dai servizi collegati alle pagine.

Per chi crea o migra un sito web, la domanda utile è quale approccio sia più adatto alle funzioni che il sito deve svolgere. Una pagina di destinazione di un prodotto, un calendario di prenotazione in tempo reale e un pannello di controllo clienti hanno esigenze diverse, anche se appartengono alla stessa azienda.

Questa guida mette a confronto i due approcci, spiega in cosa si sovrappongono e illustra come gestiamo le pagine statiche e i siti web basati sui dati in TeleportHQ.

In questa guida#

• Siti web statici e dinamici a confronto
• Che cos'è un sito web statico?
• Che cos'è un sito web dinamico?
• I siti web statici possono avere funzionalità dinamiche?
• Siti statici e dinamici: i compromessi pratici
• SEO, panoramiche AI e visibilità presso gli LLM
• Esempi di website builder, CMS e framework
• Come TeleportHQ gestisce i siti web statici e dinamici
• Quale approccio scegliere?
• Domande frequenti

Siti web statici e dinamici a confronto#

Una pagina statica fornisce un documento già generato. Una pagina dinamica renderizzata sul server assembla un documento quando è necessario. Una pagina può anche caricare dati nel browser dopo aver ricevuto il documento iniziale.

Questi approcci possono coesistere. Per esempio, un negozio online potrebbe generare in anticipo le descrizioni dei prodotti, recuperare le scorte aggiornate tramite un'API e usare un backend per elaborare gli ordini.

Le categorie descrivono le scelte di implementazione. Non distinguono i siti web piccoli da quelli grandi, né i design semplici dalle esperienze sofisticate.

Che cos'è un sito web statico?#

Un sito web statico fornisce pagine già esistenti quando i visitatori le richiedono. Queste pagine contengono HTML per la struttura, CSS per la presentazione e spesso JavaScript per le interazioni.

I file possono essere forniti da un server web o distribuiti tramite una rete di distribuzione dei contenuti, solitamente chiamata CDN. Poiché il documento è già pronto, non è necessario ricostruirlo a partire dai dati del database a ogni visita.

«Statico» non significa che il contenuto debba rimanere invariato per sempre. Puoi aggiornare il sorgente, generare nuovi file e pubblicarli con la frequenza consentita dal tuo flusso di lavoro.

Come vengono create le pagine statiche#

Esistono diversi modi per crearli:

• Scrivere direttamente in HTML. Questo metodo funziona per i progetti piccoli, ma senza modelli diventa ripetitivo.
• Usare un editor visuale. Modificare i contenuti e i layout tramite un’interfaccia, quindi pubblicare il risultato generato.
• Usare un generatore di siti statici. Combinare modelli con Markdown, file strutturati o dati API per generare pagine.
• Collegare un sistema di gestione dei contenuti. Gli editor aggiornano i contenuti nel CMS e un processo di compilazione genera le pagine pubbliche.

A Un generatore di siti statici può creare molte pagine a partire da un unico layout riutilizzabile. Un catalogo di corsi con 300 corsi non richiede necessariamente che qualcuno progetti e gestisca a mano 300 documenti separati.

I contenuti possono provenire da un database. Ciò che rende statiche le pagine risultanti è che il loro HTML viene generato prima della distribuzione, anziché essere assemblato a ogni richiesta dei visitatori.

Vantaggi dei siti web statici#

• Distribuzione semplice: i file preparati possono essere serviti senza eseguire l’applicazione che genera le pagine per ogni richiesta.
• Caching efficace: i file condivisi si prestano bene alla distribuzione tramite CDN.
• Costi operativi potenzialmente inferiori: i contenuti pubblici non richiedono necessariamente un server applicativo sempre attivo.
• Design flessibile: modelli e componenti possono supportare layout diversi in tutto il sito web.
• Meno componenti pubblici in esecuzione: le pagine fornite possono esporre meno logica applicativa lato server.

Limiti da considerare#

Gli aggiornamenti richiedono un processo di pubblicazione che mantenga aggiornati i file generati. Nei siti di grandi dimensioni, ricostruire tutto dopo ogni piccola modifica può diventare scomodo, quindi la strategia di compilazione è importante.

I file statici, da soli, non possono nemmeno elaborare pagamenti in modo sicuro, verificare le autorizzazioni degli account o archiviare dati condivisi dei clienti. Queste operazioni richiedono un backend, che tu lo gestisca direttamente o utilizzi un servizio ospitato.

L’architettura statica è particolarmente adatta ai contenuti pubblici che possono essere preparati in anticipo: pagine di servizi, articoli, documentazione, portfolio e molte descrizioni di prodotti.

Che cos’è un sito web dinamico?#

Un sito web dinamico utilizza una logica eseguita in tempo reale per produrre o recuperare contenuti. Può rispondere alla richiesta di un visitatore, al suo account, ai filtri selezionati o alle informazioni più recenti in un database.

Questo non significa che ogni pagina dinamica sia personalizzata. Un server può generare lo stesso articolo pubblico per migliaia di visitatori. La pagina è comunque generata dinamicamente se l’applicazione la compone al momento della richiesta, anziché fornire un file creato in precedenza.

Come funzionano le pagine dinamiche#

Due approcci comuni sono:

• Rendering lato server: il server esegue la logica dell'applicazione, recupera i dati necessari e restituisce HTML contenente il contenuto della pagina.
• Rendering lato client: JavaScript eseguito nel browser crea o aggiorna l'interfaccia, spesso utilizzando dati recuperati da un'API.

Molte applicazioni combinano i due approcci. Un server può restituire una pagina iniziale completa, dopodiché il codice del browser gestisce i filtri, aggiorna un grafico o carica altri risultati.

Per esempio, la dashboard di uno studente potrebbe verificare chi ha effettuato l'accesso, recuperare i corsi a cui è iscritto e mostrare i suoi progressi. Un altro studente visualizzerà dati diversi attraverso la stessa interfaccia.

Vantaggi dei siti web dinamici#

• Informazioni aggiornate: le pagine possono utilizzare dati aggiornati di recente senza dover attendere la ricostruzione completa del sito.
• Azioni persistenti: i visitatori possono creare account, inviare ordini o salvare preferenze tramite i servizi di backend.
• Esperienze personalizzate: gli utenti autorizzati possono vedere i propri acquisti, messaggi e impostazioni.
• Gestione dei contenuti strutturati: i modelli condivisi mostrano i record provenienti da una fonte centralizzata.
• Flussi di lavoro dell'applicazione: l'invio di un modulo può attivare la convalida, gli aggiornamenti del database e le azioni successive.

Limiti da considerare#

Le funzionalità eseguite durante l'uso introducono delle dipendenze. Una query lenta al database, un'API non disponibile o un server applicativo sovraccarico possono influire sull'esperienza dei visitatori.

Il team deve inoltre gestire le autorizzazioni, l'archiviazione dei dati, gli aggiornamenti software, il monitoraggio e le procedure di ripristino. Una piattaforma gestita può occuparsi di gran parte dell'infrastruttura, ma la logica del sito web deve comunque essere configurata correttamente.

Né la libertà di progettazione limitata né le scarse prestazioni nei risultati di ricerca sono caratteristiche intrinseche dei siti web dinamici. Questi risultati dipendono dalla piattaforma, dall'implementazione e dalle scelte di manutenzione.

I siti web statici possono avere funzionalità dinamiche?#

Sì. Un sito web può fornire HTML statico e offrire comunque funzionalità interattive o basate sui dati. La distinzione importante riguarda ciò che accade nella pagina e ciò che accade nei servizi che la supportano.

È qui che molte spiegazioni sulla differenza tra statico e dinamico diventano confuse. L'apertura di un menu con un clic modifica l'interfaccia, ma non richiede al server di generare un nuovo documento. Un modulo di pagamento può essere visualizzato su una pagina statica, mentre il pagamento viene elaborato da un servizio separato.

Le interazioni nel browser non richiedono la generazione dinamica delle pagine#

JavaScript e CSS possono supportare interazioni come:

• Aprire menu di navigazione e pannelli a fisarmonica.
• Passare da una scheda all'altra.
• Animare gli elementi mentre i visitatori scorrono la pagina.
• Calcolare una stima del prezzo usando i valori già disponibili nella pagina.
• Filtrare un elenco già caricato.
• Memorizzare nel browser una preferenza di visualizzazione locale.

Queste funzionalità possono essere utilizzate con pagine predefinite. Non richiedono necessariamente un database o un server applicativo.

Le funzionalità persistenti richiedono un luogo in cui elaborare e archiviare i dati#

Alcune azioni riguardano informazioni che devono essere disponibili anche al termine della sessione del browser o condivise tra gli utenti. Ecco alcuni esempi:

• Ricezione e archiviazione di una richiesta di contatto.
• Verifica delle credenziali di accesso.
• Conferma di un acquisto.
• Salvataggio di un appuntamento.
• Aggiornamento delle scorte.
• Visualizzazione dello storico degli ordini di un cliente.

Un frontend statico può connettersi a servizi che eseguono queste operazioni. Il frontend continua a essere distribuito in modo statico, mentre il sistema nel suo complesso include funzionalità dinamiche.

L'autenticazione richiede anche più che nascondere un elemento con JavaScript. Un backend deve controllare l'accesso alle informazioni protette. Inviare dati riservati a tutti i browser e nasconderli visivamente non li protegge.

Un sito web ibrido combina diversi approcci di distribuzione#

Consideriamo un'azienda che vende corsi online:

1. Le descrizioni dei corsi possono essere generate in anticipo perché il programma pubblico non cambia per ogni visitatore.
2. I posti disponibili possono essere ricavati dai dati aggiornati sulle iscrizioni.
3. La procedura di pagamento richiede la convalida del backend e l'elaborazione del pagamento.
4. Il dashboard dello studente mostra dati privati dopo l'autenticazione.

Lo stesso sito web contiene contenuti pubblici condivisi, dati operativi aggiornati e funzionalità private dell'applicazione. Non è molto utile costringere ogni parte a seguire un'unica strategia di rendering.

Quando valuti gli strumenti, potresti incontrare i termini SSG, SSR e CSR. SSG significa generazione statica del sito; SSR significa rendering lato server; CSR significa rendering lato client. Descrivono il modo in cui i contenuti vengono visualizzati nella pagina e un singolo progetto può usarne più di uno.

Alcuni sistemi rigenerano anche pagine selezionate dopo la pubblicazione o memorizzano nella cache le risposte generate dinamicamente. Nel valutare queste opzioni, chiediti quanto devono essere aggiornati i contenuti e cosa accade tra un aggiornamento e la richiesta del visitatore successivo.

Statico o dinamico: i compromessi pratici#

Il confronto più efficace parte dalle attività che il tuo sito web deve supportare. La velocità è importante, ma lo sono anche gli aggiornamenti dei contenuti, l'affidabilità, l'aggiornamento dei dati e il tempo che il tuo team dedica alla manutenzione del sito.

Prestazioni e velocità di caricamento#

La distribuzione statica elimina la necessità di generare il documento iniziale per ogni richiesta. Questo può ridurre il carico sul server e rendere più semplice distribuire le pagine pubbliche tramite una CDN.

Tuttavia, una pagina statica può comunque avere prestazioni scadenti se carica immagini troppo pesanti, JavaScript in eccesso, font non necessari o script di terze parti pesanti. L'HTML pre-generato non impedisce che una pagina sia lenta o che l'interfaccia non risponda.

Le pagine dinamiche possono offrire buone prestazioni se le query, il codice dell'applicazione e la memorizzazione nella cache sono progettati in modo adeguato. Le risposte pubbliche condivise possono spesso essere memorizzate nella cache, riducendo le operazioni ripetute.

Confronta l'esperienza effettiva:

• Quanto tempo occorre perché il contenuto principale venga visualizzato su una connessione mobile?
• La pagina rimane reattiva durante le interazioni?
• Il layout si sposta mentre vengono caricati immagini, font o contenuti incorporati?
• Cosa succede quando un'API o un database risponde lentamente?

Misura pagine rappresentative, comprese quelle degli elenchi e dei dettagli. Una homepage veloce non dimostra che l'intero sito abbia buone prestazioni.

Pubblicazione e aggiornamento dei contenuti#

I contenuti statici di solito cambiano quando i file vengono rigenerati o pubblicati di nuovo. Il processo può essere automatizzato e attivato da un aggiornamento del CMS, invece di richiedere a uno sviluppatore di modificare manualmente l’HTML.

Le pagine dinamiche possono richiedere informazioni aggiornate, ma le cache possono comunque ritardare la visualizzazione delle modifiche da parte dei visitatori. «Dinamico» non significa automaticamente «istantaneo».

Scegli il modello di aggiornamento in base alle conseguenze delle informazioni non aggiornate:

• Di norma, la biografia di un membro del team può attendere la pubblicazione.
• La descrizione di un corso potrebbe richiedere un rilascio programmato.
• La quantità disponibile in magazzino richiede una chiara politica di aggiornamento.
• La disponibilità deve essere verificata quando viene elaborata la transazione per finalizzare una prenotazione o un acquisto.

La presentazione al pubblico e la precisione delle transazioni sono responsabilità distinte. Anche un indicatore di disponibilità che sembra aggiornato in tempo reale non deve sostituire una verifica lato server prima di confermare una prenotazione.

Modifica, modelli e scalabilità#

Entrambi gli approcci supportano contenuti strutturati e layout riutilizzabili. Un generatore di siti statici può creare migliaia di pagine a partire da record, mentre un’applicazione dinamica può visualizzare molti record usando un unico modello.

Per chi redige i contenuti, le domande pratiche sono spesso più utili dell’etichetta architetturale:

• Possono aggiornare i contenuti senza modificare il codice?
• Possono visualizzare in anteprima le modifiche prima della pubblicazione?
• Possono riutilizzare un layout per un’intera categoria di contenuti?
• Possono programmare la pubblicazione e gestire le autorizzazioni?
• Possono correggere un componente condiviso senza modificare ogni pagina?

Su larga scala, i colli di bottiglia sono diversi. I progetti statici possono richiedere build selettive e un’elaborazione efficiente delle risorse. I progetti dinamici possono richiedere l’ottimizzazione delle query, la memorizzazione nella cache e una capacità di elaborazione sufficiente.

Sicurezza e manutenzione#

Un sito pubblico composto da file statici può evitare di esporre ai visitatori un CMS attivo o un backend per la generazione delle pagine. Questo riduce alcune categorie di rischi in fase di esecuzione.

Questo non rende l’intero sistema immune agli attacchi. Gli account di hosting, i sistemi di build, le dipendenze, gli script incorporati, i moduli e i servizi connessi devono comunque essere protetti.

Le funzionalità dinamiche comportano ulteriori responsabilità in materia di controllo degli accessi e informazioni archiviate. In particolare, verifica chi può leggere, creare, modificare ed eliminare i record. L’autenticazione identifica un utente; l’autorizzazione determina cosa può fare.

Anche la memorizzazione nella cache richiede attenzione. I contenuti pubblici condivisi spesso possono essere riutilizzati tra più richieste, ma i dati privati degli account non devono essere mostrati a un altro visitatore a causa di una cache configurata in modo errato.

Costi di sviluppo e gestione continuativa#

La distribuzione di contenuti statici può essere economica, soprattutto per le pagine informative pubbliche. Il budget complessivo può comunque includere un CMS, moduli, ricerca, analisi dei dati, infrastruttura di compilazione e sviluppo continuativo.

I siti web dinamici richiedono applicazioni e dati, ma le piattaforme gestite possono ridurre il lavoro necessario per mantenerli operativi. Un sistema di gestione dei contenuti ben mantenuto può anche far risparmiare molto tempo alla redazione.

Stima i costi dell’intero flusso di lavoro:

• Implementazione iniziale e migrazione dei contenuti.
• Hosting, database e abbonamenti a servizi di terze parti.
• Produzione di contenuti e aggiornamenti periodici.
• Manutenzione, monitoraggio e assistenza.
• Modifiche future alle funzionalità o all’hosting.

Il piano di hosting più economico non è necessariamente la soluzione meno costosa, se ogni modifica ai contenuti richiede interventi manuali di sviluppo.

SEO, panoramiche AI e visibilità nei modelli linguistici di grandi dimensioni (LLM)#

L’architettura di un sito web influisce sulla facilità con cui i motori di ricerca possono individuare e raggiungere i contenuti. Può avere un impatto significativo quando un’implementazione nasconde informazioni utili dietro l’esecuzione nel browser, link non funzionanti o percorsi con accesso limitato.

Tuttavia, l’architettura da sola non determina il posizionamento, l’inclusione nelle risposte dell’IA o le menzioni del marchio. Sia le pagine statiche sia quelle dinamiche renderizzate dal server possono offrire contenuti pubblici accessibili.

Rendi disponibili i contenuti principali nel codice HTML restituito#

Per un articolo pubblico, una pagina di categoria o una pagina di servizio, controlla cosa restituisce il server prima che venga eseguito JavaScript nel browser. Contiene il titolo, la spiegazione e i link effettivi oppure solo un guscio vuoto dell’applicazione?

Sia le pagine prerenderizzate sia quelle renderizzate dal server possono restituire codice HTML significativo. Cambiano i tempi di generazione, ma in entrambi i casi un crawler può ricevere contenuti utili.

Google può eseguire JavaScript, anche se il rendering aggiunge una fase di elaborazione e comporta alcune considerazioni implementative. Altri bot potrebbero non eseguirlo. Le indicazioni di Google sulla SEO per JavaScript consigliano di valutare il rendering lato server o il prerendering per gli utenti e i crawler.

La raccomandazione pratica è rendere disponibili i contenuti pubblici importanti senza obbligare i visitatori a fare clic su un controllo o a completare prima una sequenza che funziona solo nel browser. Le funzionalità interattive possono poi basarsi su queste fondamenta accessibili.

Le Panoramiche AI si basano sull'idoneità alla ricerca, non su una preferenza per i siti statici#

Le indicazioni di Google per le funzionalità AI spiegano che, per poter essere inclusi come link di supporto nelle Panoramiche AI o nella modalità AI, i contenuti devono essere indicizzati e idonei a comparire con uno snippet. L'idoneità non garantisce che vengano selezionati.

Un sito non gode di una preferenza particolare solo perché i suoi file sono stati generati staticamente. Anche una pagina dinamica che offre contenuti chiari e accessibili può essere idonea.

Google non richiede neppure uno schema AI speciale né un file di testo AI aggiuntivo per queste funzionalità. Prima di considerare un nuovo formato di file come una strategia di ottimizzazione, concentrati su contenuti utili, accessibilità alla scansione, link interni e controlli di ricerca adeguati.

Le citazioni degli LLM e le menzioni del brand sono risultati diversi#

Il recupero di una pagina da parte di un assistente AI durante una ricerca è diverso dalla menzione di un brand da parte di un modello linguistico sulla base di informazioni apprese in precedenza. I prodotti possono combinare in modi diversi indici di ricerca, recupero di informazioni in tempo reale e conoscenze del modello.

Rendere accessibile una pagina offre ai sistemi di recupero la possibilità di utilizzarla. Non garantisce che la pagina venga scelta come fonte, che compaia una citazione o che il brand venga menzionato in una risposta specifica.

Nella pianificazione editoriale, considera l'accessibilità tecnica e l'utilità dei contenuti come verifiche separate:

• Accessibilità: il sistema è in grado di raggiungere e leggere le informazioni pertinenti?
• Utilità: la pagina contiene una risposta specifica e credibile alla domanda posta?

Cambiare il metodo di rendering non può compensare descrizioni vaghe dei servizi, dettagli mancanti sui prodotti o informazioni contraddittorie tra le pagine.

Rendi reperibili le informazioni pubbliche e proteggi quelle private#

Le dashboard private e i dati degli account devono rimanere protetti. Non è necessario renderli indicizzabili per migliorare la visibilità dell'azienda.

Pubblica invece pagine accessibili a tutti che illustrino chiaramente i tuoi prodotti, servizi, criteri di prezzo e competenze pertinenti. Assegna a queste pagine indirizzi stabili e collegamenti di navigazione, in modo che possano essere trovate indipendentemente dall'applicazione.

Per una piattaforma di corsi, la descrizione pubblica del corso può illustrare il programma, il livello e i requisiti di iscrizione. I progressi degli studenti e lo storico dei pagamenti devono invece restare protetti dall'autenticazione.

Una checklist pratica per l'architettura#

Prima di cambiare piattaforma o metodo di rendering:

• Esamina l'HTML restituito per alcune pagine pubbliche rappresentative.
• Confrontalo con la pagina visualizzata per individuare eventuali contenuti principali mancanti.
• Verifica che le pagine importanti abbiano URL accessibili e distinti.
• Usa link standard esplorabili per la navigazione pubblica.
• Controlla le regole robots, le direttive di indicizzazione, gli URL canonici e i codici di stato delle risposte.
• Prova le modifiche ai contenuti per verificare quando si aggiorna effettivamente la versione pubblicata.
• Monitora l'indicizzazione e l'esperienza sulle pagine, invece di dare per scontato che l'architettura garantisca i risultati.

Per i dettagli di implementazione, consulta la nostra guida a SEO per siti web statici. Lo stesso requisito generale vale per le pagine dinamiche: i contenuti che vuoi rendere individuabili devono essere accessibili, comprensibili e utili.

Esempi di website builder, CMS e framework#

Gli strumenti non rientrano sempre nettamente nella categoria statica o dinamica. Alcuni generano file, altri eseguono applicazioni e altri ancora forniscono contenuti a un frontend separato.

La tabella seguente distingue questi ruoli. Include website builder, sistemi di pubblicazione, generatori di siti statici e framework, così puoi confrontare sia l'output sia la quantità di lavoro di implementazione necessaria.

Un CMS headless, di per sé, non determina l’architettura del sito pubblico. La stessa API dei contenuti può alimentare una build statica o un’applicazione renderizzata sul server.

Allo stesso modo, la presenza di un CMS non significa che ogni visita attivi una nuova query al database. Tra il sistema di gestione dei contenuti e i visitatori possono esserci pagine generate e risposte memorizzate nella cache.

Se l’output precompilato è adatto al tuo progetto, il nostro confronto tra i generatori di siti statici più diffusi presenta altre opzioni. Se la tua priorità è la modifica visiva, valuta il flusso di pubblicazione insieme all’output, invece di scegliere basandoti solo sul nome della tecnologia.

Come TeleportHQ gestisce siti web statici e dinamici#

Supportiamo progetti che presentano informazioni pubbliche e progetti che leggono dati ed eseguono funzionalità applicative. Puoi creare l’interfaccia visiva e poi scegliere i dati e le funzionalità lato server di cui il progetto ha bisogno.

Questa distinzione è importante quando si pianificano l’hosting, l’esportazione del codice e le modifiche future. Anche le categorie dei nostri prodotti hanno significati specifici: un TeleportHQ Website può mostrare dati collegati senza diventare automaticamente un TeleportHQ Web App.

Crea pagine statiche con interazioni nel browser#

Usa il nostro generatore di siti web statici per creare visivamente pagine pubbliche con layout e componenti riutilizzabili. L’output statico può includere interazioni nel browser: aprire un pannello a fisarmonica o passare da una scheda all’altra non richiede necessariamente funzionalità applicative su un server.

Per esempio, un sito web di servizi può includere un menu di navigazione interattivo, una spiegazione dei prezzi e risposte espandibili, pur presentando contenuti pubblici condivisi. La sola interazione non trasforma la pagina in un’applicazione basata su database.

Alcuni comportamenti dipendono dal formato di esportazione selezionato. La nostra guida agli stati dei componenti spiega come funzionano i semplici stati attivati dai clic e quali sono i limiti dell'HTML scaricato.

Collega il database che preferisci o un'API esterna#

Le nostre integrazioni con le origini dati ti permettono di importare nel progetto informazioni già esistenti. Tra le opzioni supportate figurano PostgreSQL, MySQL, MariaDB, MongoDB, Firestore, Supabase e altri servizi di database.

Puoi collegare un database usando il metodo di connessione supportato. Se un sistema non dispone di un connettore nativo adeguato, è possibile usare un'API REST che restituisce JSON come alternativa, purché il servizio renda disponibili i dati e gli accessi necessari.

Questo ti offre la flessibilità di usare il database che preferisci, senza però implicare che ogni motore di database disponga di un'integrazione nativa. I requisiti e le funzionalità di connessione dipendono dall'origine.

Per i contenuti editoriali, la nostra integrazione con un CMS headless collega il frontend a un sistema di gestione dei contenuti esistente. Sono supportati Strapi, Contentful, WordPress, caisy.io e Flotiq; la guida alla configurazione del CMS illustra la procedura di connessione.

Usa un database fornito da TeleportHQ#

Se non hai già un database, possiamo predisporre per il tuo progetto un database PostgreSQL ospitato. Puoi creare tabelle e gestire i record dall'editor, senza dover configurare un server di database separato.

La configurazione del database integrato ti offre uno spazio in cui archiviare informazioni strutturate, come prodotti o iscritti. Le pagine pubblicate possono leggere i record aggiornati senza dover ripubblicare il sito a ogni modifica dei contenuti.

Questo database è compatibile con l'hosting di TeleportHQ. Il codice scaricato non potrà continuare a utilizzarlo su un altro host. Se prevedi di usare un hosting indipendente, scegli un database esterno e verifica gli altri requisiti di esportazione del progetto prima di basarti sulla soluzione ospitata.

La capacità e la disponibilità della versione di prova dipendono dal piano; i limiti attuali del database sono documentati separatamente.

Trasforma i dati in elenchi e pagine di dettaglio#

Collegare una fonte è solo il primo passo. Poi associ i suoi valori agli elementi dell'interfaccia.

Ad esempio, un database di corsi può fornire:

• Un titolo e un'immagine di copertina per ogni scheda del corso.
• Un elenco ripetuto dei corsi disponibili.
• Una pagina di dettaglio per un singolo corso.
• Righe strutturate in una tabella.

La nostra guida al collegamento dei dati spiega come collegare i campi e creare design ripetuti per i record. In questo modo puoi gestire le informazioni sottostanti separatamente dal layout usato per visualizzarle.

Comprendere il rendering lato server, le applicazioni web e l'esportazione#

Quando aggiungi una prima origine dati, le pagine basate sui dati utilizzano il rendering lato server e l’esportazione del codice è limitata a Next.js. Questo, da solo, non attiva la categoria separata delle Web App.

Funzionalità come l’autenticazione degli utenti, i flussi di lavoro, un negozio online o il blog integrato attivano le funzionalità delle Web App. Le Web App di TeleportHQ vengono eseguite sul nostro hosting, non possono essere scaricate come codice e, dopo il periodo iniziale di accesso di sette giorni, richiedono uno slot Web App.

Consulta cosa rende un progetto TeleportHQ una Web App quando pianifichi queste funzionalità. In questo modo distingui le interazioni nel browser e i contenuti collegati dalle operazioni lato server che modificano i requisiti di distribuzione del progetto.

Quale approccio scegliere?#

L’aspetto più importante da chiarire prima di scegliere tra siti web statici e dinamici è lo scopo del sito che intendi realizzare.

Parti da ciò che i visitatori devono fare, poi scegli come deve funzionare ciascuna parte. Il numero di pagine e la complessità visiva sono punti di partenza molto meno utili rispetto all’aggiornamento dei contenuti, ai requisiti di accesso e a ciò che i visitatori devono poter salvare o modificare.

Scegli la pubblicazione statica per i contenuti pubblici che possono essere preparati in anticipo#

È spesso una scelta adatta per:

• Pagine aziendali e di servizi.
• Landing page per campagne.
• Portfolio e casi di studio.
• Documentazione e articoli didattici.
• Descrizioni di catalogo che non richiedono la generazione personalizzata per ogni visitatore.

Scegli un flusso di lavoro di modifica adatto al tuo team. Un sito basato su CMS può supportare pubblicazioni regolari, mentre i modelli di siti web statici possono offrire una struttura iniziale per le pagine pubbliche più comuni.

Aggiungi funzionalità dinamiche quando necessario#

Usa servizi in fase di esecuzione per esigenze quali:

• Account cliente sicuri.
• Dashboard personalizzate.
• Ordini, prenotazioni e pagamenti.
• Disponibilità attuale o dati operativi soggetti a frequenti variazioni.
• Record condivisi che i visitatori creano o aggiornano.

Stabilisci quali informazioni devono essere visualizzate immediatamente e quali possono essere memorizzate nella cache. Individua anche chi è responsabile delle autorizzazioni, dei backup, della gestione degli errori e della manutenzione continua.

Combina gli approcci quando il sito web soddisfa esigenze diverse#

Un'attività non deve scegliere un unico metodo di rendering per tutte le pagine. Le pagine dei servizi pubblici possono essere generate in anticipo, il catalogo può usare il rendering lato server e l'area account può caricare dati privati dopo l'autenticazione.

Prima di scegliere una piattaforma, rispondi a cinque domande:

1. Quali contenuti possono essere identici per tutti i visitatori?
2. Quali informazioni devono essere aggiornate nel momento in cui avviene un'azione?
3. Quali operazioni richiedono l'autenticazione o una memorizzazione persistente?
4. Chi aggiornerà il sito e con quale frequenza?
5. Di quale flessibilità di hosting ed esportazione avrà bisogno il progetto in futuro?

Queste risposte offrono una base più affidabile per scegliere, invece di dare per scontato che statico significhi basilare o dinamico significhi migliore.