html

Il modo in cui i browser gestiscono il rendering delle pagine sta per cambiare parecchio, almeno se dipendesse da Google. Le nuove API di Chrome pensate per rendere più efficienti gli aggiornamenti web puntano a risolvere un problema che esiste praticamente da sempre: il fatto che HTML venga elaborato in modo strettamente sequenziale, dall'alto verso il basso, senza possibilità di aggiornare singole porzioni della pagina fuori ordine. La proposta si chiama Declarative Partial Updates ed è già disponibile in fase sperimentale a partire da Chrome 148, attivabile tramite il flag chrome://flags/#enable-experimental-web-platform-features. Il punto di partenza è semplice da capire: HTML nasce come formato di documento, non come un ambiente applicativo. Quando una pagina deve attendere dati lenti, magari una query al database o una risposta da un servizio esterno, il browser si trova davanti a un bivio poco entusiasmante. Può aspettare che tutto sia pronto prima di mostrare qualcosa, oppure può mandare dei segnaposto temporanei e poi lasciare che JavaScript si occupi di sostituirli con i contenuti reali. Nel primo caso si rallenta il caricamento visibile della pagina, cosa che Google stessa penalizza in termini di ranking e visibilità nei risultati di ricerca. Nel secondo caso serve più JavaScript e più lavoro lato browser, con framework che negli anni hanno costruito architetture complesse proprio per gestire questa situazione. Google sostiene che parte di questa complessità possa essere eliminata introducendo funzionalità native direttamente nel parser HTML del browser. Con le nuove API, il browser può ricevere contenuti parziali e posizionarli nel punto giusto della pagina anche se arrivano in ritardo rispetto alla struttura iniziale. È questo il cuore di Declarative Partial Updates. Come funzionano le processing instructions e lo streaming HTML Sul piano tecnico, la proposta introduce un sistema basato su nuove processing instructions HTML. Storicamente queste appartenevano al mondo XML e in HTML venivano trattate come semplici commenti ignorati dal parser. Chrome ora cambia le regole del gioco: le processing instructions diventano punti di aggancio dinamici. Quando il server invia successivamente il contenuto associato a uno di questi marker, il parser aggiorna automaticamente il nodo corretto nel documento, senza che l'ordine di arrivo debba per forza coincidere con l'ordine finale della pagina. Questo elimina passaggi intermedi, riduce allocazioni DOM inutili e limita il lavoro tipico dei framework lato client. Ma Chrome non si ferma qui. La seconda parte della proposta introduce un'intera famiglia di API per l'inserimento e lo streaming HTML. Oggi esistono strumenti separati come innerHTML, outerHTML, insertAdjacentHTML e altri, ciascuno con comportamenti diversi in fatto di sanitizzazione del codice, esecuzione degli script e supporto alla sicurezza. Le nuove API provano a uniformare tutto con metodi come setHTML(), appendHTML(), replaceWithHTML() e le rispettive controparti streaming come streamHTML() e streamReplaceWithHTML(). Il browser può così ricevere uno stream HTML progressivo senza dover attendere il payload completo, eliminando la necessità di simulare lo streaming con tecniche manuali o addirittura con il vecchio document.write(). Sicurezza, framework e il futuro dell'interoperabilità Ogni volta che si inserisce HTML dinamico nel DOM si apre il problema del Cross-Site Scripting (XSS), e Google dedica parecchio spazio a questo aspetto. Le versioni considerate sicure delle nuove API eseguono automaticamente la sanitizzazione del codice, rimuovendo contenuti potenzialmente pericolosi. Le varianti Unsafe, invece, non applicano queste protezioni e richiedono maggiore attenzione da parte di chi sviluppa. Il supporto a Trusted Types resta un elemento chiave per gestire in modo coerente le sorgenti HTML ed evitare vulnerabilità. Il rischio concreto è che team meno esperti scelgano le versioni Unsafe per comodità, reintroducendo problemi che i browser cercano di arginare da anni. Va detto che il problema non nasce con queste API: anche oggi innerHTML viene spesso usata in modo scorretto. La differenza è che Chrome sta cercando di proporre un modello più chiaro e meno ambiguo. La proposta racconta qualcosa di più ampio. Da tempo i browser osservano l'evoluzione dei framework JavaScript e cercano di incorporarne le idee migliori direttamente nella piattaforma. Questo non significa che React o Vue spariranno, però potrebbe ridursi la quantità di codice necessaria per ottenere rendering progressivo e aggiornamenti incrementali. Resta da capire quanto rapidamente queste API usciranno dalla fase sperimentale e soprattutto se Firefox e Safari decideranno di implementarle: una funzione disponibile solo in Chromium e derivati rischia di rimanere confinata agli esperimenti.

html

HTML-first raddoppia gli utenti in una notte

Chrome: le API che rivoluzioneranno il caricamento delle pagine web