diff --git a/documentation/it/guides/getting-started.md b/documentation/it/guides/getting-started.md
new file mode 100644
index 000000000..c0402cfe0
--- /dev/null
+++ b/documentation/it/guides/getting-started.md
@@ -0,0 +1,112 @@
+# Iniziare
+
+## Prova Solid
+
+Il modo migliore per imparare Solid è provarlo online. Il nostro REPL su https://playground.solidjs.com è il modo perfetto per sperimentare i concetti fondamentali. Così come https://codesandbox.io/ dove puoi modificare uno qualsiasi dei nostri esempi.
+
+In alternativa, puoi utilizzare i nostri semplici modelli [Vite](https://vitejs.dev/) eseguendo questi comandi nel tuo terminale:
+
+```sh
+> npx degit solidjs/templates/js my-app
+> cd mia-app
+> npm i # o yarn o pnpm
+> npm run dev # o yarn o pnpm
+```
+
+O per TypeScript:
+
+```sh
+> npx degit solidjs/templates/ts my-app
+> cd mia-app
+> npm i # o yarn o pnpm
+> npm run dev # o fyarn o pnpm
+```
+
+## Impara Solid
+
+Il Solid è composto da piccoli pezzi componibili che fungono da elementi costitutivi nelle applicazioni. Questi pezzi sono per lo più funzioni che costituiscono molte API superficiali di alto livello. Fortunatamente, non avrai bisogno di conoscerne la maggior parte per iniziare con la libreria.
+
+I due principali tipi di blocchi a tua disposizione sono i componenti e le primitive reattive.
+
+I componenti sono funzioni che accettano un oggetto di props e restituiscono elementi JSX inclusi elementi DOM nativi e altri componenti. Possono essere espressi come elementi JSX in PascalCase:
+
+```jsx
+function MyComponent(props) {
+ return
Ciao {props.name}
;
+}
+
+;
+```
+
+I componenti sono leggeri. Non sono stateful di per sé e non hanno istanze. Servono invece come funzioni di fabbrica per gli elementi DOM e le primitive reattive.
+
+La reattività a grana fine è costruita su 3 semplici primitive: Segnali, Memo ed Effetti. Insieme, formano un motore di sincronizzazione con tracciamento automatico che garantisce che la tua vista rimanga aggiornata. I calcoli reattivi assumono la forma di semplici espressioni con wrapping di funzioni che vengono eseguite in modo sincrono.
+
+```js
+const [first, setFirst] = createSignal("JSON");
+const [last, setLast] = createSignal("Bourne");
+
+createEffect(() => console.log(`${first()} ${last()}`));
+```
+
+Puoi saperne di più su [Reattività di Solid](https://www.solidjs.com/docs/latest#reactivity) e [Rendering di Solid](https://www.solidjs.com/docs/latest#rendering).
+
+## Pensa in modo Solid
+
+Il design di Solid contiene diverse opinioni su quali principi e valori ci aiutano a costruire al meglio siti Web e applicazioni. È più facile imparare e utilizzare Solid quando si è consapevoli della filosofia alla base.
+
+### 1. Dati dichiarativi
+
+Declarative data combines the description of data’s behavior to its declaration. This allows for easy composition by packaging all aspects of data’s behavior in a single place.
+
+### 2. Componenti a scomparsa
+
+È piuttosto difficile strutturare i componenti senza prendere in considerazione gli aggiornamenti. Gli aggiornamenti Solid sono completamente indipendenti dai componenti. Le funzioni componenti vengono chiamate una volta e poi cessano di esistere. Esistono componenti per organizzare il tuo codice e non molto altro.
+
+### 3. Lettura/scrittura
+
+Precise control and predictability make for better systems. We don't need true immutability to enforce unidirectional flow, only the ability to make the conscious decision which consumers may write and which may not.
+
+### 4. Semplice è meglio che facile
+
+Ecco una lezione che viene dalla reattività a grana fine. Vale la pena avere convenzioni esplicite e coerenti anche se richiedono uno sforzo maggiore. Lo scopo è fornire strumenti minimi che servano come base su cui costruire.
+
+## Web Components
+
+Solid nasce con il desiderio di avere Web Components come cittadini di prima classe. Nel tempo il suo design si è evoluto e gli obiettivi sono cambiati. Tuttavia, Solid è ancora un ottimo modo per creare Web Components. [Solid Element](https://github.com/solidjs/solid/tree/main/packages/solid-element) consente di scrivere e avvolgere i componenti funzione di Solid per produrre componenti Web piccoli e performanti. All'interno delle app Solid Solid Element è ancora in grado di sfruttare l'API di contesto di Solid e Solid Portals supportano lo stile isolato Shadow DOM.
+
+## Rendering del server
+
+Solid ha una soluzione di rendering lato server dinamico che fornisce un'esperienza di sviluppo veramente isomorfa. Attraverso l'uso della nostra primitiva Resource, le richieste di dati asincroni vengono facilmente effettuate e automaticamente serializzate e sincronizzate tra client e browser.
+
+Poiché Solid supporta il rendering asincrono e in streaming sul server, puoi scrivere il tuo codice in un modo e farlo eseguire sul server. Ciò significa che funzionalità come [render-as-you-fetch](https://reactjs.org/docs/concurrent-mode-suspense.html#approach-3-render-as-you-fetch-using-suspense) e code splitting funzionano solo in Solid.
+
+Per maggiori informazioni, leggi la [Guida al server](https://www.solidjs.com/docs/latest#server-side-rendering).
+
+## Nessuna compilazione?
+
+Non ti piace JSX? Non ti dispiace fare il lavoro manuale per avvolgere le espressioni, prestazioni peggiori e avere pacchetti di dimensioni maggiori? In alternativa, puoi creare un'app Solid usando Tagged Template Literals o HyperScript in ambienti non compilati.
+
+Puoi eseguirli direttamente dal browser utilizzando [Skypack](https://www.skypack.dev/):
+
+```html
+
+
+
+
+
+```
+
+Ricorda che hai ancora bisogno della corrispondente libreria di espressioni DOM affinché funzionino con TypeScript. È possibile utilizzare i valori letterali dei modelli con tag con le espressioni Lit DOM o HyperScript con le espressioni Hyper DOM.
diff --git a/documentation/it/guides/reactivity.md b/documentation/it/guides/reactivity.md
new file mode 100644
index 000000000..65bd18709
--- /dev/null
+++ b/documentation/it/guides/reactivity.md
@@ -0,0 +1,95 @@
+# Reattività
+
+La gestione dei dati in Solid utilizza primitive reattive che sono responsabili di tutti gli aggiornamenti. Utilizza un approccio molto simile a MobX o Vue, tranne per il fatto che non scambia mai la sua granularità con un VDOM. Le dipendenze vengono tracciate automaticamente quando accedi ai tuoi valori reattivi in Effetti e codice JSX.
+
+Le primitive di Solid sono chiamate `create` che spesso restituiscono tuple. Generalmente il primo elemento è una primitiva leggibile e il secondo è un setter. È comune riferirsi solo alla parte leggibile con il nome primitivo.
+
+Ecco un contatore di incremento automatico di base che si aggiorna in base all'impostazione del segnale `count`.
+
+```jsx
+import { createSignal, onCleanup } from "solid-js";
+import { render } from "solid-js/web";
+
+const App = () => {
+ const [counteggio, setCounteggio] = createSignal(0),
+ timer = setInterval(() => setCounteggio(counteggio() + 1), 1000);
+ onCleanup(() => clearInterval(timer));
+
+ return
{counteggio()}
;
+};
+
+render(() => , document.getElementById("app"));
+```
+
+## Presentazione dei primitivi
+
+Solid è costituito da 3 primitive primarie, Segnale, Memo ed Effetto. Al centro c'è il pattern Observer in cui i segnali (e i promemoria) vengono tracciati avvolgendo i promemoria e gli effetti.
+
+I segnali sono la primitiva più semplice. Contengono valore e ottengono e impostano funzioni in modo da poter intercettare quando vengono letti e scritti.
+
+```js
+const [counteggio, setCounteggio] = createSignal(0);
+```
+
+Gli effetti sono funzioni che forniscono letture del nostro segnale. Viene eseguito nuovamente ogni volta che il valore di un segnale dipendente cambia. Questo è utile per creare effetti collaterali, come il rendering.
+
+```js
+createEffect(() => console.log("L'ultimo conteggio è ", counteggio()));
+```
+
+Infine, i Memo sono valori derivati memorizzati nella cache. Condividono le proprietà di entrambi i segnali e gli effetti. Tracciano i propri segnali dipendenti, rieseguendoli solo quando questi cambiano e sono essi stessi segnali tracciabili.
+
+```js
+const nome = createMemo(() => `${nomeBattsimo()} ${cognome()}`);
+```
+
+## Come funziona
+
+I segnali sono emettitori di eventi che contengono un elenco di abbonamenti. Notificano ai loro abbonati ogni volta che il loro valore cambia.
+
+Dove le cose si fanno più interessanti è come avvengono questi abbonamenti. Solid utilizza il monitoraggio automatico delle dipendenze. Gli aggiornamenti avvengono automaticamente quando i dati cambiano.
+
+Il trucco è uno stack globale in fase di esecuzione. Prima che un Effetto o Memo esegua (o riesegui) la sua funzione fornita dallo sviluppatore, si spinge su quello stack. Quindi qualsiasi segnale che viene letto controlla se c'è un listener corrente nello stack e in tal caso aggiunge il listener alle sue sottoscrizioni.
+
+Puoi pensarla così:
+
+```js
+function createSignal(value) {
+ const iscritti = new Set();
+
+ const leggere = () => {
+ const listener = getCurrentListener();
+ if (listener) iscritti.add(listener);
+ return valore;
+ };
+
+ const scrivi = nextValue => {
+ valore = valoreSuccessivo;
+ for (const isc of iscritti) isc.run();
+ };
+
+ return [read, scrivi];
+}
+```
+
+Ora ogni volta che aggiorniamo il segnale sappiamo quali effetti eseguire nuovamente. Semplice ma efficace. L'effettiva implementazione è molto più complicata, ma questo è il succo di ciò che sta accadendo.
+
+Per una comprensione più dettagliata di come funziona Reattività, questi sono articoli utili (in inglese):
+
+[A Hands-on Introduction to Fine-Grained Reactivity](https://dev.to/ryansolid/a-hands-on-introduction-to-fine-grained-reactivity-3ndf)
+
+[Building a Reactive Library from Scratch](https://dev.to/ryansolid/building-a-reactive-library-from-scratch-1i0p)
+
+[SolidJS: Reactivity to Rendering](https://indepth.dev/posts/1289/solidjs-reactivity-to-rendering)
+
+## Considerazioni
+
+Questo approccio alla reattività è molto potente e dinamico. Può gestire le dipendenze che cambiano al volo eseguendo diversi rami di codice condizionale. Funziona anche attraverso molti livelli di indiretto. Viene tracciata anche qualsiasi funzione eseguita all'interno di un ambito di tracciamento.
+
+Ci sono alcuni comportamenti chiave e compromessi di cui dobbiamo essere consapevoli.
+
+1. Tutta la reattività viene tracciata direttamente dalle chiamate di funzione. Possono anche essere nascosti sotto getter/proxy e attivati dall'accesso alla proprietà. Ciò significa che è importante dove si accede alle proprietà sugli oggetti reattivi.
+
+2. I componenti ei callback dai flussi di controllo non tengono traccia degli ambiti. Eseguono solo una volta. Ciò significa che la destrutturazione o l'esecuzione della logica di primo livello nei componenti non verrà rieseguita. È necessario accedere a questi segnali, negozi e oggetti di scena dall'interno di altre primitive reattive o JSX per quella parte del codice da rivalutare.
+
+3. Questo approccio tiene traccia solo in modo sincrono. Se hai un setTimeout o usi una funzione asincrona nel tuo effetto, verrà eseguito asincrono. Quindi non verrà più tracciato.
diff --git a/documentation/it/guides/rendering.md b/documentation/it/guides/rendering.md
new file mode 100644
index 000000000..7f8d1ac87
--- /dev/null
+++ b/documentation/it/guides/rendering.md
@@ -0,0 +1,277 @@
+# Rendering
+
+Solid supporta 3 tipi di template: JSX, Tagged Template Literals e la variante HyperScript di Solid. JSX è la forma predominante. Perché? JSX è un ottimo DSL creato per la compilazione. Ha una sintassi chiara, supporta TypeScript, funziona con Babel e supporta altri strumenti come l'evidenziazione della sintassi del codice e più carino. Era solo pragmatico usare uno strumento che fondamentalmente ti dà tutto gratuitamente. Come soluzione compilata fornisce un ottimo DX. Abbiamo scelto di non lottare con le sintassi DSL personalizzate e di usarne una ampiamente supportata.
+
+## Compilazione JSX
+
+Il rendering prevede la precompilazione di modelli JSX in codice js nativo ottimizzato. I costrutti del codice JSX sono:
+
+- Elementi template DOM (clonati su ogni istanza)
+- Una serie di dichiarazioni di riferimento che utilizzano solo firstChild e nextSibling
+- Calcoli a grana fine per aggiornare gli elementi creati.
+
+Questo approccio è più performante e produce meno codice rispetto alla creazione di ogni elemento individualmente con document.createElement.
+
+## Attributi e oggetti di scena
+
+Tentativi solidi di seguire il più possibile le convenzioni HTML, inclusa l'insensibilità alle maiuscole degli attributi.
+
+La maggior parte di tutti gli attributi sull'elemento nativo JSX sono impostati come attributi DOM. I valori statici sono incorporati direttamente nel modello clonato. Ci sono un certo numero di eccezioni come `class`, `style`, `value`, `innerHTML` che forniscono funzionalità extra.
+
+Gli elementi personalizzati (ad eccezione dei built-in nativi) sono predefiniti come proprietà quando sono dinamici. Questo serve per gestire tipi di dati più complessi. Esegue questa conversione in base ai nomi degli attributi dei casi di serpente standard dell'involucro del cammello da `some-attr` a `someAttr`.
+
+È anche possibile controllare questo comportamento direttamente con le direttive dello spazio dei nomi. Puoi forzare un attributo con `attr:` o `prop:`
+
+```jsx
+
+```
+
+> **Nota:** gli attributi statici vengono creati come parte del modello html che viene clonato. Le espressioni fisse e dinamiche vengono applicate successivamente nell'ordine di associazione JSX. Questo va bene per la maggior parte degli elementi DOM ma ce ne sono alcuni, come gli elementi di input con `type='range'`, dove l'ordine conta. Ricordalo quando leghi gli elementi.
+
+## Entrata
+
+Il modo più semplice per montare Solid è importare il rendering da 'solid-js/web'. `render` riceve una funzione come primo argomento e l'elemento di montaggio per il secondo. Restituirà un metodo di smaltimento. Questo `render` crea automaticamente la radice reattiva e gestisce il rendering nel contenitore di montaggio. Per prestazioni ottimali, utilizzare un elemento senza figli.
+
+```jsx
+import { render } from "solid-js/web";
+
+render(() => , document.getElementById("main"));
+```
+
+> **Importante** Il primo argomento deve essere una funzione. In caso contrario, non possiamo tracciare e programmare correttamente il sistema reattivo. Se lo fai in modo errato, i tuoi effetti non verranno eseguiti.
+
+## Componenti
+
+I componenti in Solid sono solo funzioni in maiuscolo Pascal. Il loro primo argomento è un oggetto props e restituiscono nodi DOM reali.
+
+```jsx
+const Primo = () => (
+
+
+
Davide
+
+
+);
+
+const Secondo = props => (
+ <>
+
{props.saluto}
+ {props.children}
+
+);
+```
+
+Tutti i nodi JSX sono nodi DOM effettivi. Non c'è magia qui. I componenti di primo livello li aggiungono al DOM stesso.
+
+## Oggetti di scena
+
+Solid consente di definire le proprietà sui componenti per passare i dati ai componenti figlio. Questo è simile a React, Vue, Angular e altri framework. Qui un componente genitore sta passando la stringa "Hello" al componente `Label` tramite una proprietà `greeting`.
+
+```jsx
+const Primo = () => (
+
+
+
David
+
+
+);
+```
+
+Il valore impostato su "saluto" è statico, ma possiamo anche impostare valori dinamici. Per esempio:
+
+```jsx
+const Primo = () => {
+ const [saluto, impostareSaluto] = createSignal("Buongiorno");
+ return (
+
+
+
Davide
+
+
+ );
+};
+```
+
+I componenti possono accedere alle proprietà passate loro tramite un argomento `props`.
+
+```jsx
+const Label = props => (
+ <>
+
{props.greeting}
+ {props.children}
+
+);
+```
+
+A differenza di altri framework, non è possibile utilizzare la destrutturazione degli oggetti sui `props` di un componente. Dietro le quinte l'oggetto `props` si basa su Object getter per recuperare pigramente i valori. L'uso della destrutturazione degli oggetti interrompe la reattività degli "sostegni". Questa è una limitazione naturale e accettabile.
+
+Questo esempio mostra il modo "corretto" di accedere agli oggetti di scena in Solid:
+
+```jsx
+// Qui, `props.name` si aggiornerà come ti aspetteresti
+const MioComponentene = props =>
{props.nome}
;
+```
+
+Questo esempio mostra il modo sbagliato di accedere agli oggetti di scena in Solid:
+
+```jsx
+// Questo è il male
+// Qui, `props.name` non si aggiornerà (cioè non è reattivo) poiché è destrutturato in `name`
+const MioComponentene = ({ nome }) =>
{nome}
;
+```
+
+Mentre l'oggetto props sembra un oggetto normale quando lo usi, in realtà è adeguatamente reattivo, in qualche modo simile a un segnale. Questo ha alcune implicazioni. Gli utenti dattiloscritti riconosceranno che è digitato come un normale oggetto.
+
+A differenza della maggior parte dei framework JSX, i componenti delle funzioni di Solid vengono eseguiti solo una volta (anziché ogni ciclo di rendering). L'esempio seguente non funzionerà come previsto.
+
+```jsx
+import { createSignal } from "solid-js";
+
+const ComponenteBase = props => {
+ const valore = props.value || "predefinita";
+ return
+ );
+}
+```
+
+In realtà vogliamo che il `ComponenteBase` mostri il valore corrente digitato nell'`input`. Come promemoria, la funzione `ComponenteBase` viene eseguita solo una volta quando il componente viene creato per la prima volta. A questo punto (durante la creazione), `props.valore` sarà uguale a `''`. Ciò significa che il "valore const" in "BasicComponent" si risolverà in "default" e non si aggiornerà mai. L'accesso agli oggetti di scena mentre l'oggetto `props` è reattivo è al di fuori dell'ambito osservabile di Solid. Quindi verrà automaticamente rivalutato quando cambiano gli oggetti di scena.
+
+Per risolvere il problema dobbiamo accedere a "props" da qualche parte in cui Solid possa osservarlo. Generalmente questo significa all'interno di JSX o all'interno di un `createMemo`, `createEffect` o thunk(`() => ...`). Ecco una soluzione che funziona come previsto:
+
+```jsx
+const ComponenteBase = props => {
+ return
{props.valore || "predefinita"}
;
+};
+```
+
+Questo, equivalentemente, può essere issato in una funzione:
+
+```jsx
+const ComponenteBase = props => {
+ const valore = () => props.valore || "predefinita";
+
+ return
{valore()}
;
+};
+```
+
+Un'altra opzione per calcoli costosi è usare `createMemo`. Per esempio:
+
+```jsx
+const ComponenteBase = props => {
+ const valore = createMemo(() => props.valore || "predefinita");
+
+ return
;
+};
+```
+
+I componenti di Solid sono la parte fondamentale delle sue prestazioni. L'approccio di Solid a far scomparire i componenti è reso possibile dalla valutazione pigra degli oggetti. A differenza della valutazione immediata delle espressioni prop e del passaggio di valori, l'esecuzione viene posticipata fino a quando non si accede al prop nel figlio. In questo modo rimandiamo l'esecuzione fino all'ultimo momento, in genere proprio nei binding DOM, massimizzando le prestazioni. Ciò appiattisce la gerarchia ed elimina la necessità di mantenere un albero di componenti.
+
+```jsx
+;
+
+// compila approssimativamente a:
+
+// estraiamo il corpo del componente per isolarlo e prevenire costosi aggiornamenti
+untrack(() =>
+ Componente({
+ prop1: "statica",
+ // espressione dinamica quindi avvolgiamo in un getter
+ get prop2() {
+ return state.dinamica;
+ }
+ })
+);
+```
+
+Per aiutare a mantenere la reattività, Solid ha un paio di aiutanti:
+
+```jsx
+// oggetti di scena predefiniti
+props = mergeProps({ name: "Italiano" }, props);
+
+// clone
+const newProps = mergeProps(props);
+
+// unire
+props = mergeProps(props, otherProps);
+
+// sdividere gli oggetti di scena in più oggetti di scena
+const [locale, altre] = splitProps(props, ["className"])
+
+```
+
+## Children
+
+Solid gestisce JSX Children simile a React. Un singolo figlio è un singolo valore su `props.children` e più figli vengono gestiti tramite un array di valori. Normalmente, li passi alla vista JSX. Se vuoi interagire con loro il metodo suggerito è l'helper `figli` che risolve qualsiasi flusso di controllo a valle e restituisce un memo.
+
+```jsx
+// singolo
+const Etichetta = (props) =>
Salve, { props.children }
+
+Michele
+
+// multipla
+const List = (props) =>
;
+
+// mmodificare e mappare i bambini usando l'helper
+const Elenco = (props) => {
+ // l'assistente dei bambini memorizza il valore e risolve tutte le reattività intermedie
+ const memo = bambini(() => props.children);
+ createEffect(() => {
+ const bambini = memo();
+ bambini.forEach((c) => c.classList.add("elenco-bambino"))
+ })
+ return
+ {item =>
{item}
}
+
;
+```
+
+**Importante:** Solid tratta i tag inferiori come espressioni costose e li racchiude allo stesso modo delle espressioni reattive dinamiche. Valutano pigramente l'accesso "prop". Fai attenzione ad accedervi più volte o a destrutturare prima del punto in cui li useresti nella vista. Solid non ha il lusso di creare nodi DOM virtuali in anticipo e poi di differenziarli. La risoluzione di questi "sostegni" deve essere pigra e deliberata. Usa l'helper `bambini` se desideri farlo mentre li memorizza.
diff --git a/documentation/it/guides/server.md b/documentation/it/guides/server.md
new file mode 100644
index 000000000..2f0172a3c
--- /dev/null
+++ b/documentation/it/guides/server.md
@@ -0,0 +1,135 @@
+# Server di rendering
+
+Solid gestisce il rendering del server compilando i modelli JSX in un codice di aggiunta di stringhe ultra efficiente. Questo accade con il plugin o il preset Babel passando in `generate: "ssr"`. Con client e server è necessario passare `hydratable: true` per generare il codice compatibile con l'idratazione.
+
+I runtime `solid-js` e `solid-js/web` vengono scambiati con versioni non reattive durante l'esecuzione in un ambiente nodo. Per altri ambienti sarà necessario raggruppare il codice del server con esportazioni condizionali impostate su "nodo". La maggior parte dei bundler ha un modo per farlo. Raccomandiamo anche di usare le condizioni di esportazione `solid` così come si consiglia alle librerie di spedire i loro sorgenti sotto l'export `solid`.
+
+Costruire per SSR richiede sicuramente un po' più di configurazione. Genereremo 2 bundle separati. La voce client dovrebbe usare "idrato":
+
+```jsx
+import { hydrate } from "solid-js/web";
+
+hydrate(() => , document);
+```
+
+_Nota: è possibile renderizzare e idratare dalla radice del documento. Questo ci permette di descrivere la nostra visione completa in JSX._
+
+La voce del server può utilizzare una delle quattro opzioni di rendering offerte da Solid. Ciascuno produce l'output e un tag di script da inserire nell'intestazione del documento.
+
+```jsx
+import {
+ renderToString,
+ renderToStringAsync,
+ renderToNodeStream,
+ renderToWebStream
+} from "solid-js/web";
+
+// Rendering di stringhe sincrone
+const html = renderToString(() => );
+
+// Rendering di stringhe asincrone
+const html = await renderToStringAsync(() => );
+
+// Node Stream API
+pipeToNodeWritable(App, res);
+
+// Web Stream API (come esempio Cloudflare Workers)
+const { readable, writable } = new TransformStream();
+pipeToWritable(() => , writable);
+```
+
+Per semplicità `solid-js/web` esporta un flag `isServer`. Ciò è utile in quanto la maggior parte dei bundler sarà in grado di eseguire il treeshake di qualsiasi cosa sotto questo flag o le importazioni utilizzate solo dal codice sotto questo flag dal tuo bundle client.
+
+```jsx
+import { isServer } from "solid-js/web";
+
+if (isServer) {
+ // solo per server
+} else {
+ // solo nel browser
+}
+```
+
+## Script di idratazione
+
+Per idratarsi progressivamente direttamente prima del caricamento del runtime di Solid, è necessario inserire uno script speciale nella pagina. Può essere generato e inserito tramite `generateHydrationScript`o incluso come parte di JSX utilizzando il tag ``.
+
+```js
+import { generateHydrationScript } from "solid-js/web";
+
+const app = renderToString(() => );
+
+const html = `
+
+
+ 🔥 Solid 🔥
+
+
+
+ ${generateHydrationScript()}
+
+ ${app}
+
+`;
+```
+
+```jsx
+import { HydrationScript } from "solid-js/web";
+
+const App = () => {
+ return (
+
+
+ 🔥 Solid 🔥
+
+
+
+
+
+ {/*... resto dell'app */}
+
+ );
+};
+```
+
+Fai attenzione quando ti idrati. Anche l'inserimento di risorse che non sono disponibili nell'esecuzione del client può rovinare le cose. Solid fornisce un componente `` i cui figli funzioneranno normalmente sul server. Questo non è per idratare nel browser.
+
+```jsx
+
+ {manifesta.map(m => (
+
+ ))}
+
+```
+
+## Asincrono e streaming SSR
+
+I meccanismi sono costruiti sulla conoscenza di Solid di come funziona la tua applicazione. Usando Suspense e l'API delle risorse sul server, invece di recuperare in anticipo e quindi eseguire il rendering. Solid recupera mentre esegue il rendering sul server in modo simile al client. Il codice e i modelli di esecuzione sono scritti esattamente allo stesso modo.
+
+Il rendering asincrono attende la risoluzione di tutti i limiti di Suspense. Quindi invia i risultati o li scrive su un file nel caso di Static Site Generation.
+
+Lo streaming inizia a scaricare il contenuto sincrono nel browser, rendendo immediatamente i tuoi Suspense Fallback sul server. Quindi, quando i dati asincroni terminano sul server, inviano lo stesso flusso al client per risolvere Suspense. Questo è quando il browser termina il lavoro e sostituisce il fallback con contenuto reale.
+
+Il vantaggio:
+
+- Il server non deve attendere che i dati asincroni rispondano. Le risorse possono iniziare a caricarsi prima nel browser e l'utente può iniziare a vedere i contenuti prima.
+- Rispetto al recupero del client come JAMStack, il caricamento dei dati inizia immediatamente sul server e non deve attendere il caricamento di JavaScript del client.
+- Tutti i dati vengono serializzati e trasportati automaticamente dal server al client.
+
+## Avvertenze SSR
+
+La soluzione SSR isomorfa di Solid è molto potente. Puoi scrivere il tuo codice principalmente come base di codice singola che funziona in modo simile in entrambi gli ambienti. Tuttavia ci sono aspettative che questo metta su idratazione. Principalmente che la vista renderizzata nel client è la stessa che sarebbe resa sul server. Non ha bisogno di essere esatto in termini di testo. Strutturalmente il markup dovrebbe essere lo stesso.
+
+Usiamo i marcatori resi nel server per abbinare elementi e posizioni delle risorse sul server. Per questo motivo Client e Server dovrebbero avere gli stessi componenti. Questo non è in genere un problema dato che Solid esegue il rendering allo stesso modo su client e server. Attualmente non esiste un metodo per rendere qualcosa sul server che non si idrata sul client. Non è possibile idratare parzialmente un'intera pagina e non generare indicatori di idratazione per essa. L'idratazione parziale è qualcosa che vogliamo esplorare in futuro.
+
+Infine, tutte le risorse devono essere definite nell'albero `render`. Vengono automaticamente serializzati e prelevati nel browser. Funziona perché i metodi `render` o `pipeTo` tengono traccia dell'avanzamento del rendering. Non possiamo fare nulla se vengono creati in un contesto isolato. Allo stesso modo non c'è reattività sul server. Non aggiornare i segnali durante il rendering iniziale e aspettarti che si riflettano più in alto nell'albero. Ci sono limiti di Suspense ma l'SSR di Solid viene elaborato dall'alto verso il basso.
+
+## Iniziare con SSR
+
+Le configurazioni SSR sono complicate. Abbiamo alcuni esempi nel pacchetto [solid-ssr](https://github.com/solidjs/solid/blob/main/packages/solid-ssr).
+
+È in lavorazione un nuovo antipasto [SolidStart](https://github.com/solidjs/solid-start) che mira a rendere questa esperienza molto più fluida.
+
+## Iniziare con la generazione di siti statici
+
+[solid-ssr](https://github.com/solidjs/solid/blob/main/packages/solid-ssr) viene fornito anche con una semplice utility per la generazione di siti statici o prerenderizzati. Leggi il README per maggiori informazioni.