Come funziona un Browser | Come si popola la pagina Web

Popolamento di una pagina: come funzionano i browser
Gli utenti vogliono esperienze web con contenuti che si carichino velocemente e con cui sia facile interagire. Pertanto, uno sviluppatore dovrebbe impegnarsi per raggiungere questi due obiettivi.

Per capire come migliorare le prestazioni e le prestazioni percepite, è utile capire come funziona il browser.

Cos’è un browser?

Un browser web è un software che consente agli utenti di accedere e visualizzare contenuti sul World Wide Web. La sua funzione principale è quella di individuare e recuperare pagine web, immagini, video, documenti e altri file dai server e visualizzarli sul dispositivo dell’utente.

Quando digiti l’URL di un sito web nel browser e premi Invio, il browser invia una richiesta al server in cui sono archiviati i file del sito web utilizzando protocolli come HTTP o HTTPS. Il server risponde inviando file, solitamente scritti in HTML, CSS o JavaScript, che il browser interpreta e visualizza come una pagina web.

Come funziona un browser?

I browser sono responsabili del recupero e della visualizzazione di contenuti web agli utenti. Quando un utente immette un URL o clicca su un link, il browser avvia una serie complessa di azioni per recuperare il contenuto web da un server e visualizzarlo sul dispositivo dell’utente.

Illustrazione che spiega come un contenuto viaggia nella rete e viene poi interpretato dal browser

Il processo inizia con la risoluzione del Domain Name System (DNS), in cui il browser traduce il nome di dominio in un indirizzo IP per individuare il server in cui è archiviata la pagina Web.

Passaggio 1: il processo inizia con la risoluzione del Domain Name System (DNS), in cui il browser traduce il nome di dominio in un indirizzo IP per individuare il server in cui è archiviata la pagina Web.
Passaggio 2: il browser invia quindi una richiesta HTTP al server, specificando il percorso e i parametri della risorsa richiesta.
Passaggio 3: una volta che il server riceve la richiesta, invia una risposta HTTP al browser contenente la risorsa richiesta in codice HTML, CSS e JavaScript.
Passaggio 4: il motore di rendering del browser interpreta e rende il codice per visualizzare la pagina Web sul dispositivo dell’utente.
Passaggio 5: i fogli di stile CSS vengono applicati per formattare il contenuto della pagina Web, inclusi caratteri, colori e layout.
Passaggio 6: il browser può anche eseguire codice JavaScript sulla pagina Web per aggiungere interattività e comportamento dinamico.

Fase 7: Man mano che vengono caricati nuovi contenuti o vengono apportate modifiche alla pagina web, il browser aggiorna la visualizzazione di conseguenza.

Tipi di browser

Esistono diversi tipi di browser disponibili per gli utenti, tra cui:

Browser desktop: sono i browser più comuni che gli utenti installano sui loro computer desktop o laptop. Esempi includono Google Chrome, Mozilla Firefox, Microsoft Edge, Apple Safari e Opera.
Browser mobili: i browser progettati specificamente per dispositivi mobili come smartphone e tablet sono chiamati browser mobili. Esempi includono Google Chrome per Android e iOS, Safari per iOS, Firefox per Android e Opera per Android e iOS.
Browser console: sono progettati per console di gioco come Xbox e PlayStation, consentendo agli utenti di navigare sul Web dalle loro console.
Browser basati su testo: i browser legacy che visualizzano i siti Web solo come testo, senza grafica o immagini, sono basati su testo. Esempi includono Lynx ed Elinks.

Componenti di un browser

il browser web è costituito da due elementi chiave: il front-end e il back-end, entrambi essenziali per un’esperienza di navigazione fluida.

Il front-end è l’interfaccia rivolta all’utente. Include:
Barra degli indirizzi: dove vengono inseriti gli URL.
Pulsanti di navigazione: per tornare indietro, avanti o aggiornare le pagine.
Segnalibri e schede: consentono un rapido accesso e la gestione di più pagine web.
Il back-end opera dietro le quinte e gestisce:
- Comunicazione: interazione con i server web.
- Gestione delle risorse: recupero ed elaborazione di file HTML, CSS e JavaScript.
- Supporto del protocollo: gestione di protocolli di rete come HTTP e HTTPS.
- Sicurezza: implementazione della crittografia e della verifica dei certificati.

illustrazione che mostra gli elementi che compongono un browser

Approfondimento del funzionamento di un Browser

I siti veloci permettono a chi naviga esperienze utente migliori. Gli utenti vogliono e si aspettano esperienze web con contenuti che si carichino velocemente e con cui sia facile interagire.

Due problemi principali nelle prestazioni web sono problemi legati alla latenza e problemi legati al fatto che, per la maggior parte, i browser sono single-thread.

La latenza è la minaccia più grande alla nostra capacità di garantire una pagina dal caricamento veloce.

L’obiettivo di un webmaster è quello di far caricare il sito il più velocemente possibile, o almeno di far sembrare che si carichi super velocemente, in modo che l’utente riceva le informazioni richieste il più rapidamente possibile. La latenza di rete è il tempo necessario per trasmettere byte via etere ai computer. Le prestazioni web sono ciò che dobbiamo fare per far caricare la pagina il più velocemente possibile.

Per la maggior parte, i browser sono considerati single-thread. Cioè, eseguono un’attività dall’inizio alla fine prima di iniziare un’altra attività. Per interazioni fluide, l’obiettivo dello sviluppatore è garantire interazioni performanti del sito, dallo scorrimento fluido alla risposta al tocco. Il tempo di rendering è fondamentale, per garantire che il thread principale possa completare tutto il lavoro che gli affidiamo e che sia sempre disponibile per gestire le interazioni dell’utente.

Le prestazioni Web possono essere migliorate comprendendo la natura single-threaded del browser e riducendo al minimo le responsabilità del thread principale, ove possibile e appropriato, per garantire che il rendering sia fluido e che le risposte alle interazioni siano immediate.

Navigazione

La navigazione è il primo passaggio nel caricamento di una pagina Web. Si verifica ogni volta che un utente richiede una pagina immettendo un URL nella barra degli indirizzi, cliccando su un collegamento, inviando un modulo e altre azioni.

Uno degli obiettivi delle prestazioni Web è ridurre al minimo la quantità di tempo necessaria per completare la navigazione. In condizioni ideali, di solito non ci vuole troppo tempo, ma la latenza e la larghezza di banda sono nemici che possono causare ritardi.

Ricerca DNS

Il primo passaggio per navigare su una pagina web è trovare dove si trovano le risorse per quella pagina. Se navighi su https://sitoesempio.com, la pagina HTML si trova sul server con indirizzo IP 85.968.276.43. Se non hai mai visitato questo sito, deve essere eseguita una ricerca DNS.

Il tuo browser richiede una ricerca DNS, che alla fine viene elaborata da un name server, che a sua volta risponde con un indirizzo IP. Dopo questa richiesta iniziale, l’IP verrà probabilmente memorizzato nella cache per un po’ di tempo, il che velocizza le richieste successive recuperando l’indirizzo IP dalla cache anziché contattare nuovamente un name server.

Le ricerche DNS di solito devono essere eseguite solo una volta per nome host per un caricamento di pagina. Tuttavia, le ricerche DNS devono essere eseguite per ogni nome host univoco a cui fa riferimento la pagina richiesta. Se i tuoi font, immagini, script, annunci e metriche hanno tutti nomi host diversi, sarà necessario effettuare una ricerca DNS per ciascuno di essi.

Ciò può essere problematico per le prestazioni, in particolare sulle reti mobili. Quando un utente è su una rete mobile, ogni ricerca DNS deve passare dal telefono alla torre cellulare per raggiungere un server DNS autorevole. La distanza tra un telefono, una torre cellulare e il server dei nomi può aggiungere una latenza significativa.

Handshake TCP

Una volta noto l’indirizzo IP, il browser imposta una connessione al server tramite un handshake TCP a tre vie. Questo meccanismo è progettato in modo che due entità che tentano di comunicare, in questo caso il browser e il server Web, possano negoziare i parametri della connessione socket TCP di rete prima di trasmettere dati, spesso tramite HTTPS.

La tecnica di handshake a tre vie di TCP è spesso definita “SYN-SYN-ACK” o, più precisamente, SYN, SYN-ACK, ACK, perché ci sono tre messaggi trasmessi da TCP per negoziare e avviare una sessione TCP tra due computer. Sì, questo significa altri tre messaggi avanti e indietro tra ciascun server e la richiesta deve ancora essere effettuata.

Negoziazione TLS

Per connessioni sicure stabilite tramite HTTPS, è richiesta un’altra “stretta di mano”. Questa stretta di mano, o meglio la negoziazione TLS, determina quale cifratura verrà utilizzata per crittografare la comunicazione, verifica il server e stabilisce che è in atto una connessione sicura prima di iniziare il trasferimento effettivo dei dati. Ciò richiede altri cinque round trip al server prima che la richiesta di contenuto venga effettivamente inviata.

Sebbene rendere sicura la connessione aggiunga tempo al caricamento della pagina, una connessione sicura vale la spesa di latenza, poiché i dati trasmessi tra il browser e il server web non possono essere decriptati da terzi.

Dopo gli otto viaggi di andata e ritorno al server, il browser è finalmente in grado di effettuare la richiesta.

Risposta

Una volta stabilita una connessione a un server web, il browser invia una richiesta HTTP GET iniziale per conto dell’utente, che per i siti web è il più delle volte un file HTML. Una volta che il server riceve la richiesta, risponderà con le intestazioni di risposta pertinenti e il contenuto dell’HTML.

HTML
<!doctype html>
<html lang="it">
<head>
<meta charset="UTF-8" />
<title>La mia pagina semplice</title>
<link rel="stylesheet" href="styles.css" />
<script src="mioscript.js"></script>
</head>
<body>
<h1 class="heading">La mia pagina</h1>
<p>Un paragrafo con un <a href="https://esempiosito.com/chi-siamo">link</a></p>
<div>
<img src="mia-immagine.jpg" alt="descrizione immagine" />
</div>
<script src="altro-script.js"></script>
</body>
</html>

Questa risposta per questa richiesta iniziale contiene il primo byte di dati ricevuti. Time to First Byte (TTFB) è il tempo che intercorre tra il momento in cui l’utente ha effettuato la richiesta, ad esempio cliccando su un collegamento, e la ricezione di questo primo pacchetto HTML. Il primo blocco di contenuto è solitamente di 14 KB di dati.

Nel nostro esempio precedente, la richiesta è sicuramente inferiore a 14 KB, ma le risorse collegate non vengono richieste finché il browser non incontra i collegamenti durante l’analisi, descritta di seguito.

Controllo della congestione / avvio lento TCP

I pacchetti TCP vengono suddivisi in segmenti durante la trasmissione. Poiché TCP garantisce la sequenza dei pacchetti, il server deve ricevere un riconoscimento dal client sotto forma di un pacchetto ACK dopo l’invio di un certo numero di segmenti.

Se il server attende un ACK dopo ogni segmento, ciò si tradurrà in frequenti ACK dal client e potrebbe aumentare il tempo di trasmissione, anche nel caso di una rete a basso carico.

D’altro canto, inviare troppi segmenti contemporaneamente può portare al problema che in una rete occupata il client non sarà in grado di ricevere i segmenti e continuerà a rispondere con ACK per molto tempo, e il server dovrà continuare a inviare nuovamente i segmenti.

Per bilanciare il numero di segmenti trasmessi, l’algoritmo TCP slow start viene utilizzato per aumentare gradualmente la quantità di dati trasmessi fino a quando non può essere determinata la larghezza di banda massima della rete e per ridurre la quantità di dati trasmessi in caso di carico di rete elevato.

Il numero di segmenti da trasmettere è controllato dal valore della finestra di congestione (CWND), che può essere inizializzato a 1, 2, 4 o 10 MSS (MSS è 1500 byte sul protocollo Ethernet). Tale valore è il numero di byte da inviare, alla ricezione dei quali il client deve inviare un ACK.

Se viene ricevuto un ACK, il valore CWND verrà raddoppiato e quindi il server sarà in grado di inviare più segmenti la volta successiva. Se invece non viene ricevuto alcun ACK, il valore CWND verrà dimezzato. Questo meccanismo raggiunge quindi un equilibrio tra l’invio di troppi segmenti e l’invio di troppo pochi.

Parsing

Una volta che il browser riceve il primo blocco di dati, può iniziare ad analizzare le informazioni ricevute. L’analisi è il passaggio che il browser esegue per trasformare i dati ricevuti tramite la rete in DOM e CSSOM, che vengono utilizzati dal renderer per dipingere una pagina sullo schermo.

Il DOM è la rappresentazione interna del markup per il browser. Il DOM è anche esposto e può essere manipolato tramite varie API in JavaScript.

Anche se l’HTML della pagina richiesta è più grande del pacchetto iniziale da 14 KB, il browser inizierà ad analizzare e tentare di eseguire il rendering di un’esperienza in base ai dati in suo possesso. Ecco perché è importante per l’ottimizzazione delle prestazioni web includere tutto ciò di cui il browser ha bisogno per iniziare a eseguire il rendering di una pagina, o almeno un modello della pagina, ovvero il CSS e l’HTML necessari per il primo rendering, nei primi 14 KB. Ma prima che qualsiasi cosa venga renderizzata sullo schermo, HTML, CSS e JavaScript devono essere analizzati.

Creazione dell’albero DOM

Descriviamo cinque passaggi nel percorso di rendering critico.

Il primo passaggio è l’elaborazione del markup HTML e la creazione dell’albero DOM. L’analisi HTML comporta la tokenizzazione e la costruzione dell’albero. I token HTML includono tag di inizio e fine, nonché nomi e valori degli attributi. Se il documento è ben formato, l’analisi è semplice e veloce. L’analizzatore analizza l’input tokenizzato nel documento, creando l’albero del documento.

L’albero DOM descrive il contenuto del documento. L’elemento <html> è il primo elemento e il nodo radice dell’albero del documento. L’albero riflette le relazioni e le gerarchie tra i diversi elementi. Gli elementi nidificati all’interno di altri elementi sono nodi figlio. Maggiore è il numero di nodi DOM, più tempo ci vuole per costruire l’albero DOM.

Quando il parser trova risorse non bloccanti, come un’immagine, il browser richiederà tali risorse e continuerà l’analisi. L’analisi può continuare quando viene rilevato un file CSS, ma gli elementi <script>, in particolare quelli senza un attributo async o defer, bloccano il rendering e mettono in pausa l’analisi dell’HTML. Sebbene lo scanner di precaricamento del browser acceleri questo processo, gli script eccessivi possono comunque rappresentare un collo di bottiglia significativo.

Scanner di precaricamento

Mentre il browser crea l’albero DOM, questo processo occupa il thread principale. Mentre ciò accade, lo scanner di precaricamento analizzerà il contenuto disponibile e richiederà risorse ad alta priorità come CSS, JavaScript e font Web. Grazie allo scanner di precaricamento, non dobbiamo aspettare che il parser trovi un riferimento a una risorsa esterna per richiederla. Recupererà le risorse in background in modo che quando il parser HTML principale raggiunge le risorse richieste, queste potrebbero essere già in volo o essere state scaricate. Le ottimizzazioni fornite dallo scanner di precaricamento riducono i blocchi.

HTML
<link rel="stylesheet" href="styles.css" />
<script src="my-script.js" async></script>
<img src="my-image.jpg" alt="image description" />
<script src="another-script.js" async></script>

In questo esempio, mentre il thread principale analizza HTML e CSS, lo scanner di precaricamento troverà gli script e l’immagine e inizierà a scaricarli. Per assicurarti che lo script non blocchi il processo, aggiungi l’attributo async o l’attributo defer se l’ordine di analisi e di esecuzione di JavaScript è importante.

L’attesa per ottenere CSS non blocca l’analisi o il download di HTML, ma blocca JavaScript perché JavaScript è spesso utilizzato per interrogare l’impatto delle proprietà CSS sugli elementi.

Creazione dell’albero CSSOM

Il secondo passaggio nel percorso di rendering critico è l’elaborazione di CSS e la creazione dell’albero CSSOM. Il modello di oggetti CSS è simile al DOM. DOM e CSSOM sono entrambi alberi. Sono strutture dati indipendenti. Il browser converte le regole CSS in una mappa di stili che può comprendere e con cui può lavorare. Il browser esamina ogni set di regole nel CSS, creando un albero di nodi con relazioni padre, figlio e fratello in base ai selettori CSS.

Come con HTML, il browser deve convertire le regole CSS ricevute in qualcosa con cui può lavorare. Quindi, ripete il processo HTML-oggetto, ma per il CSS.

L’albero CSSOM include stili dal foglio di stile dell’agente utente. Il browser inizia con la regola più generale applicabile a un nodo e perfeziona ricorsivamente gli stili calcolati applicando regole più specifiche. In altre parole, esegue la cascata dei valori delle proprietà.

La creazione del CSSOM è molto, molto veloce e queste informazioni sul tempo di creazione non vengono visualizzate negli strumenti per sviluppatori. Piuttosto, “Ricalcola stile” negli strumenti per sviluppatori mostra il tempo totale necessario per analizzare il CSS, costruire l’albero CSSOM e calcolare ricorsivamente gli stili calcolati. In termini di prestazioni web, ci sono molti modi migliori per investire sforzi di ottimizzazione, poiché il tempo totale per creare il CSSOM è generalmente inferiore al tempo necessario per una ricerca DNS.

Altri processi

Compilazione JavaScript
Mentre il CSS viene analizzato e il CSSOM viene creato, altre risorse, inclusi i file JavaScript, vengono scaricate (grazie allo scanner di precaricamento). JavaScript viene analizzato, compilato e interpretato. Gli script vengono analizzati in alberi sintattici astratti. Alcuni motori di browser prendono gli alberi sintattici astratti e li passano a un compilatore, producendo bytecode. Questo è noto come compilazione JavaScript. La maggior parte del codice viene interpretata sul thread principale, ma ci sono eccezioni come il codice eseguito nei web worker.

Creazione dell’albero di accessibilità
Il browser crea anche un albero di accessibilità che i dispositivi di assistenza utilizzano per analizzare e interpretare il contenuto. Il modello di oggetti di accessibilità (AOM) è come una versione semantica del DOM. Il browser aggiorna l’albero di accessibilità quando il DOM viene aggiornato. L’albero di accessibilità non è modificabile dalle stesse tecnologie di assistenza.

Finché non viene creato l’AOM, il contenuto non è accessibile agli screen reader.

Render

I passaggi di rendering includono stile, layout, paint e, in alcuni casi, compositing. Gli alberi CSSOM e DOM creati nel passaggio di analisi vengono combinati in un albero di rendering che viene quindi utilizzato per calcolare il layout di ogni elemento visibile, che viene quindi dipinto sullo schermo. In alcuni casi, il contenuto può essere promosso al proprio livello e composito, migliorando le prestazioni dipingendo parti dello schermo sulla GPU anziché sulla CPU, liberando il thread principale.

Style

Il terzo passaggio nel percorso di rendering critico consiste nel combinare DOM e CSSOM in un albero di rendering. La costruzione dell’albero di stile calcolato, o albero di rendering, inizia con la radice dell’albero DOM, attraversando ogni nodo visibile.

Gli elementi che non verranno visualizzati, come l’elemento <head> e i suoi figli e tutti i nodi con display: none, come lo script { display: none; } che troverai nei fogli di stile dell’agente utente, non sono inclusi nell’albero di rendering poiché non appaiono nell’output renderizzato. I nodi con visibility: hidden applicato sono inclusi nell’albero di rendering, poiché occupano spazio. Poiché non abbiamo fornito alcuna direttiva per sovrascrivere l’impostazione predefinita dell’agente utente, il nodo script nel nostro esempio di codice sopra non sarà incluso nell’albero di rendering.

A ogni nodo visibile sono applicate le sue regole CSSOM. L’albero di rendering contiene tutti i nodi visibili con contenuto e stili elaborati, abbinando tutti gli stili rilevanti a ogni nodo visibile nell’albero DOM e determinando, in base alla cascata CSS, quali sono gli stili elaborati per ogni nodo.

Layout

Il quarto passaggio nel percorso di rendering critico è l’esecuzione di layout sull’albero di rendering per calcolare la geometria di ogni nodo. Layout è il processo mediante il quale vengono determinate le dimensioni e la posizione di tutti i nodi nell’albero di rendering, oltre alla determinazione delle dimensioni e della posizione di ogni oggetto sulla pagina. Il reflow è qualsiasi successiva determinazione delle dimensioni e della posizione di qualsiasi parte della pagina o dell’intero documento.

Una volta creato l’albero di rendering, inizia il layout. L’albero di rendering ha identificato quali nodi sono visualizzati (anche se invisibili) insieme ai loro stili calcolati, ma non le dimensioni o la posizione di ciascun nodo. Per determinare le dimensioni esatte e la posizione di ciascun oggetto, il browser inizia dalla radice dell’albero di rendering e lo attraversa.

Nella pagina web, quasi tutto è una casella. Dispositivi diversi e preferenze desktop diverse implicano un numero illimitato di diverse dimensioni di viewport. In questa fase, tenendo in considerazione le dimensioni di viewport, il browser determina quali saranno le dimensioni di tutte le diverse caselle sullo schermo. Prendendo come base le dimensioni di viewport, il layout inizia generalmente con il corpo, disponendo le dimensioni di tutti i discendenti del corpo, con le proprietà del modello di casella di ogni elemento, fornendo uno spazio segnaposto per gli elementi sostituiti di cui non conosce le dimensioni, come la nostra immagine.

La prima volta che vengono determinate le dimensioni e la posizione di ogni nodo è chiamata layout. I successivi ricalcoli sono chiamati reflow. Nel nostro esempio, supponiamo che il layout iniziale si verifichi prima che l’immagine venga restituita. Poiché non abbiamo dichiarato le dimensioni della nostra immagine, ci sarà un reflow una volta note le dimensioni dell’immagine.

Paint

L’ultimo passaggio nel percorso di rendering critico è la verniciatura dei singoli nodi sullo schermo, la cui prima occorrenza è chiamata prima verniciatura significativa. Nella fase di pittura o rasterizzazione, il browser converte ogni casella calcolata nella fase di layout in pixel effettivi sullo schermo. La pittura comporta il disegno di ogni parte visiva di un elemento sullo schermo, inclusi testo, colori, bordi, ombre ed elementi sostituiti come pulsanti e immagini. Il browser deve farlo molto rapidamente.

Per garantire uno scorrimento e un’animazione fluidi, tutto ciò che occupa il thread principale, inclusi gli stili di calcolo, insieme al reflow e alla pittura, deve richiedere al browser meno di 16,67 ms per essere completato. A 2048 x 1536, l’iPad ha oltre 3.145.000 pixel da dipingere sullo schermo. Sono molti pixel che devono essere dipinti molto rapidamente. Per garantire che la ripittura possa essere eseguita ancora più velocemente della pittura iniziale, il disegno sullo schermo è generalmente suddiviso in diversi livelli. Se ciò si verifica, è necessario il compositing.

La pittura può suddividere gli elementi nell’albero del layout in livelli. La promozione del contenuto in livelli sulla GPU (invece che sul thread principale sulla CPU) migliora le prestazioni di pittura e ripittura. Ci sono proprietà ed elementi specifici che creano un livello, tra cui <video> e <canvas>, e qualsiasi elemento che abbia le proprietà CSS di opacità, una trasformazione 3D, will-change e alcune altre. Questi nodi saranno dipinti sul loro livello, insieme ai loro discendenti, a meno che un discendente non necessiti del suo livello per uno (o più) dei motivi di cui sopra.

I livelli migliorano le prestazioni, ma sono costosi quando si tratta di gestione della memoria, quindi non dovrebbero essere abusati come parte delle strategie di ottimizzazione delle prestazioni web.

Compositing

Quando sezioni del documento sono disegnate in livelli diversi, sovrapposti tra loro, il compositing è necessario per garantire che vengano disegnate sullo schermo nell’ordine corretto e che il contenuto venga renderizzato correttamente.

Mentre la pagina continua a caricare risorse, possono verificarsi dei reflow (ricorda la nostra immagine di esempio arrivata in ritardo). Un reflow innesca un repaint e una ricomposizione. Se avessimo definito le dimensioni della nostra immagine, non sarebbe stato necessario alcun reflow e solo il livello che doveva essere ridipinto sarebbe stato ridipinto e composito, se necessario. Ma non abbiamo incluso le dimensioni dell’immagine! Quando l’immagine viene ottenuta dal server, il processo di rendering torna ai passaggi di layout e riparte da lì.

Interattività

Una volta che il thread principale ha finito di dipingere la pagina, penseresti che saremmo “tutti a posto”. Non è necessariamente così. Se il caricamento include JavaScript, che è stato correttamente differito ed eseguito solo dopo l’attivazione dell’evento onload, il thread principale potrebbe essere occupato e non disponibile per lo scorrimento, il tocco e altre interazioni.

Il tempo di interattività (TTI) è la misurazione di quanto tempo è trascorso dalla prima richiesta che ha portato alla ricerca DNS e alla connessione TCP a quando la pagina è interattiva, dove interattiva è il momento successivo al First Contentful Paint in cui la pagina risponde alle interazioni dell’utente entro 50 ms. Se il thread principale è occupato nell’analisi, nella compilazione e nell’esecuzione di JavaScript, non è disponibile e quindi non è in grado di rispondere alle interazioni dell’utente in modo tempestivo (meno di 50 ms).

Nel nostro esempio, forse l’immagine è stata caricata rapidamente, ma forse il file another-script.js era di 2 MB e la connessione di rete del nostro utente era lenta. In questo caso, l’utente vedrebbe la pagina molto rapidamente, ma non sarebbe in grado di scorrere senza problemi finché lo script non fosse stato scaricato, analizzato ed eseguito. Questa non è una buona esperienza utente. Evita di occupare il thread principale, come dimostrato in questo esempio di WebPageTest:

In questo esempio, l’esecuzione di JavaScript ha richiesto oltre 1,5 secondi e per tutto quel tempo il thread principale è stato completamente occupato, senza rispondere agli eventi di clic o ai tocchi dello schermo.

I browser più popolari

Di seguito sono riportati alcuni browser popolari che soddisfano esigenze e preferenze diverse.

1. Google Chrome

Google Chrome è un browser veloce, sicuro e intuitivo di Google. Domina la quota di mercato grazie alla sua velocità e al vasto ecosistema di estensioni. Offre solidi strumenti per sviluppatori e un vasto ambiente di estensioni.