HPN #01: le performance di Chrome

Di - 4 March 2013 - in
Post image for HPN #01: le performance di Chrome

Nella scorsa puntata abbiamo introdotto questa nuova guida, chiamata High Performance Networking, che ci permetterà di comprendere come far interagire al meglio le nostre applicazioni con Google Chrome. Quello che abbiamo fatto finora è una semplice panoramica di quelli che sono da sempre i principi cardine del browser di Mountain View, i quali devono poi essere anche i pilastri portanti delle nostre applicazioni. In questo episodio cominciamo ad addentrarci nello specifico di ciò che ci interessa principalmente: le prestazioni. Cominciamo dunque cercando di capire come Google Chrome ci assicura delle performance notevoli.

In primo luogo bisogna dire che i browser di oggi sono delle vere e proprie piattaforme, simili ad un sistema operativo, mentre nel passato erano delle applicazioni monolitiche che rappresentavano un singolo processo. Questo portava con sé delle problematiche di fondo piuttosto critiche: ogni pagina aperta condivideva lo stesso spazio e le stesse risorse di tutte le altre. Di conseguenza, un bug presente in una di queste pagine o nel browser stesso aveva la potenzialità di compromettere l’intera esperienza.

Con l’avvento di Google Chrome le cose sono cambiate, perché è nato un browser che si basa su un modello a processi multipli, ognuno dei quali utilizza un frammento di memoria proprio e non condivide le risorse con gli altri. In Chrome, inoltre, ogni scheda ha una propria sandbox di sicurezza che la isola dalle altre. Nel caso in cui sia presente un bug in una scheda quindi, esso non può compromettere anche tutte le altre. C’è un altro aspetto da considerare: negli ultimi anni si è cominciato ad utilizzare processori multicore, che per essere sfruttati al meglio necessitano di una suddivisione dei processi. Già questo modello di base ha conferito a Chrome delle prestazioni che l’hanno fatto spiccare sugli altri browser, i quali hanno cominciato ad utilizzare la stessa architettura o stanno per farlo.

Facciamo ora un ulteriore passo avanti per capire come il browser interpreta ed esegue un’applicazione web. Possiamo fare una principale suddivisione in tre passi:

  • fetch delle risorse;
  • layout e rendering della pagina;
  • esecuzione degli script.

Possiamo subito notare un limite in questi passi: il rendering della pagina e l’esecuzione degli script devono essere eseguiti in due momenti distinti. Ciò è dovuto in primo luogo al fatto che JavaScript in sé è un linguaggio sequenziale e in secondo luogo al fatto che il Document Object Model (DOM) deve essere renderizzato prima di subire qualsiasi modifica, ovviamente. Nonostante ciò, è di primaria importanza ottimizzare i tempi di esecuzione di questi due passi, sia da parte dell’applicazione, sia da parte del browser.

Chrome utilizza WebKit come motore di rendering, il quale è veloce, open source e aderente agli standard. Per JavaScript, invece, utilizza il proprio V8 JavaScript runtime, ottimizzato proprio per Chrome e rilasciato anche come progetto indipendente adottato in altri famosi progetti come node.js.

Un aspetto cruciale è quindi l’ottimizzazione del rendering (ci baseremo su WebKit, essendo questa guida incentrata su Chrome) e dell’esecuzione JavaScript (tramite V8), ma se il fetch delle risorse rappresenta un collo di bottiglia, tutto questo lavoro è inutile.

È importante perciò che il browser sappia ottimizzare l’ordine, la priorità e la latenza di ogni risorsa da caricare, perché questo influisce pesantemente nell’esperienza utente. Anche se non ce ne rendiamo conto, Chrome continua a migliorare da questo punto di vista, cercando di ridurre sempre più il costo di latenza di ogni risorsa: ricerca i DNS più probabili, ricorda la topologia del web, si preconnette alle destinazioni più probabili e molto altro. Dall’esterno il tutto appare come un unico meccanismo di fetch, ma in realtà è un organismo molto complesso che può essere studiato per comprendere come ottimizzare l’esperienza utente delle nostre applicazioni. Ed è quello che andremo a fare, partendo dalla prossima lezione.

Leave a Reply

Mattia Migliorini Articolo scritto da

Studente di informatica presso l’Università di Padova, web designer, amante di Linux e dell’open source in generale.
Membro di Ubuntu e di 2viLUG, da gennaio 2012 è collaboratore di Engeene.

Contatta l'autore

Previous post:

Next post: