Siamo tutti bravi con il browser degli altri!

Siamo tutti bravi
con il browser
degli altri!
Francesco Sciuti
Google Developer Expert / Microsoft MVP / Codemotion devrel

agenda
● alziamo la mano
● Cos’è un browser
● come è fatto
● i processi del browser
● come funziona
● rendering
● i motori
● conclusioni
Francesco Sciuti

quanti di noi non hanno mai detto un #?!-*!!?

Cos’è un browser
Tutti lo usano, pochi lo sanno
Francesco Sciuti

il browser
● Sono il tipo di software in assoluto più utilizzato
● Sono fatti da milioni di righe c++ ed altra roba tosta
● Sono cambiati moltissimo nel tempo
● Sono un concentrato di tecnologia ed algoritmi,
che neanche la batmobile!
è un'applicazione che richiede dati ai server
web, invia una richiesta di rete all'URL, ottiene
risorse e le rappresenta in modo interattivo!
facile, no? e che ce vo’?

Gli utenti adorano vedere i pixel sullo schermo
il più velocemente possibile,
ed è ciò che rende veloce un'applicazione web!
ma chi scrive browser ha un piccolo casino da gestire…
Francesco Sciuti

e a me che ç@#!^
me ne frega a me?
Io mica scrivo browser!
P.s. se qualcuno di voi dovesse essere del team chromium…
vi prego, siate clementi!

come sviluppatori web, abbiamo il dovere di
conoscere alcune delle meccaniche dei browser,
così da prendere decisioni migliori
e capire alcune cose che a volte ci sembrano assurde.
(cit. del famoso ﬁlosofo: ciccio da val demone)

come è fatto
siamo tutti bravi a navigare con il timone degli altri
Francesco Sciuti

L’architettura
● applicazioni multi-processo
● ogni processo si occupa di un logica
speciﬁca
● Ogni processo ha un main thread ed
eventuali thread speciali dedicati
Non ci sono speciﬁche standard su come si
potrebbe costruire un browser web.
L'approccio potrebbe essere completamente
diverso da un browser ad un altro.

p
processi & thread
I processi possono comunicare tra loro attraverso IPC.
I thread possono comunicare tra loro anche all'interno del processo che li contiene, ma non direttamente con i thread in altri processi.
La comunicazione tra processi è, in generale, più lenta della comunicazione tra thread all'interno di un processo.
● Un processo può essere descritto come il
programma in esecuzione di un'applicazione.
● Un thread è quello che vive all'interno del
processo ed esegue qualsiasi parte del processo
al quale appartiene.
p
ipc
ipc
p
t
t
t
t

i processi del browser
sembra il titolo di un ﬁlm ma c’è comunque tanto da investigare
Francesco Sciuti

HIGHEST LEAST
Browser Process
Render Process
IFRAME
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin tincidunt, nunc nec tincidunt vestibulum, ante metus maximus
neque, eget fringilla ante diam sed nibh. Nullam nibh libero, consequat eu ligula non, aliquet laoreet sapien. Aenean
ultricies sed odio quis tempus. Vivamus facilisis tellus eget nunc venenatis malesuada. Phasellus metus metus, tincidunt eu
libero a, lobortis tempus neque. Donec condimentum leo semper leo malesuada, non pretium neque dictum. Integer sit amet
augue non neque dapibus pretium. Nullam id dui ac purus mattis suscipit nec ac nisl. Phasellus dignissim a risus quis cursus.
Curabitur nec lacus faucibus, elementum felis nec, blandit turpis. Duis mollis enim eu tincidunt sagittis. Morbi mauris tellus,
pellentesque id tellus vitae, lobortis fringilla ex.
Render Process
GPU Process
STORAGE
Process
UI
Process
NETWORK
Process
1 PER OGNI TAB
LOWER
PRIORITY:
Architettura multi-processo

Architettura multi-processo
● Sand-boxing
● Black Sheep Detection
● Optimal memory footprint
● Private Data
● Site Isolation
Vantaggi
● Memory Overhead
● Process Creation Overhead
● IPC overhead
SVantaggi
Francesco Sciuti

COME FUNZIONA
NAVIGARE SEMBRA FACILE, MA GUIDARE IL TITANIC È RISCHIOSO
Francesco Sciuti

Scrivo sulla barra degli indirizzi e…
● viene valutato l’input
Browser process | UI thread/Process
● inizia la navigazione!
Browser process | network thread/Process
● viene letta e gestita la risposta
Browser process | network thread/Process
● Viene attivato un render process
Browser process | UI thread/Process
● viene “presa in carico” la navigazione
Render Process
● inizia la document loading phase
Render Process
https://devmyit

Browser Process
ui
Scrivo sulla barra degli indirizzi e…
https://devmyit
NETWORK
Process
Render Process
Francesco Sciuti

Rendering
sembra semplice, eh?
Francesco Sciuti

renderizziamo una pagina
Il processo di rendering, di cui si occupa il
buon render process, è di certo la parte più
articolata ed interessante ed è quella in cui
dobbiamo affrontare il tanto temuto
critical rendering path!
Un processo, tanti threads: main thread, worker threads,
compositor thread, raster thread, …
Francesco Sciuti

Rendering di una pagina
● Parsing
● Style Calculation
● Layout
● Paint
● Compositing
Il processo di rendering, per buona parte
grazie al suo main thread, si snoda tra:
Francesco Sciuti

parsing
● Bytes -> characters
● characters -> token
● Token -> nodes
● nodes -> dom (ﬁnalmente!)
● Subresource loading
i dati vengono inviati su Internet come
pacchetti ed il browser legge i byte grezzi
dell’HTML (anche dal disco rigido).
al main thread il compito di:
00111100 01101000 01110100 01101101
01101100 00111110 00101110 00101110
00101110 00111100 00101111 01101000
01110100 01101101 01101100 00111110
<html><head>...</head>
<body><p>...</p></body></Html>
Start-tag: html
start-tag: head
…
end-tag: head
start-tag: body
…
bytes characters
tokens
html head p span
nodes
html
Head
link
body
span
p
…
dom tree

bytes
characters
tokens
nodes
body
span
p
…
CSSom tree
style calculation
● css Bytes -> characters
● characters -> token
● Token -> nodes
● nodes -> cssom
● layout (o render) tree!
Il main thread analizza CSS e determina il
computed style per ogni nodo del DOM in base ai
selettori CSS.
background-color: red
font-size: 1.1em
color: blue
color: yellow
margin: 10px

layout
Il layout (o reﬂow) è IL processo IN CUI Il
MAIN thread attraversa il DOM e gli stili e
crea IL LAYOUT TREE (O RENDER TREE), che
contiene informazioni come le coordinate
e le dimensioni DEGLI ELEMENTI.
IL PROCESSO DI LAYOUT è ESTREMAMENTE
ONEROSO PER IL BROWSER PERCHé DEVE CALCOLARE
L’ESATTA POSIZIONE E DIMENSIONE DI OGNI
ELEMENTO DELLA PAGINA!
x,y
x,y
w,h

dom cssom
layout (o reﬂow)
dom + cssom = layout (o REnder) tree
layout tree

layout - Layout tree o render tree
per costruire il layout (o render) Tree, il browser
dovrà:
● attraversare ricorsivamente il dom e cercare
gli elementi visibili
● costruire / aggiornare il nodo del layout Tree
puntando il nodo del DOM
● derivare le Computed Styles per il nodo del
DOM, ed associarle con il nodo del layout Tree
layout tree

paint
conosciamo le dimensioni e le posizioni
degli elementi ma non l’ordine con il
quale li andremo a disegnare sulla nostra
pagina.
il main thread attraversa il layout tree per
costruire una coda di paint record, che
consentono di gestire l’ordine di disegno
degli elementi.
background: …
testo
box (x,y …)
,,,

Compositing
Il compositing è una tecnica per gestire parti di
una pagina in livelli, rasterizzarle
separatamente e comporre come pagina in un
thread separato chiamato compositor thread.
Se si veriﬁca lo scrolling (una delle operazioni più
onerose ma comuni), poiché i livelli sono già
rasterizzati, tutto ciò che deve fare è comporre un nuovo
fotogramma.
Francesco Sciuti

Compositing
● Il main thread esegue il traversing del
layout tree per generare il layer tree
● il main thread invia tali informazioni
nel compositor thread
● Il compositor thread rasterizza ogni livello
● Il compositor thread divide in riquadri
ed invia ogni riquadro (Draw quad) ai
raster thread
● Un compositor frame viene quindi inviato
al processo del browser tramite IPC
layout
tree
layer
tree

Compositing
● Draw quads
contiene le informazioni, come la
posizione della tile in memoria e dove nella
disegnarla nella pagina.
● Compositor frame
Una raccolta di Draw quads che
rappresentano il frame di una pagina.
Il vantaggio del compositing è che viene eseguito senza
coinvolgere il main thread!
layout
tree
layer
tree

Browser Process
Compositing - EVENTS
● Browser process riceve una gesture (click) ED invia
l’event type e le cooRDINATE AL RENDERER PROCESS
● Renderer process GESTISCE L’EVENTO NEL CASO IN CUI
CI SIA UN LISTENER
● NEL CASO IN CUI NON CI SIA IL COMPOSITOR THREAD
CREA UN FRAME SENZA CHIEDER NULLA AL MAIN THREAD!
● IL COMPOSITOR THREAD MARCA ED ASSOCIA GLI EVENT
HANDLERS ALLE AREE DELLA PAGINA (Non-Fast Scrollable Region)
NEL CASO IN CUI L’event AVVIENE FUORI DALLE REGION, IL COMPOSITOR THREAD
NON CHIEDE NUOVAMENTE NULLA AL MAIN THREAD
Render Process
ui
C
M

critical rendering path (CRP)
ogni ritardo è critico in questa occasione
Francesco Sciuti

L'intero processo tra la ricezione dei byte HTML, CSS e JS e la loro trasformazione in pixel
renderizzati sullo schermo è chiamato critical rendering path (per gli amici CRP).
network
html
css
dom tree
js
cssom tree
layout tree
paint records
layer tree
layout (reﬂow)
paint
compositing
Francesco Sciuti

Se è in esecuzione un'animazione, una transizione, l'utente sta scorrendo le pagine o fa uno
zoom il browser deve creare frames alla frequenza di aggiornamento del dispositivo.
Sono 60 al secondo i frames per far si che un’animazione sia ﬂuida e questo
costringe il browser a risolvere la pipeline di rendering in circa 10 ms!

jank - il peggior nemico
Quando il browser non riesce a raggiungere questo obiettivo, la
frequenza dei fotogrammi diminuisce e il contenuto non sarà
ﬂuido e ciò avrà un impatto negativo sull'esperienza dell'utente!
Questo è spesso indicato come jank!
0–100 ms — Instant feel, constant ﬂow;
100–300 ms —Slight percetible delay;
300–1000 ms — Loss of task focus, perceptible delay;
1 s+ — Mental context switch;
10s+ — User leaves! Francesco Sciuti

… > Style > Layout > Paint > compositing
quando ci sono cambiamenti sulle geometrie, dimensioni, posizioni, …
quando ci sono cambiamenti in ciò che non inﬂuenza il layout (background image, text color, …)
in poche parole ciò che non inﬂuenza il layout ed il Paint (transform, opacity)
Dopo il caricamento, la pagina cambia in risposta a due tipologie di input:
interazione dell'utente ed aggiornamenti al DOM effettuati da JavaScript.

main thread
alcune precisazioni importanti
Francesco Sciuti

Una rapida distinzione
alle Web application viene concesso un singolo
thread, il main thread, per eseguire la maggior
parte della logica dell'applicazione e
dell'interfaccia utente,
i browser Web non sono assolutamente un
environment a thread singolo!
Francesco Sciuti

Il Browser Event Loop è probabilmente il concetto di prestazioni frontend
più importante da comprendere…ma noi già lo conosciamo, vero?
Ci basta solo sapere che ESSO vive all’interno del main thread!
Il suo comportamento determina il comportamento
delle applicazioni Web in fase di esecuzione.
Browser Event Loop

REQUESTANIMATION
FRAME
RECAP
INPUT
HANDLER
FRAME START
CALC STYLE
COMPOSITOR
THREAD
PARSE HTML LAYOUT PAINT COMPOSITE
RASTERIZE
RAST. SCHEDULE
PIXEL TO SCREEN
FRAME END
MAIN
THREAD
RENDER
PROCESS
GPU
PROCESS
REQUESTIDLE
FRAME
GPU
THREAD

i motori
e non siamo neanche a grand tour ma i motori contano
Francesco Sciuti

cosa usano?
● Chrome, edge, brave
○ render engine: blink (blinkng)
○ js engine: v8
● ﬁrefox
○ render engine: gecko (Quantum)
○ js engine: spider monkey
● safari
○ render engine: webkit
○ js engine: nitro (javascriptcore)
Francesco Sciuti

forse non è come pensavamo
il povero browser, forse, non ha quindi una vita così facile
Francesco Sciuti

QUALCHE idea?
● requestAnimationFrame | REQUESTIDLEFRAME
● WILL-CHANGE (MA CON CAUTELA)
● ASYNC / DEFER ATTRIBUTES
● WORKERS
● PRIORITà DELLE RISORSE
● VALUTARE I CSS TRIGGERS
● VALUTARE COSA FORZA LAYOUT & PAINT
● …
Francesco Sciuti

proviamo ad aiutare lo strumento che ogni
giorno ci fa viaggiare tra miliardi di pagine
piene di cose da imparare (e di gattini)!
Francesco Sciuti

io lo faccio a modo mio...
Francesco Sciuti

...uso il
batcomputer,
che è potente!

...no...non così…
ma provando a scrivere
codice migliore!

Qualche link
quick references
● https://csstriggers.com/
● https://gist.github.com/paulirish/5d52fb081b3570c81e3a
Inside browser
● https://developer.chrome.com/blog/inside-browser-part1/
Francesco Sciuti

Qualche link
Rendering Ng
● https://developer.chrome.com/articles/renderingng/
● https://developer.chrome.com/articles/renderingng-architecture/
● https://developer.chrome.com/articles/renderingng-data-structures/
● https://developer.chrome.com/articles/blinkng/
● https://developer.chrome.com/articles/layoutng/
● https://developer.chrome.com/articles/videong/
Francesco Sciuti

Qualche link
articles & sites
● https://web.dev/mainthread-work-breakdown/
● https://web.dev/fast/#prioritize-resources
● https://web.dev/optimize-javascript-execution/
● https://web.dev/simplify-paint-complexity-and-reduce-paint-areas/
● https://web.dev/avoid-large-complex-layouts-and-layout-thrashing
● https://web.dev/stick-to-compositor-only-properties-and-manage-layer-count/
Francesco Sciuti

Qualche link
articles & sites
● https://www.webperf.tips/
● https://www.html5rocks.com/en/tutorials/internals/howbrowserswork
● https://blog.logrocket.com/how-browser-rendering-works-behind-scenes/
● https://www.toptal.com/web/website-performance-critical-rendering-path/
● https://grosskurth.ca/papers/browser-refarch.pdf
Francesco Sciuti

francesco sciuti
Developer per scelta e per passione,
amante di nerdaggini di ogni
tipo ed amante della
condivisione del sapere!
Francesco Sciuti

Software Factory
● Project Management
● Architecture Design
● Team Augmentation
● Code Review
● Mentoring
● Outsourcing
Learning Factory
● Formazione in azienda
● Corsi e Workshop
● Eventi online e offline
● questo talk!
Francesco Sciuti

Le illustrazioni sono della mia amica elena pianta
https://elenapianta.it - info@elenapianta.it

grazie a tutti!
● https://www.facebook.com/francesco.sciuti
● https://www.linkedin.com/in/francescosciuti/
● https://twitter.com/FrancescoSciuti
● https://www.facebook.com/Devmy.it
● https://www.linkedin.com/company/devmyfactory/
● https://twitter.com/DevmyFactory
● https://www.instagram.com/Devmy.it/
● https://www.youtube.com/c/devmy
Francesco Sciuti

lasciami un feedback!
Francesco Sciuti

Siamo tutti bravi con il browser degli altri!

More Related Content

Similar to Siamo tutti bravi con il browser degli altri! (20)

More from Francesco Sciuti (10)

Siamo tutti bravi con il browser degli altri!