Shopify manda l'head al browser prima che il template sia finito

Il 22 settembre 2026 Shopify ha pubblicato sul proprio blog dedicato alle performance i risultati di un cambiamento nel modo in cui gli storefront Liquid vengono consegnati al browser. Il tempo di attesa del primo byte, il TTFB, cala del 29%, e il conto è fatto sul tempo che tre visite su quattro non superano, per il negozio che sta a metà della classifica di tutti i negozi Shopify. Sulle visite più lente, quelle che stanno nell'ultimo decimo, il recupero è del 21%. First Contentful Paint e Largest Contentful Paint migliorano fra il 2% e il 6%.

Chi vende non deve fare niente per ottenerlo. Il miglioramento è già attivo sulle pagine idonee, non c'è una funzione da abilitare nell'admin, non c'è un tema da rifare, non c'è un'app di ottimizzazione da comprare. Shopify lo scrive senza mediazioni: i risultati spingono le performance dell'intera piattaforma, all without a single change needed from our merchants.

Per chi mantiene il tema il discorso cambia, perché la dimensione del guadagno dipende da come è scritto l'head del layout, e la distanza fra due temi ufficiali di Shopify lo mostra con i numeri.

Che cosa parte per primo, e quando

Prima di questo cambiamento la risposta di una pagina Liquid era un blocco unico. Lo Storefront Renderer, il servizio che Shopify usa per servire le pagine dei negozi, rendeva il layout e tutte le sezioni del template, poi mandava l'HTML completo. Finché quel rendering non finiva, il browser teneva una connessione aperta e non aveva niente su cui lavorare.

Adesso la risposta viene spezzata in due chunk. Shopify rende il layout fino a {{ content_for_header }} e lo manda appena può; il resto della pagina arriva nella stessa risposta quando il rendering del template è completo.

Il primo pezzo contiene l'apertura dell'head, quindi tutto ciò che il tema dichiara prima di quel tag: fogli di stile, preload dei font, import map, variabili CSS. Il browser comincia a risolvere i nomi, aprire le connessioni e scaricare quelle risorse mentre Shopify sta ancora generando il corpo della pagina. Server e browser lavorano nello stesso intervallo di tempo invece che uno dopo l'altro, e il TTFB scende perché il primo byte parte prima, non perché il rendering complessivo sia diventato più rapido.

La distinzione cambia che cosa aspettarsi a valle. Un intervento sul tempo di rendering avrebbe spostato in avanti tutta la timeline della pagina in modo proporzionale; questo intervento sposta il punto in cui il browser può cominciare a fare la sua parte, e il beneficio a valle dipende da quanto lavoro utile il browser trova da fare in quella finestra. È esattamente la ragione per cui FCP e LCP migliorano molto meno del TTFB, e per cui migliorano in misura diversa da un tema all'altro.

I numeri, e la popolazione su cui sono misurati

Le percentuali dichiarate da Shopify riguardano l'aggregato delle pagine viste degli storefront, non una singola pagina né un singolo negozio, e sono espresse in percentili, che è il modo standard di misurare la performance web. Il p75 è il tempo che tre visite su quattro non superano: si ordinano tutte le visite dalla più veloce alla più lenta e si guarda il valore che lascia sotto di sé il 75%. Il p90 è lo stesso conto fatto sul 90% delle visite, quindi scende più a fondo nella coda lenta.

Su questi due valori il guadagno è rispettivamente del 29% e del 21%, e riguarda il negozio mediano, cioè quello che sta a metà della classifica di tutti i negozi Shopify, scelto per non far spostare il dato dai casi estremi. Si misura così e non con la media perché la media impasta le visite veloci con quelle lente e nasconde proprio la coda su cui si interviene.

Sui paint il quadro è più articolato, perché entra in gioco il tema. Horizon guadagna circa l'8% di FCP e il 4% di LCP al p75, Dawn circa il 3% e il 2%. Shopify attribuisce la differenza all'ordinamento delle risorse nell'head: quanto più il tema dichiara sopra {{ content_for_header }} ciò che serve al primo paint, tanto più quel vantaggio di partenza si trasforma in pixel disegnati prima.

Un miglioramento dichiarato in percentili su una popolazione di pagine viste si osserva nei dati di campo, non in una singola esecuzione di laboratorio: un test lanciato due volte sullo stesso URL può restituire differenze più grandi di quelle in discussione, e una prova che non conferma il 29% non dimostra che sul negozio lo streaming non stia funzionando.

Quando una pagina è eleggibile

Lo streaming non si applica a tutte le pagine, e le condizioni sono strette perché il taglio della risposta deve essere sicuro.

La prima condizione riguarda il template. La pagina deve essere resa da un template JSON. I template .liquid restano esclusi, e la ragione è dichiarata: un template Liquid può cambiare il layout a metà rendering, oppure assegnare variabili che il layout legge più avanti, quindi non esiste un punto della risposta in cui sia sicuro tagliare. Finché quella possibilità è aperta, Shopify non può promettere che i byte già spediti restino validi.

La seconda condizione riguarda il layout. {{ content_for_header }} deve comparire dentro il tag <head> come output puro, e la documentazione elenca i modi in cui si perde l'idoneità: il tag non deve avere filtri applicati, non deve stare dentro un {% if %} o un {% capture %}, non deve essere spostato dentro uno snippet, non deve essere assegnato prima a una variabile. La conseguenza non è locale: un tag avvolto, filtrato o spostato disattiva lo streaming su ogni pagina del negozio, non solo su quella in cui la modifica si trova.

Restano fuori anche i temi in anteprima, la preview bar e il theme editor. Chi controlla l'effetto dentro l'editor del tema sta guardando un contesto in cui lo streaming è disattivato per costruzione.

Che cosa cambia nell'head di un tema

La raccomandazione di Shopify per chi mantiene un tema è spostare sopra {{ content_for_header }} quante più definizioni di risorse critiche possibile. La documentazione di shopify.dev è più specifica e nomina le categorie: i fogli di stile, i preload dei font, l'import map e le variabili CSS che servono al primo paint.

Accanto a questa c'è una seconda indicazione, meno visibile e altrettanto operativa: tenere leggero in Liquid l'head del layout. Tutto ciò che sta sopra il tag deve finire di rendersi prima che il primo chunk possa partire, quindi una condizione costosa, un ciclo su una collezione o una chiamata a un metaobject piazzati là sopra ritardano l'inizio dello stream per ogni pagina del negozio. La regola pratica che ne esce è che sopra {{ content_for_header }} vanno dichiarazioni di risorse, non logica.

Le due cautele sullo spostamento

Spostare risorse verso l'alto non è un'operazione neutra, e Shopify segnala due punti in cui rompe qualcosa.

Il primo riguarda JavaScript. Uno script inline che legge gli oggetti Shopify.* non funziona sopra {{ content_for_header }}, perché quegli oggetti li definisce il tag stesso. Lo script trova un riferimento non definito e fallisce, con l'aggravante che il fallimento è silenzioso su un'intera categoria di casi, come le inizializzazioni che dipendono da Shopify.locale, Shopify.currency o Shopify.routes.

Il secondo riguarda i CSS. Shopify inietta i propri stili attraverso content_for_header, e uno stile del tema spostato sopra quel tag cambia posizione nella cascata. A parità di specificità vince la dichiarazione che arriva dopo, quindi una regola che prima prevaleva può trovarsi sopravanzata dagli stili iniettati, e il difetto si manifesta come una differenza visiva che non ha alcun rapporto apparente con la modifica fatta. Il riordino dell'head va accompagnato da un confronto visivo delle pagine chiave prima e dopo, non solo da un controllo dei tempi.

Che cosa Shopify dichiara di star facendo ancora

Nel chiudere l'annuncio Shopify indica due direzioni di lavoro già aperte: allargare l'eleggibilità dello streaming a quante più richieste possibile, e modificare il rendering perché il primo chunk di HTML possa partire ancora prima.

La prima delle due è quella che interessa chi oggi ha pagine servite da template .liquid, che restano escluse. La seconda agisce sullo stesso perimetro di pagine già idonee e sposta più indietro il punto di partenza dello stream.

Sul piano del metodo, l'annuncio contiene anche una nota sul modo in cui la modifica è stata costruita. Shopify scrive che gli agenti di coding AI hanno reso molto meno costosa la lettura ampia e attenta che una modifica di questo tipo richiede, e che l'implementazione ha toccato decine di file del codebase; scrive anche che ingegneri di diversi team hanno rivisto ogni modifica per settimane e hanno obiettato dove serviva. Le due frasi stanno insieme nello stesso paragrafo, e descrivono una divisione del lavoro in cui l'agente copre l'ampiezza e la revisione umana tiene il giudizio.

Che cosa fare, concretamente

Un merchant non deve attivare nulla, e il beneficio arriva sulle pagine che rispettano le condizioni.

Per chi ha un tema su misura, il controllo da fare è breve e va fatto una volta. Si apre theme.liquid e si verifica che {{ content_for_header }} sia un output puro dentro l'head, senza filtri, senza condizioni intorno, non spostato in uno snippet e non assegnato a una variabile: se una di queste condizioni non regge, il negozio sta rinunciando allo streaming su ogni pagina, ed è la prima cosa da sistemare. Poi si guarda quali template sono ancora .liquid invece che JSON, perché quelle pagine restano fuori finché Shopify non allarga l'eleggibilità. Infine si riordina l'head, portando sopra il tag le dichiarazioni di risorse che servono al primo paint e lasciando sotto tutto ciò che dipende da Shopify.*, con una verifica visiva sulle pagine che contano.

Fonte: Liquid storefronts now start loading 29% faster, Performance @ Shopify, 22 settembre 2026, e la documentazione ufficiale su The Shopify platform e Layouts.