Blazor in produzione: WebAssembly, Server o Auto e come scegliere senza sbagliare nel 2026

Portare Blazor in produzione sembra una formalità.

Non lo è.

Ho visto questa scena decine di volte: il tech lead propone Blazor WebAssembly per il nuovo portale pubblico dell'azienda.

La motivazione sembra buona.

Il team conosce già C#, nessuno deve imparare JavaScript, modelli e logica di dominio si condividono tra frontend e backend nello stesso progetto.

La sala riunioni annuisce.

Il progetto parte, i test passano, il rilascio fila liscio.

Sei mesi dopo, il CEO chiede perché l'applicazione non appare su Google.

Il traffico organico è zero.

Il primo caricamento dura otto secondi su mobile.

Ogni pagina condivisa su LinkedIn mostra la stessa anteprima vuota.

Solo allora il tech lead scopre cosa significa "rendering lato client" per un motore di ricerca, e capisce che nessuna toppa nel weekend risolverà il problema.

Il punto è questo: Blazor è una tecnologia eccellente, ma sotto il cofano sono tre tecnologie diverse.

Quattro, se conti il rendering statico.

Ognuna con la sua architettura e i suoi compromessi.

Sbagliare modalità non produce errori di compilazione.

Produce problemi che esplodono in produzione, mesi dopo il rilascio.

E a quel punto correggere costa caro: tempo, reputazione, spesso fatturato.

Molto più di quanto sarebbe costato scegliere bene fin dall'inizio.

In questo articolo trovi tutto quello che quella riunione avrebbe dovuto mettere sul tavolo prima di aprire Visual Studio.

Le tre modalità di rendering e le loro differenze reali.

Quando ciascuna ha senso e quando è un errore.

Il problema SEO e come si risolve davvero.

I numeri veri sul primo caricamento, l'autenticazione e dove sta la sicurezza vera, il confronto onesto con React e Angular, e una checklist pratica prima del lancio.

Le tre modalità di rendering di Blazor: non è tutto uguale

Blazor non è un'unica tecnologia.

È una famiglia di modelli di rendering che condividono la sintassi Razor e il linguaggio C#, ma sotto funzionano in modo completamente diverso.

E le conseguenze sono concrete.

Cambia dove vive il codice, cosa scarica il browser, come viaggiano i dati tra client e server.

Confonderle, o prendere la modalità di default senza capirne le implicazioni, ti porta dritto al disastro dell'apertura.

Da .NET 8 in avanti, Blazor espone quattro modalità di rendering, che scegli per singolo componente con l'attributo @rendermode.

• Static Server: nessuna interattività, HTML generato una volta sola.
• Interactive Server: quello che tutti continuano a chiamare Blazor Server.
• Interactive WebAssembly: Blazor WASM.
• Interactive Auto: combina le ultime due modalità.

La granularità per componente è il vero cambio di passo di .NET 8.

Prima l'intera applicazione doveva scegliere una modalità sola.

Oggi mescoli, pagina per pagina o componente per componente, in base a cosa serve davvero in quel punto dell'interfaccia.

Blazor WebAssembly (WASM) esegue il codice .NET direttamente nel browser.

Nessun server genera HTML: il browser scarica il runtime .NET, le DLL e tutta la logica, e da lì esegue ogni cosa per conto suo, senza tornare al server per il rendering.

È un modello client-side puro, strutturalmente simile a React o Angular, ma scritto interamente in C#.

Blazor Server, ribattezzato Interactive Server in .NET 8, fa l'opposto.

Il rendering avviene sul server, il browser riceve HTML già pronto, e la comunicazione passa da una connessione SignalR su WebSocket.

Ogni click, ogni input, ogni navigazione viaggia su quella connessione fino al server, che ricalcola e rimanda al browser solo il pezzo di pagina cambiato.

Blazor Auto, arrivato con .NET 8 e affinato fino a .NET 9, combina le due in sequenza.

Al primo caricamento usa Server: HTML subito pronto, l'utente interagisce senza aspettare nessun download.

In parallelo, il browser scarica in background il runtime WebAssembly.

Alle visite successive, a download completato, i componenti passano da soli in modalità WASM e la dipendenza dal server per il rendering sparisce.

Per dichiarare la modalità di un componente basta una direttiva Razor in cima al file, accanto a quella di route.

Indichi Server, WebAssembly o Auto, e hai finito.

La transizione da Server a WebAssembly la gestisce il framework, senza altro codice da scrivere, a una condizione: che il componente funzioni bene in entrambi gli ambienti.

Tienilo a mente, perché è un vincolo che riprendiamo più avanti.

Accanto alle tre modalità interattive c'è il rendering statico lato server (Static SSR), pensato per le pagine che non hanno bisogno di interattività: contenuti editoriali, pagine informative, sezioni marketing.

Static SSR genera HTML alla richiesta, senza tenere stato sul server e senza scaricare runtime sul client.

Per la parte pubblica di un sito è spesso la scelta più efficiente, anche quando il resto dell'applicazione usa WASM o Server.

Mescolare Static SSR, WASM, Server e Auto nella stessa applicazione non solo si può fare: il più delle volte è la scelta giusta.

Assegni a ogni componente la modalità più adatta ai suoi requisiti di interattività, SEO e performance.

Non è una preferenza di stile.

Questa scelta decide SEO, velocità al primo caricamento, requisiti di infrastruttura e comportamento offline dell'intera applicazione.

Chi non lo capisce se ne accorge quando l'applicazione è già in mano agli utenti, e lì cambiare strada significa riscrivere pezzi interi del progetto.

Un dettaglio che frega chi arriva da ASP.NET Core classico: un componente Static SSR con isole interattive viene renderizzato due volte.

Prima il server genera l'HTML; poi il componente interattivo si "attacca" al DOM già presente (quello che il resto del web chiama hydration).

Se l'inizializzazione ha effetti collaterali, per esempio una chiamata API che incrementa un contatore, quell'effetto rischia di scattare due volte invece di una.

La soluzione è distinguere in modo esplicito la fase di prerendering da quella interattiva, invece di dare per scontato che l'inizializzazione avvenga una volta sola.

Blazor WebAssembly in produzione: quando ha senso e quando no

Blazor WebAssembly è la modalità scelta più spesso per le ragioni sbagliate.

"Così non mi serve un server per il frontend", "è come React ma in C#", "possiamo funzionare offline".

Osservazioni tecnicamente corrette, in astratto.

Ognuna nasconde implicazioni che devi capire prima di andare in produzione, non dopo la telefonata del cliente che si lamenta.

Quando WASM è la scelta giusta

Per applicazioni interne, gestionali e dashboard aziendali, dove l'accesso è autenticato e la SEO non conta, WASM è quasi sempre la scelta migliore se il team conosce già .NET.

Qui il download iniziale capita una volta per dipendente, le DLL finiscono in cache, e dalle visite successive tutto gira in locale con performance eccellenti.

Un CRM interno, un gestionale di magazzino, una dashboard di reportistica per il management: in scenari così, pochi secondi di attesa al primo accesso, tipicamente una volta al giorno, sono un compromesso più che accettabile.

In cambio, il team scrive tutto in C#, senza imparare un secondo stack completo.

Per le Progressive Web App con requisiti offline reali, Blazor WASM con un service worker funziona senza connessione e sincronizza i dati quando la rete torna.

Penso all'assistenza tecnica in mobilità, alle ispezioni sul campo, alla raccolta dati in cantiere o dove la connessione è ballerina: il tecnico compila il modulo offline, e l'app sincronizza al primo segnale.

Per applicazioni con logica client-side complessa, dove evitare il viaggio al server a ogni interazione migliora l'esperienza in modo misurabile, WASM è spesso l'unica scelta sensata.

Pensa a un editor di testo o di codice, a un calcolatore con formule articolate, a strumenti che lavorano su dati già presenti sul client senza interrogare il server a ogni tasto premuto.

Quando WASM, invece, è l'errore da manuale

Per qualsiasi applicazione pubblica che vive di traffico organico, Blazor WASM puro è quasi sempre la scelta sbagliata.

Un blog aziendale, un portale informativo, un e-commerce costruiti interamente in WASM avranno problemi SEO strutturali, che emergono solo mesi dopo il lancio (li vediamo tra poco).

E quando te ne accorgi, tornare indietro e ristrutturare l'architettura pubblica costa settimane di lavoro che un'analisi iniziale avrebbe evitato.

Quando il primo caricamento decide la conversione, il conto è altrettanto salato.

Prima di diventare interattiva, un'app WASM deve scaricare ed eseguire l'intero runtime .NET nel browser: su un mobile di fascia media sono diversi secondi di attesa.

Il dato di Google è impietoso: oltre i 3 secondi di caricamento su mobile, più della metà degli utenti abbandona.

Per una landing page, un form di acquisizione lead o una pagina prodotto è fatturato perso, e chi se ne va quasi mai torna a riprovare.

Il confine vero è uno solo: contesto interno autenticato da una parte, contesto pubblico che vive di traffico dall'altra.

Nel primo, Blazor WASM è la scelta migliore.

Nel secondo diventa un problema in produzione, con impatto diretto sul fatturato invece che su una nota a margine in una revisione del codice.

Scegliere la modalità giusta al primo colpo non è fortuna: è mestiere.

Chi conosce Blazor a fondo queste decisioni le prende in una riunione, non dopo sei mesi di traffico organico a zero.

È esattamente il mestiere che costruisci nel corso Blazor: architettura, casi reali e gli errori da non ripetere, spiegati da chi li ha già pagati in produzione.

Blazor Server in produzione: SignalR, circuiti e limiti di scala

Blazor Server risolve il primo caricamento in modo elegante.

HTML già renderizzato dal server, mostrato subito dal browser, e SignalR che gestisce tutta la comunicazione successiva.

Per la SEO le pagine sono HTML completo fin dalla prima risposta: vengono indicizzate correttamente, senza trucchi.

Ma il prezzo c'è, ed è strutturale.

Ogni utente connesso tiene aperta una WebSocket verso il server per tutta la sessione, e il server deve conservare in memoria lo stato del circuito per ogni connessione attiva.

Il circuito comprende i componenti renderizzati, lo stato dei form compilati e l'albero del DOM usato per calcolare le differenze.

Con cento utenti concorrenti reggi tranquillamente su un'infrastruttura modesta.

Con diecimila sulla stessa macchina, il dimensionamento diventa un problema serio.

I numeri per la pianificazione

Un server con 2 GB di RAM dedicati a un'app Blazor Server gestisce all'incirca 5.000-15.000 circuiti concorrenti.

La forbice dipende dalla complessità dell'applicazione, da quanto stato tieni per utente e dal tipo di interazione: un'app con form semplici regge più circuiti di una con griglie dati aggiornate in tempo reale.

I numeri cambiano da progetto a progetto, ma ti danno l'ordine di grandezza per partire.

Sotto le migliaia di utenti concorrenti, un singolo server ben dimensionato basta.

Oltre quella soglia, la conversazione sull'infrastruttura falla prima del go-live, non dopo.

Scalabilità orizzontale

Per scalare Blazor Server su più istanze dietro un load balancer hai due strade:

• Sticky session: in questo modo ogni utente finisce sempre sullo stesso server per tutta la sessione.
• Un backplane distribuito per SignalR: sincronizza lo stato tra le istanze, tipicamente Redis o Azure SignalR Service.

Senza una delle due, l'utente instradato su un server diverso da quello del suo circuito perde la sessione all'istante.

In produzione lo vedi come disconnessioni casuali e apparentemente inspiegabili.

Azure SignalR Service sposta le connessioni WebSocket fuori dal server applicativo: i client vivono sul servizio gestito, e la tua applicazione parla con quello invece che con i browser.

Su Azure è la strada più semplice se non vuoi gestirti un Redis: paghi una dipendenza in più e un costo che cresce con le connessioni concorrenti.

Il rischio della disconnessione

Se la WebSocket cade, per instabilità della rete, timeout o restart del server, Blazor Server mostra il messaggio di riconnessione e prova a ripristinare il circuito nella finestra configurata.

Ma se nel frattempo il server è ripartito, il circuito è perso per sempre: l'utente ricarica da zero e butta via ogni dato non salvato.

Per le sessioni di lavoro lunghe questo scenario lo devi progettare, non subire.

L'operatore che compila un form per venti minuti, il configuratore di preventivo complesso: le contromisure sono salvataggi automatici periodici, conferme visive che i dati siano stati persistiti sul server, e un messaggio chiaro quando la riconnessione fallisce.

L'alternativa è che l'utente scopra il danno solo al momento dell'invio finale.

Blazor Server è la scelta giusta per applicazioni interne, con rete stabile e utenti concorrenti sotto le migliaia.

Per portali pubblici con traffico alto, picchi imprevedibili e connessioni mobile ballerine, i requisiti di infrastruttura diventano presto un salasso, in costi e in complessità operativa.

Blazor Auto in .NET 8 e 9: la modalità ibrida che cambia il quadro

La modalità Auto, arrivata con .NET 8, è la risposta di Microsoft a un dilemma storico: prendere il meglio di Server e WASM, e spostare la complessità della transizione nel framework invece che sulle tue spalle.

Il meccanismo è questo.

Al primo accesso, i componenti interattivi girano in modalità Server: la pagina arriva già renderizzata e l'utente la usa subito.

In parallelo, senza bloccare niente, il browser scarica il runtime WebAssembly e le DLL.

Quando il download è finito, in pochi secondi su connessioni veloci, o già pronto alle visite successive grazie alla cache, i componenti passano da soli alla modalità WASM.

Da lì in poi, e per tutte le sessioni successive, l'applicazione gira interamente in locale, senza dipendere dal server per il rendering.

Cosa cambia in pratica

Il primo caricamento è immediato come in Blazor Server: niente attesa per il bundle WebAssembly, niente spinner (l'indicatore di caricamento animato, la rotellina che gira) iniziale che fa scappare l'utente.

Dalle visite successive le interazioni sono rapide quanto in un'app WASM pura, tutte dentro il browser.

E soprattutto, il server non deve più tenere un circuito attivo per ogni utente connesso, il che fa sparire gran parte del problema di scala della sezione precedente.

I vincoli da considerare

Il vincolo più grosso, quello che sorprende in fase di sviluppo, è che i componenti devono funzionare in entrambe le modalità.

I servizi che dipendono dal browser (localStorage, geolocalizzazione, Web Crypto API) non ci sono quando il componente gira lato Server.

E vale al contrario: accesso diretto al database, file system, segreti di configurazione non esistono quando il componente gira in WASM nel browser.

La soluzione pratica è astrarre queste risorse dietro un'interfaccia comune, condivisa da tutto il progetto, con due implementazioni distinte iniettate in base all'ambiente.

Una parla con il browser quando c'è, l'altra usa una tabella nel database quando il componente gira sul server.

Il componente Razor lavora sempre contro l'interfaccia, e ignora quale implementazione sia attiva in quel momento.

Richiede più cura nella progettazione dei servizi fin dal primo giorno, ma ti evita di riscrivere mezza applicazione quando salta fuori il primo servizio incompatibile.

Anche l'infrastruttura è più complessa di quella di una singola modalità.

Ti servono sia la logica Server per la prima visita, con tutta la gestione dei circuiti, sia la distribuzione del bundle WASM per le visite successive, con il relativo hosting delle risorse statiche.

In .NET 9 la modalità Auto è stata affinata, con miglioramenti al caching delle risorse WASM e alla fluidità del passaggio tra le due modalità.

Sono spariti i casi limite che nelle prime versioni di .NET 8 causavano piccoli scatti visibili durante la transizione da Server a WASM.

Oggi è la scelta più bilanciata per le applicazioni pubbliche che vogliono sia HTML pre-renderizzato per la SEO sia piena autonomia client-side per le sessioni successive.

È il default che consiglio quando non ci sono vincoli specifici che spingono verso WASM o Server puri.

Per un confronto più ampio sulle scelte di stack web in .NET, vedi l'articolo su ASP.NET Core e gli altri framework web.

SEO e Blazor WebAssembly: il problema reale e come risolverlo

Il problema SEO di Blazor WebAssembly non è un bug da correggere.

È una conseguenza diretta dell'architettura client-side.

Google usa un crawler basato su Chromium che sa eseguire JavaScript e aspettare il rendering di una SPA.

Sul campo, però, emergono tre problemi concreti, e si presentano sempre mesi dopo il lancio.

Problema 1: il rendering ritardato

Il crawler (è il programma automatico che i motori di ricerca usano per esplorare il web) arriva sulla pagina e trova un HTML quasi vuoto, con uno spinner di caricamento.

Deve aspettare che il runtime .NET si carichi ed esegua il rendering.

Google dichiara di aspettare le SPA, ma l'attesa è limitata e non garantita: oltre i 5-6 secondi, il crawler indicizza la pagina vuota o la salta del tutto.

In Google Search Console lo vedi così: pagine indicizzate senza titolo né descrizione, snippet (l'anteprima di una pagina che compare nei risultati di ricerca) vuoti che nessuno nota finché il traffico organico smette di arrivare.

Problema 2: il budget di crawl

Ogni sito viene esplorato con un budget limitato, proporzionale all'autorità del dominio, e le pagine pesanti da renderizzare consumano più budget per ogni URL.

Un sito con centinaia di pagine in Blazor WASM puro viene indicizzato in modo incompleto: le pagine meno importanti vengono saltate, quelle nuove impiegano settimane a comparire nell'indice.

E il marketing si chiede perché i contenuti pubblicati non portino traffico nemmeno dopo mesi.

Problema 3: i meta tag dinamici per la condivisione social

I meta tag Open Graph per la condivisione su LinkedIn, Facebook e simili vengono spesso inseriti da Blazor dopo il caricamento.

Ma i crawler social non eseguono JavaScript: vedono solo l'HTML statico dell'index.html, con meta tag generici o vuoti.

Risultato: ogni pagina condivisa mostra la stessa anteprima, qualunque sia il contenuto.

Sembra un dettaglio cosmetico, finché non ti accorgi che i click dai social sono vicini allo zero.

Le soluzioni concrete

La soluzione più solida è far preparare la pagina al server, invece di lasciare tutto il lavoro al browser.

In Blazor significa usare la modalità Auto, o il rendering statico per le pagine pubbliche.

La differenza la vedi da solo, in trenta secondi.

Apri la pagina, click destro, "Visualizza sorgente".

Con WASM puro trovi un guscio vuoto: c'è solo la rotellina di caricamento, il contenuto non esiste ancora.

Con la pagina preparata dal server trovi l'articolo intero, già scritto.

Google riceve esattamente quello che leggi lì: nel primo caso indicizza il vuoto, nel secondo trova tutto al primo colpo.

Poi non fidarti della teoria: controlla.

Google Search Console ha uno strumento, URL Inspection, che ti mostra la pagina così come Google l'ha vista davvero.

Due minuti, e sai se il problema è risolto oppure no.

E se il progetto deve restare in Blazor WASM puro, perché la scelta è già fatta e l'investimento pure? Allora dividi il sito in due.

Davanti, le pagine che devono farsi trovare su Google: blog, schede prodotto, landing.

Quelle le fai con pagine normali, che Google legge senza sforzo.

Dietro il login, dove Google tanto non entra, vive l'applicazione vera in WASM.

Le due parti si scambiano i dati e convivono benissimo, ognuna ottimizzata per il suo scopo.

C'è poi un problema gemello, che salta fuori solo quando qualcuno analizza il sito per bene.

Hai presente le stelline delle recensioni sotto un risultato Google, il prezzo del prodotto, le domande frequenti che si aprono direttamente nella ricerca?

Nascono da poche righe di informazioni nascoste nella pagina, che Google legge e trasforma in quei riquadri.

In un'app WASM pura quelle righe compaiono solo dopo il caricamento, quando Google è già passato oltre: e le stelline non arrivano mai.

Con la pagina preparata dal server escono insieme a tutto il resto, e Google le trova sempre.

Il problema SEO di Blazor si risolve, ma solo se sai dove mettere le mani prima di scrivere la prima riga di codice.

È la differenza tra chi impara Blazor dai tutorial e chi lo impara in modo strutturato: il corso Blazor parte proprio dall'architettura delle modalità di rendering, così il traffico organico lo porti a casa dal primo rilascio, non dopo la riscrittura.

Performance di Blazor in produzione: download iniziale, TTI e ottimizzazione

La performance di Blazor in produzione si misura su tre cose: il peso del bundle iniziale, il Time to Interactive (TTI) e la velocità a regime, dopo il primo caricamento.

Peso del bundle iniziale in Blazor WASM

Una build di produzione Blazor WASM, ottimizzata con trimming e compressione Brotli, parte da circa 1,5-2 MB per un'applicazione semplice.

Con dipendenze importanti, librerie di componenti UI, crittografia, serializzazione complessa, sali a 5-8 MB.

Dopo il primo download le DLL restano in cache e le visite successive volano, ma il primo accesso costa sempre, e ogni aggiornamento dell'app invalida la cache.

Da .NET 8, le DLL vengono impacchettate nel formato webcil, un contenitore che evita l'estensione .dll grezza nel traffico HTTP.

Certi firewall aziendali e antivirus datati bloccavano le DLL Blazor scambiandole per eseguibili sospetti; webcil toglie l'attrito senza che tu debba fare nulla.

Per confronto: una build di produzione React ottimizzata parte da 100-300 KB per la maggior parte delle applicazioni.

Il divario è strutturale: Blazor WASM porta un runtime .NET completo nel browser, React no.

Time to Interactive su connessioni reali

I tempi misurati su connessioni tipiche raccontano il problema meglio di qualsiasi discorso:

Sul 3G, a quei tempi, la maggior parte degli utenti se n'è già andata.

E il TTI basso di Blazor Server si paga con la WebSocket permanente per ogni utente, vista nella sezione precedente:

Strategie di ottimizzazione del bundle

Il trimming con compilazione AOT (Ahead of Time) in .NET 9 riduce il runtime includendo solo il codice davvero usato, e compila il codice .NET in WebAssembly nativo prima del rilascio.

Le performance a runtime migliorano, perché non c'è JIT nel browser, ma il peso del bundle iniziale può crescere un po', perché il codice nativo WASM si comprime meno bene delle DLL.

Valutalo caso per caso: non è un miglioramento gratuito.

Il lazy loading dei moduli carica parti dell'applicazione solo quando servono.

Su app con tante funzionalità separate taglia il download iniziale del 40-60%: quello che si usa di rado si scarica solo al momento del bisogno.

La compressione Brotli, sul server o sul CDN, riduce il peso di trasferimento rispetto a gzip.

E le risorse statiche (DLL, runtime) vogliono un header Cache-Control con max-age lungo, per non riscaricarle a ogni visita.

Per le interfacce con elenchi lunghi, il componente Virtualize renderizza solo gli elementi visibili nel viewport, non l'intera lista.

Vale sia in WASM sia in Server, e spesso si sente più di qualsiasi ottimizzazione del bundle.

Da .NET 8, anche le pagine in Static SSR possono comportarsi come una SPA nella navigazione e nell'invio dei form, grazie alla navigazione avanzata (enhanced navigation) e alla gestione avanzata dei form.

Il framework intercetta link e submission, aggiorna solo la porzione di pagina cambiata senza un refresh completo, e lo fa senza scaricare un solo byte di runtime WebAssembly.

Per molte applicazioni pubbliche, HTML statico più navigazione avanzata copre l'esperienza che prima richiedeva WASM o Server, senza il peso né la complessità di nessuno dei due.

Misurare invece di indovinare

Ogni numero di questa sezione cambia con il progetto reale, quindi la regola è una: misura prima di ottimizzare.

Chrome DevTools con il pannello Lighthouse, in modalità 4G simulata, dà una stima realistica del TTI percepito da un utente medio.

Per il bundle WASM, il report di dimensione di dotnet publish -c Release ti dice quali assembly pesano di più, e lì scopri dipendenze che nessuno ricordava di aver aggiunto.

Performance a regime

Una volta caricato, Blazor WASM è velocissimo nelle operazioni che restano nel browser.

Blazor Server, invece, introduce una latenza fissa per ogni interazione, pari al viaggio WebSocket fino al server: tipicamente 10-50 ms su connessioni locali, 50-200 ms su connessioni lontane.

Con la digitazione in tempo reale o il drag and drop, l'interfaccia risulta percettibilmente meno reattiva rispetto a WASM.

Provalo con utenti veri prima di liquidarlo come trascurabile.

Autenticazione e sicurezza in Blazor: dove vive davvero la protezione

L'autenticazione in Blazor ha alcune peculiarità che spiazzano chi finora ha lavorato solo con l'approccio tradizionale del framework, soprattutto in modalità WebAssembly.

La regola fondamentale è una: in Blazor WASM tutto il codice client è esposto all'utente, e nessun segreto può restare nascosto in ciò che gira nel browser.

La protezione reale avviene sempre e solo lato server, negli endpoint API che l'applicazione chiama.

Quegli endpoint devono validare il token a ogni richiesta, indipendentemente da quello che il client afferma di essere.

Vuol dire che il decoratore [Authorize] su un componente Blazor WASM è solo esperienza utente, non sicurezza: nasconde o mostra elementi dell'interfaccia in base allo stato di autenticazione dichiarato dal client.

Bastano qualche minuto e gli strumenti di sviluppo del browser per aggirare qualsiasi controllo del genere.

Flusso JWT tipico in Blazor WASM

Il giro completo del token si riassume in quattro passaggi:

• L'utente accede da un form di login che chiama un endpoint ASP.NET Core.
• Il server valida le credenziali e restituisce un JWT.
• Il client salva il token e lo mette nell'header Authorization di ogni chiamata successiva alle API.
• Il server rivalida il token a ogni chiamata, qualunque cosa mostri l'interfaccia.

LocalStorage vs cookie HttpOnly

Salvare il JWT in localStorage è comodo e diffuso, ma espone il token ad attacchi XSS.

Se un attaccante inietta JavaScript malevolo nella pagina, legge il token da localStorage e lo usa per chiamate API non autorizzate dall'esterno, anche molto tempo dopo.

La strada più sicura sono i cookie HttpOnly gestiti lato server: JavaScript non li può leggere, nemmeno con un XSS riuscito.

Paghi un po' di complessità in più nel backend e porti a casa un profilo di sicurezza nettamente migliore.

Per qualsiasi applicazione con dati sensibili, accetta lo scambio.

Blazor Server e Identity

In Blazor Server l'autenticazione somiglia di più ad ASP.NET Core classico: il server mantiene la sessione, l'utente si autentica con cookie, e ogni componente accede all'identità tramite AuthenticationStateProvider.

I segreti restano sul server, un vantaggio strutturale rispetto a WASM che elimina intere categorie di rischio in partenza.

Per le applicazioni enterprise, l'integrazione con Entra ID, Identity Server o altri provider OIDC è la scelta standard.

I template di .NET 8 includono già uno scaffolding pronto per ASP.NET Core Identity con Blazor, che funziona bene sia in modalità Server sia in Auto con pre-rendering.

Occhio anche agli antiforgery token nei form: i template recenti li gestiscono in automatico, ma verificane la presenza in ogni form che scrive dati.

Vale in particolare per i progetti migrati da versioni precedenti di .NET, dove lo scaffolding non era ancora aggiornato.

Quando l'API vive su un dominio diverso

Scenario comune e sottovalutato: il frontend Blazor WASM servito da un dominio diverso dalle API che consuma, per esempio app.azienda.it contro api.azienda.it.

Qui i cookie HttpOnly chiedono attenzione in più: gli attributi SameSite e Secure vanno configurati in modo esplicito per far viaggiare il cookie nelle richieste cross-origin.

E la policy CORS lato server deve dichiarare l'origine esatta del frontend, senza wildcard che vanificherebbero la protezione appena costruita.

È il classico punto dove "funziona in locale" smette di funzionare al primo rilascio su ambienti separati: verificalo prima del go-live, non scoprirlo insieme al cliente.

Gli errori di sicurezza non perdonano: non li scopri in una revisione del codice, li scopri quando qualcuno li ha già sfruttati.

Nel corso Blazor autenticazione, token e messa in produzione si affrontano come le affronterai in azienda: su un progetto reale, con feedback su quello che scrivi.

Prima del go-live, non insieme al cliente.

Blazor vs React e Angular: quando conviene davvero scegliere Blazor

Il confronto con i framework JavaScript viene raccontato come una gara tra linguaggi, C# contro JavaScript o TypeScript.

È una semplificazione che porta a scelte sbagliate.

La domanda giusta non è "quale linguaggio preferisco", ma "quale framework risolve meglio i problemi di questo progetto, in questo team, in questo contesto".

Dove Blazor ha vantaggi reali

Un team con competenze .NET solide e poca esperienza frontend ci guadagna più di quanto sembri.

Imparare React o Angular non significa imparare solo il framework: ti porti dietro tutto l'ecosistema JavaScript, npm, bundler, TypeScript, Jest, librerie di gestione dello stato.

Per un team .NET che costruisce un'interfaccia interna, Blazor arriva in produzione molto prima, perché si salta l'intero secondo apprendistato.

Le applicazioni con logica di business complessa da condividere tra frontend e backend sono un altro caso chiaro.

Con Blazor WASM condividi classi di dominio, validatori e regole di business tra client e server nello stesso progetto: niente duplicazione, niente implementazioni che divergono nel tempo.

Terzo scenario, ricorrente nel mercato italiano: modernizzare applicazioni desktop WPF o Windows Forms verso il web, tenendo il team esistente.

Blazor è la via naturale: stessa logica, stesso linguaggio, stesso team.

Ed è il ponte più diretto verso Blazor Hybrid, che riusa gli stessi componenti Razor in un'app MAUI desktop o mobile.

Dove React e Angular vincono

Le applicazioni pubbliche con requisiti SEO stringenti, dove Time to First Byte e First Contentful Paint sono KPI misurati e monitorati, restano terreno di React e Angular.

React con Next.js o Angular con SSR hanno una maturità di rendering lato server molto superiore a Blazor WASM, con ecosistemi di ottimizzazione più ampi e collaudati su scala molto più grande.

Un team con competenze JavaScript o TypeScript solide ha poco da guadagnare cambiando stack.

Il costo di imparare Blazor per un frontend JavaScript è simmetrico a quello di imparare React per un team .NET: reale, non banale, e raramente sensato senza una ragione di business precisa.

Anche l'ecosistema di componenti pesa nella stessa direzione: npm ha un ordine di grandezza in più di librerie rispetto a NuGet per il frontend.

Grafici, mappe, editor rich text e componenti specializzati, in Blazor spesso li costruisci da zero o li adatti da librerie meno mature.

E poi c'è il mercato, che nelle discussioni tecniche nessuno guarda: in Italia trovi sviluppatori React o Angular esperti molto più facilmente di sviluppatori Blazor senior.

Il motivo è semplice, l'ecosistema JavaScript ha da anni una base di professionisti più ampia.

Se devi assumere e far crescere un team frontend in fretta, questo pesa quanto l'architettura: mettilo sul piatto insieme a SEO, performance e competenze già in casa.

La regola pratica

Il criterio di scelta, ridotto all'osso, sta in tre righe:

È la combinazione più sensata quando servono entrambe le cose.

Per un confronto approfondito tra Blazor e React nella scelta di stack, vedi l'articolo Blazor vs React.

E se stai costruendo il tuo percorso come sviluppatore web .NET e vuoi capire dove mettere Blazor nella roadmap, vedi come diventare sviluppatore web con .NET nel 2026.

Blazor in produzione: la checklist prima del go-live

Prima di portare un'applicazione Blazor in produzione, c'è una serie di controlli che separa un rilascio tranquillo da una settimana di interventi d'urgenza.

Negli anni ho seguito decine di go-live Blazor, e ho visto gli stessi errori ripetersi con una regolarità impressionante.

Sempre quelli: la modalità di rendering scelta per abitudine, il bundle mai misurato su una build di produzione, il token validato solo dall'interfaccia, il primo restart del server che butta giù le sessioni di tutti.

Così ho condensato tutto in una checklist operativa, quella che uso io stesso prima di ogni rilascio.

Copre le cinque aree dove si concentrano quasi tutti i problemi delle prime settimane:

• La modalità di rendering: l'hai scelta in base ai requisiti reali o per preferenza di linguaggio?
• La SEO: hai verificato con URL Inspection cosa vede davvero Google?
• Le performance: hai misurato il TTI su una 4G simulata?
• La sicurezza: gli endpoint validano il token indipendentemente dall'interfaccia?
• L'infrastruttura: cosa succede alle sessioni attive al primo restart in produzione?

Ogni domanda della checklist esiste perché qualcuno, da qualche parte, ha passato un weekend a rispondere nel modo peggiore: in emergenza.

La checklist da sola però non basta, perché ogni progetto ha i suoi vincoli: il traffico atteso, il team, l'infrastruttura che hai già.

È il motivo per cui non la distribuisco come PDF da scaricare: senza sapere come applicarla al tuo progetto, la liquideresti come l'ennesima lista inutile trovata in rete.

Il percorso per padroneggiare Blazor in modo professionale

Blazor è una tecnologia matura, con investimenti continui di Microsoft a ogni release di .NET.

In .NET 9 la modalità Auto è stabile, le performance AOT sono migliorate, e il modello ibrido con Static SSR e interattività selettiva copre la grande maggioranza dei casi reali che un team incontra in produzione.

Il problema non è la tecnologia.

È che la documentazione ufficiale spiega bene il singolo concetto, ma non ti dice quando usare quale modalità, quali compromessi accettare, quali errori evitare prima del rilascio invece che a rilascio avvenuto.

La differenza tra un senior .NET che sa scegliere la modalità Blazor giusta per ogni contesto e chi sceglie per sentito dire si vede tutta in produzione.

La leggi nel traffico organico, nei tempi di caricamento, nelle chiamate al supporto tecnico.

Se ti chiedi se valga la pena investire nel percorso C# e ASP.NET Core per usare Blazor da professionista, leggi anche corso C# o autodidatta: cosa conviene davvero nel 2026.

E se vuoi un percorso strutturato che copra Blazor, ASP.NET Core e l'intero stack .NET con progetti reali e feedback su quello che costruisci, il nostro corso è pensato esattamente per questo.

Arrivato qui, hai due strade davanti a te.

La prima: chiudi la pagina e torni al progetto.

Continuerai a scegliere le modalità di rendering per sentito dire, a scoprire i problemi SEO sei mesi dopo il rilascio, a pagare la formazione nel modo più caro che esiste: con i weekend d'emergenza, le riscritture e le telefonate dei clienti.

La seconda: decidi che la prossima scelta architetturale la prendi sapendo esattamente quello che stai facendo.

Chiariamoci: il corso Blazor non è per tutti.

Non è per chi colleziona tutorial e non porta a termine niente.

Non è per chi cerca un certificato da appendere su LinkedIn.

E non è per chi ripete che "tanto ormai il codice lo scrive l'AI": il codice magari sì, ma le scelte che contano tra WASM, Server e Auto le fai tu.

E in produzione ci va la tua firma, non quella del modello.

È per chi vuole essere quello che in riunione dice "questa modalità no, e vi spiego perché", mentre tutti gli altri annuiscono alla proposta sbagliata.

Se ti riconosci nella seconda categoria, il corso Blazor ti dà quello che un articolo può solo indicarti: l'architettura affrontata su progetti reali, con feedback su quello che costruisci, finché scegliere bene non diventa un riflesso.

Questo articolo lo hai letto gratis.

Gli errori in produzione li paghi a prezzo pieno.

Scegli cosa preferisci.