Zero Articoli Prerenderizzati: Perché il Prerender Totale è un Rischio di Build, non un'Ottimizzazione

"Prerenderizza tutto quello che puoi" è il consiglio da tutorial che chiunque scriva SSR con Angular ha sentito almeno una volta. È un buon consiglio a 50 pagine. Su questo portfolio, con oltre 1200 articoli di blog e una crescita settimanale, prerenderizzare ogni singola pagina articolo non è mai stata la scelta: è stata deliberatamente esclusa, e il codice lo dichiara in un commento, non in retrospettiva dopo un incidente.

Disclaimer di metodo: questa non è una raccomandazione teorica su rendering strategy. È la lettura diretta di frontend/src/app/app.routes.server.ts, il file che configura la strategia SSR di questo stesso sito, verificabile da chiunque abbia accesso al repository.

Il dato: 50 prerender contro 134 server-on-demand

Il conteggio esatto delle configurazioni di rotta in app.routes.server.ts:

• 50 configurazioni con RenderMode.Prerender (homepage, pagine categoria, pagine statiche).
• 134 configurazioni con RenderMode.Server (articoli blog, route con parametri dinamici).
• 1 configurazione con RenderMode.Client.

Il commento in testa al file è esplicito: "Blog articles: Server-rendered on demand (too many for build-time prerender)". Non è una scusa post-hoc per un problema di performance: è una decisione architetturale scritta prima, come motivazione del design, non come giustificazione di un compromesso subito.

Perché "prerenderizza tutto" smette di essere un consiglio sicuro

Il prerender build-time ha un vantaggio enorme: ogni pagina statica diventa un file HTML già pronto, servito da Nginx senza toccare il processo Node in produzione. Time-to-first-byte quasi zero, nessun carico runtime, superficie di attacco minima.

Il problema emerge quando il numero di pagine da prerenderizzare cresce oltre un certo ordine di grandezza. Ogni pagina prerenderizzata deve essere costruita durante il processo di build: più pagine, build più lenta, più memoria richiesta, più probabilità che un singolo articolo con un bug di rendering (un componente che lancia un errore SSR su un dato malformato) faccia fallire l'intero processo di build, bloccando il deploy di TUTTI i contenuti, non solo di quello con il bug.

Con oltre 1200 articoli di blog, prerenderizzarli tutti significa che un solo articolo rotto può impedire il deploy dell'intero sito. Con il rendering server-on-demand, lo stesso articolo rotto genera un errore quando (e solo quando) qualcuno lo visita, isolato dal resto del sito che continua a funzionare.

Il trade-off reale: TTFB contro stabilità della build

Non esiste una risposta universalmente corretta tra prerender e server-on-demand: è un trade-off che va misurato, non assunto per dogma. I due lati:

• Prerender: TTFB quasi zero, nessun carico runtime sul processo Node, ma la build cresce linearmente col numero di pagine e un solo errore di rendering può bloccare il deploy di tutto il sito.
• Server-on-demand: build stabile e veloce indipendentemente dal numero di pagine, isolamento dei fallimenti (un articolo rotto non blocca gli altri), ma TTFB più alto per richiesta e carico runtime reale sul processo Node in produzione.

La soglia in cui conviene passare dall'uno all'altro non è ovvia e dipende da quanto velocemente cresce il contenuto, quanto è affidabile la pipeline di generazione contenuti, e quanto è tollerante il team a un deploy bloccato da un singolo file rotto. Su questo portfolio, con contenuto generato in batch (a volte centinaia di articoli per fase) e un sistema agentico che scrive HTML runtime, il rischio di un singolo file malformato che blocca TUTTO il deploy era considerato inaccettabile: da qui la scelta di escludere gli articoli dal prerender fin dall'inizio.

La contraddizione apparente con "1080 route prerenderizzate"

La documentazione interna di questo progetto cita spesso "circa 1080 route prerenderizzate" come statistica del sito. Non è in contraddizione con questo articolo: quel numero descrive il totale di route statiche, per-lingua e categoria che rientrano nelle 50 configurazioni RenderMode.Prerender (ognuna delle quali può espandersi in decine di URL concreti per via delle 7 lingue compilate AOT), non gli oltre 1200 articoli di blog, che restano deliberatamente fuori da quel conteggio e vengono serviti on-demand. La distinzione tra "quante configurazioni di rotta" e "quanti URL concreti genera ciascuna configurazione" è dove la maggior parte delle discussioni superficiali su prerender va fuori strada.

Quando prerenderizzare tutto è davvero la scelta giusta

Su un sito con un numero di pagine stabile e conosciuto in anticipo (un portfolio con 15 pagine, un sito vetrina aziendale, una documentazione tecnica con un centinaio di pagine versionate), prerenderizzare tutto resta la scelta corretta senza se e senza ma: il costo di build è fisso e prevedibile, e il vantaggio di TTFB quasi zero non ha controindicazioni reali. Il problema non è il prerender in sé: è applicarlo per dogma a un content model che cresce senza un limite superiore noto in anticipo.