Cosa sono i componenti del server React e perché la logica sta tornando al server

Per più di un decennio, la regola di React è stata semplice: tutto avviene nel browser. Il server ha consegnato un file HTML quasi vuoto, il browser ha scaricato un grosso pacchetto JavaScript, ha eseguito questo codice e solo allora è apparsa effettivamente l'interfaccia. Ha funzionato, ma ha avuto un costo crescente.

Questo costo è ciò che i componenti React Server vengono riaddebitati. L'idea centrale è semplice: non tutti i componenti devono essere eseguiti nel browser dell'utente. Gran parte della sua interfaccia cerca solo dati, formatta testo e crea strutture. Questo tipo di lavoro può avvenire sul server, prima di raggiungere il client.

Non è un dettaglio implementativo. Si tratta di un cambiamento nel luogo in cui risiede la tua applicazione e influisce direttamente sulla velocità, sui costi di manutenzione e sull'esperienza di chi utilizza il prodotto.

Il problema che nessuno voleva ammettere

La tradizionale applicazione React, nota come SPA, scarica praticamente tutta la responsabilità sul browser. L'utente apre la pagina, riceve uno scheletro vuoto, attende il download di JavaScript, attende l'esecuzione e solo allora vede il contenuto utile.

Con una buona connessione e un cellulare potente questo passa quasi inosservato. Su un dispositivo medio su una rete instabile, si trasforma in uno schermo bianco che impiega molto tempo. E la maggior parte del pubblico reale è più vicino al secondo scenario che al primo.

La parte peggiore è che questo pacchetto JavaScript non fa che crescere. Ogni libreria di formattazione della data, ogni client API, ogni utilità rientra nel pacchetto che il browser deve scaricare. Gran parte di questo codice non avrebbe mai bisogno di essere lì, perché la sua unica funzione è preparare i dati che potrebbero arrivare già pronti.

I componenti server attaccano esattamente questi rifiuti. Ti consentono di spostare il codice che non ha motivo di vivere sul client sul server.

Server e client: la differenza che conta

La distinzione più importante da comprendere è tra due tipi di componenti. Il componente server viene eseguito solo sul server. Cerca i dati, assembla la struttura e produce un risultato che viene inviato pronto al browser. Il suo codice non è incluso, quindi non incide sul pacchetto scaricato dall'utente.

Il componente client è il React che già conosci. Funziona nel browser, ha uno stato, risponde ai clic, controlla i moduli e gestisce qualsiasi cosa interattiva. Per contrassegnare un componente come lato client, utilizzare la direttiva "use client" nella parte superiore del file.

La regola pratica è quasi intuitiva. Se il componente visualizza solo informazioni, potrebbe essere lato server. Se deve reagire all'utente, salvare lo stato o utilizzare le risorse del browser, deve essere lato client.

Il dettaglio elegante è che i due vivono sullo stesso albero. Un componente server può eseguire il rendering di un componente client al suo interno. Non si sceglie da che parte stare in modo definitivo, si compone l'interfaccia mescolando le due in base alle reali esigenze di ogni pezzo.

Il guadagno concreto per l'utente

Il primo vantaggio è la ricerca dei dati. In un componente server, interroghi il database o chiami direttamente un'API, senza bisogno di un livello intermedio solo affinché il browser possa comunicare con il backend. I dati vengono recuperati vicino alla fonte, con bassa latenza per coloro che si trovano all'interno dell'infrastruttura.

Il secondo vantaggio è la dimensione di ciò che raggiunge il cliente. Poiché il codice per i componenti server non viene fornito, il bundle JavaScript si riduce. Meno codice da scaricare, meno codice da elaborare per il browser, meno tempo necessario affinché la pagina sia utilizzabile. Negli apparecchi modesti questa differenza si avverte sulla pelle.

Il terzo guadagno è il caricamento iniziale. L'utente riceve contenuti già renderizzati, con testo e struttura visibili quasi immediatamente, anziché una tela bianca in attesa che JavaScript si attivi. La percezione della velocità cambia e la percezione è ciò che definisce se qualcuno resta o se ne va.

C'è anche un vantaggio che spesso viene trascurato: i segreti rimangono sul server. Le chiavi API, la logica aziendale sensibile e le regole che non desideri vengano esposte rimangono all'esterno del browser perché non vengono mai inviate lì. Se stai mettendo insieme il quadro più ampio, vale la pena leggere sviluppo web nel 2026 per vedere dove si inserisce questo.

E la questione dell'idratazione

Vale la pena comprendere un concetto che ricorre spesso in questa conversazione: l’idratazione. Quando un componente client arriva nel browser già renderizzato dal server, React deve allegare gli eventi e lo stato a quell'HTML esistente, affinché diventi interattivo. Questo processo di dare vita all'HTML statico è l'idratazione.

Il problema con le applicazioni tradizionali è che idratano tutto, comprese le parti che non reagirebbero mai all’utente. Ciò consumava inutilmente elaborazione sul dispositivo di chi voleva solo leggere.

Con i componenti server, idrati solo ciò che deve essere interattivo. I pezzi puramente informativi arrivano già pronti e restano silenziosi, senza sprecare il processore del cellulare. Meno idratazione significa meno lavoro sul dispositivo e un'interfaccia più reattiva.

Perché questa non è solo moda

È giusto diffidare di qualsiasi novità nell'ecosistema React, che cambia frequentemente i paradigmi. Ma i componenti server non sono un framework attuale. Rispondono alla pressione che si è accumulata: applicazioni troppo grandi per essere gestite con garbo dal browser.

Inviare tutto al cliente è stata una semplificazione utile mentre le richieste erano piccole. Quando crebbero, il modello cominciò a costare molto in termini di prestazioni e complessità di soluzioni alternative per superare il peso del pacchetto.

Restituire parte della logica al server non è nostalgia dell'era PHP. È riconoscere che ogni tipo di lavoro ha il posto giusto in cui svolgersi e che insistere nel fare tutto nel browser è stata una scelta, non una legge. Server Components restituisce questa scelta al team, con strumenti moderni per esercitarla.

Se guidi un team o decidi l’architettura, il punto non è adottare la tecnologia perché è nuova. È comprendere che il confine tra server e client è ancora una volta una decisione consapevole, e che ignorarlo costa prestazioni che l'utente percepisce.