Un gioco HTML5 che resta sul disco fisso in pratica non esiste. Finché non ha un indirizzo, nessuno può giocarci con un clic, inserirlo in un portfolio o iscriverlo a una jam. La buona notizia è che una build web richiede pochissimo per stare online: niente database, niente PHP, niente server applicativo. File statici, un URL, HTTPS.
La cattiva notizia è che «pochissimo» resta comunque qualcosa. A seconda del motore usato, del peso della build e dell’uso previsto, i tre servizi di hosting gratuiti più diffusi – itch.io, GitHub Pages e Netlify – hanno differenze concrete. Li usiamo tutti e tre in studio, su progetti diversi, ed ecco che cosa li distingue davvero.
Che cosa chiede un gioco HTML5 al suo hosting
Un export web è una cartella: un index.html, uno o due file JavaScript, spesso un .wasm e una serie di asset. Qualsiasi server di file statici sa distribuirlo, a tre condizioni. Prima l’HTTPS, perché schermo intero, blocco del puntatore, API Gamepad e avvio dell’audio dipendono da questo sui browser recenti. Poi i tipi MIME: un file .wasm servito come text/plain impedisce l’istanziazione in streaming e allunga i tempi di caricamento. Infine la compressione, gzip o Brotli, perché un export Godot o Unity arriva facilmente a decine di megabyte da decompresso.
Il caso particolare delle build multithread
Se il motore usa i thread – succede con gli export Godot 4 con rendering threaded e con molte build Unity WebGL – il browser richiede che la pagina sia isolata tra origini. In pratica il server deve restituire due header, Cross-Origin-Opener-Policy: same-origin e Cross-Origin-Embedder-Policy: require-corp, senza i quali SharedArrayBuffer resta indisponibile e il gioco rifiuta di partire. Questo singolo vincolo esclude uno dei tre servizi che vediamo qui sotto.
itch.io, prima una vetrina e poi un hosting
Su itch.io si carica un archivio ZIP con un index.html nella radice, si spunta l’opzione che indica il file come giocabile nel browser e la piattaforma pensa al resto. È il percorso più breve tra una build e un link giocabile. Ed è anche l’unico dei tre che porta pubblico: pagina prodotto, devlog, commenti, statistiche di visualizzazione, iscrizione a una jam e raccolta di donazioni sono già integrati.
I limiti dichiarati per una build giocabile nel browser sono 1.000 file, 200 MB per file e 500 MB da decompresso. Comodo per un gioco 2D, molto più stretto per un progetto 3D. Oltre quella soglia, lo strumento a riga di comando butler permette di caricare versioni ben più pesanti.
In cambio, la pagina non è vostra. L’URL resta su nomeutente.itch.io, l’impaginazione segue un modello e il posizionamento sui motori di ricerca va prima di tutto a vantaggio della piattaforma. Per mostrare un lavoro a un cliente o alimentare un sito professionale è il supporto sbagliato.
GitHub Pages, quando il repository diventa il sito
Se il progetto è già versionato, GitHub Pages costa quasi zero lavoro in più: si carica la cartella di build, si attiva Pages nelle impostazioni del repository e il gioco è online dopo pochi secondi, in HTTPS, con la possibilità di collegare un dominio personalizzato senza spese.
I limiti documentati sono generosi per un gioco: 1 GB per il sito pubblicato, 100 GB di banda al mese e una decina di build all’ora. Sono limiti morbidi: GitHub avvisa o rallenta invece di fatturare.
L’ostacolo vero sta altrove. GitHub Pages non permette di impostare header HTTP personalizzati. Niente COOP, niente COEP, quindi niente isolamento tra origini e niente SharedArrayBuffer: un export Godot 4 multithread o una build Unity WebGL con thread semplicemente non parte. La richiesta torna con regolarità nelle discussioni della community GitHub da diversi anni, senza risposta. Per un gioco in JavaScript puro, per esempio con Phaser, il problema non si pone e Pages fa benissimo il suo lavoro.
Netlify, deploy continuo e nuovo listino
Netlify accetta sia il trascinamento di una cartella di build sia il collegamento diretto di un repository Git, con ridistribuzione automatica a ogni commit. Soprattutto, lascia scrivere gli header che servono, tramite un file _headers messo nella cartella pubblicata oppure tramite netlify.toml. È la via più semplice per servire una build multithread isolata come si deve.
Attenzione però al cambio di modello. Gli account creati da settembre 2025 sono passati a un sistema a crediti: 300 crediti al mese sul piano gratuito, con un deploy in produzione che costa 15 crediti e la banda 20 crediti per gigabyte. In pratica si parla di una quindicina di gigabyte di traffico oppure di una ventina di deploy, con tetto rigido. Gli account più vecchi mantengono la formula precedente, 100 GB di banda e 300 minuti di build. Per un gioco web da decine di megabyte vale la pena fare il conto prima di diffondere il link.
Quale scegliere in base al progetto
Per una jam o una prima pubblicazione, itch.io resta la scelta ovvia: la pagina esiste in dieci minuti, il pubblico è già lì e nessuno si aspetta un URL di marca. Per un portfolio, un prototipo mostrato a un cliente o un gioco da indicizzare sotto il proprio dominio, GitHub Pages è difficile da battere, a patto che la build non richieda isolamento tra origini. Appena il motore pretende COOP e COEP, oppure quando serve un deploy continuo pulito, Netlify diventa l’unica opzione comoda dei tre – tenendo d’occhio i consumi.
Del resto niente obbliga a sceglierne uno soltanto. Pubblichiamo spesso la stessa versione in due posti: su itch.io per visibilità e feedback, sul nostro dominio per il portfolio. La build è identica, cambia il contesto. E se vi state chiedendo che cosa possa davvero prendersi in carico l’automazione in questa catena, ne abbiamo parlato in IA e giochi indie: cosa si può davvero automatizzare nel 2026.
Gli errori che tornano più spesso
Il primo è l’archivio malformato: l’index.html finisce in una sottocartella invece che nella radice dello ZIP e la piattaforma mostra una pagina bianca. Il secondo arriva dai percorsi assoluti. Un GitHub Pages di progetto serve il sito da /nome-del-repository/, quindi un asset richiamato in /assets/sprite.png viene cercato nella radice del dominio e fallisce in silenzio. Servono percorsi relativi, oppure una base configurata al momento dell’export.
Poi arrivano il contenuto misto – un font o un suono richiamati in http:// da una pagina in https:// vengono bloccati senza avvisi visibili –, la compressione dimenticata, che trasforma un caricamento da tre secondi in un’attesa da trenta, e il test su mobile mai fatto, dove il tocco e la memoria disponibile non perdonano le ipotesi prese davanti a una tastiera.
Per approfondire
Mettere online un gioco HTML5 richiede dieci minuti, una volta capito che cosa il browser si aspetta dal server. Il lavoro importante viene prima, nella preparazione della build: percorsi relativi, asset compressi, header coerenti con il motore. Se partite da zero, la nostra guida per creare un gioco 2D con Phaser 4 copre la parte di sviluppo, mentre la guida completa per creare un gioco in JavaScript riprende le basi. Sul fronte letture, i manuali di sviluppo giochi in JavaScript restano una buona porta d’ingresso, e le uscite indipendenti si seguono bene su Subway Press.
0 Commenti