{"id":527,"date":"2015-04-14T20:59:26","date_gmt":"2015-04-14T18:59:26","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/pianificazione-per-la-performance\/"},"modified":"2015-04-14T20:59:26","modified_gmt":"2015-04-14T18:59:26","slug":"pianificazione-per-la-performance","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/pianificazione-per-la-performance\/","title":{"rendered":"Pianificazione per la performance"},"content":{"rendered":"
\n

Nota degli editori:<\/strong> Siamo lieti di condividere un estratto dal Capitolo 3 del nuovo libro di Scott Jehl, Responsible Responsive Design<\/cite>, disponibile presso A Book Apart<\/a>.<\/p>\n<\/div>\n

\n

Voglio che tu ti chieda, quando stai creando qualcosa, quando stai facendo prototipi delle interazioni, sto pensando al mio orologio o a quello dell’utente?<\/p><\/blockquote>\n

Paul Ford, \u201c10 Timeframes\u201d<\/a><\/p>\n

Non stiamo facendo un buon lavoro<\/h2>\n

Sulle moderne reti mobile sono ancora comuni i tempi di page load nell’ordine dei dieci secondi e questo tempo \u00e8 solo una frazione di quanto in effetti ci vuole per caricare una pagina in paesi con reti pi\u00f9 vecchie e limitate? Perch\u00e9 \u00e8 cos\u00ec lento? Perlopi\u00f9 \u00e8 colpa nostra: i nostri siti sono troppo pesanti e spesso vengono assemblati e inviati in maniera da non sfruttare il modo in cui funzionano i browser. Secondo HTTP Archive<\/a>, in media, un sito web pesa 1.7 megabytes (probabilmente adesso sono un po’ pi\u00f9 pesanti, quindi vi conviene ricontrollare). A peggiorare le cose, la maggior parte dei siti esaminati da HTTP Archive non sono nemmeno responsive, ma sono focalizzati su un particolare use case: il classico computer desktop con uno schermo grande.<\/p>\n

Sono brutte notizie per i designer responsive (e, ehm, responsabili<\/em>) che hanno come obiettivo quello di supportare molti tipi di device con una singola codebase, piuttosto che concentrarsi su un unico tipo. A dire il vero, molte delle critiche mosse al responsive design riguardano l’eccessiva dimensione di file dei siti responsive, come il bellissimo Airbrake MX site<\/a> di Oakley, che originariamente fu lanciato con una dimensione di file pari a 80 megabyte (sebbene poi sia stato ottimizzato per essere pi\u00f9 responsabile), o la homepage piena di media di Disney, che manda un sito responsive da 5 megabyte a tutti i device.<\/p>\n

Perch\u00e9 alcuni siti responsive sono cos\u00ec grossi? Cercare di supportare tutti i browser e i device con una sola codebase sicuramente ha come conseguenza quella di far aumentare la dimensione dei file se non si prendono misure per impedirlo. La natura veramente responsive del design implica l’invio di codice che \u00e8 pronto per rispondere a condizioni che possono verificarsi oppure no, e l’invio di codice solo quando e dove \u00e8 necessario pone degli ostacoli insidiosi stando allo stato degli strumenti attualmente a nostra disposizione.<\/p>\n

Non temete!<\/h3>\n

Si pu\u00f2 ottenere un responsive design responsabile anche per i siti pi\u00f9 complessi e pieni di contenuto, ma non succede automaticamente. Inviare siti responsive veloci richiede una concentrazione precisa sui nostri sistemi di delivery, perch\u00e9 il modo in cui inviamo e applichiamo i nostri asset ha un impatto enorme sulla performance percepita ed effettiva del page load. In effetti, il modo in cui inviamo<\/em> il codice \u00e8 pi\u00f9 importante di quanto pesi il nostro codice.<\/p>\n

Inviare responsabilmente \u00e8 difficile, quindi questo capitolo approfondir\u00e0 molto e in maniera pratica come ottimizzare gli asset responsive per l’invio finale sulla rete. Tuttavia, per prima cosa, faremo un giro nell’anatomia del processo di caricamento e di miglioramento per vedere come il codice client-side viene richiesto, caricato e reso a video e dove tendono a capitare i colli di bottiglia della performance e dell’usabilit\u00e0.<\/p>\n

Pronti? Facciamo un rapido giro del processo del caricamento di una pagina (page load).<\/p>\n<\/div>\n

\n

Una passeggiata lungo il percorso critico<\/h2>\n

Comprendere come i browser richiedano e carichino gli asset di una pagina ci aiuta molto nel prendere decisioni responsabili su come inviare il codice e accelera i tempi di caricamento per i nostri utenti. Se dovessimo registrare gli eventi che accadono dal momento in cui una pagina viene richiesta a quello in cui la pagina \u00e8 utilizzabile, otterremmo quello che nella community della web performance \u00e8 noto come critical path (o percorso critico)<\/em>. In qualit\u00e0 di web developers \u00e8 compito nostro accorciare il pi\u00f9 possibile questo percorso.<\/p>\n

Anatomia semplificata di una richiesta<\/h3>\n

Per dare il via al nostro “tour de HTTP”, cominciamo con le fondamenta di tutto quello che accade sul web: lo scambio di dati tra un browser e un web server. Tra il momento in cui il nostro utente preme “go” e quello in cui il sito comincia a caricare, una “initial request” comincia a fare ping avanti e indietro tra il browser e un Domain Name Server<\/em> locale (che traduce l’URL in un indirizzo IP utilizzato per trovare un host), o DNS, verso l’host server (fig. 3.1).<\/p>\n

\"Schema<\/p>\n

Fig. 3.1: Le fondamenta di una connessione web.<\/p>\n<\/div>\n

In breve, questa praticamente \u00e8 la base per i device che accedono al web su Wi-Fi (o mediante un vecchio cavo Ethernet). Un device connesso a una rete mobile fa uno step ulteriore: per prima cosa, il browser invia la richiesta a una cella telefonica locale, che inoltra la richiesta al DNS per dare il via a un loop browser-server. Anche su una velocit\u00e0 di connessione popolare come il 3G, quella connessione impiega secoli in termini di computer. Come risultato, stabilire una connessione mobile verso un server remoto pu\u00f2 rimanere indietro rispetto al Wi-Fi di due secondi o pi\u00f9 (fig. 3.2).<\/p>\n

\"Schema<\/p>\n

Fig. 3.2: Mobile? Prima alla cella! …che impiega in media due secondi su 3G<\/a>.<\/p>\n<\/div>\n

Due secondi possono sembrare pochi, ma considerate che gli utenti possono individuare, e sono annoiati da, ritardi nella performance di 300 millisecondi. Quel ritardo cruciale di due secondi implica che il mobile web \u00e8 intrinsecamente pi\u00f9 lento della sua controparte Wi-Fi.<\/p>\n

Fortunatamente, le moderne connessioni LTE e 4G alleviano sensibilmente questa pena e stanno lentamente guadagnando popolarit\u00e0 nel mondo. Non potendo per\u00f2 fare affidamento sulla velocit\u00e0 della rete, \u00e8 meglio assumere che non sar\u00e0 veloce. In entrambe i casi, una volta che la connessione al server \u00e8 stabilita, le richieste per i file possono fluire senza ritardi nella connessione alla cella.<\/p>\n<\/div>\n

\n

Richieste, richieste, richieste!<\/h2>\n

Supponiamo che il nostro browser richieda un file HTML. Man mano che il browser riceve pezzi di testo di quel file HTML dal server, ne fa un parsing procedurale, cercando riferimenti ad asset esterni che devono essere richiesti e converte l’HTML in una struttura ad albero di elementi HTML nota come Document Object Model<\/em>, o DOM. Una volta che \u00e8 stata creata la struttura DOM, i metodi JavaScript possono attraversarla e manipolare programmaticamente gli elementi nel documento e il CSS pu\u00f2 dare uno stile visuale agli elementi nel modo in cui vogliamo.<\/p>\n

Le complessit\u00e0 del parsing HTML (e le sue variazioni tra i browser) potrebbero riempire un libro. Per timore che questo mio libro si trasformi in quello, sar\u00f2 breve: la cosa importante \u00e8 comprendere l’ordine fondamentale delle operazioni quando un browser fa il parsing e rende l’HTML.<\/p>\n

    \n
  • Per esempio, CSS funziona meglio quando tutti gli stili rilevanti al layout iniziale della pagina vengono caricati e analizzati prima<\/em> che un documento HTML venga reso visivamente su uno schermo.<\/li>\n
  • Di contro, il comportamento di JavaScript \u00e8 spesso in grado di essere applicato agli elementi della pagina dopo<\/em> che questi sono stati caricati e resi a video.<\/li>\n<\/ul>\n

    Tuttavia, sia JavaScript sia CSS presentano degli ostacoli sul percorso critico, impedendo alla nostra pagina di apparire mentre essi vengono caricati ed eseguiti. Approfondiamo un pochino l’ordine di queste operazioni.<\/p>\n

    Rendering e blocking<\/h3>\n

    Il documento HTML con il caricamento pi\u00f9 rapido \u00e8 quello che non ha files esterni, ma \u00e8 anche quello che non troverete di solito. Un documento HTML tipico fa riferimento ad un sacco di asset esterni come CSS, JavaScript, font e immagini.<\/p>\n

    Spesso, si trovano i CSS e JavaScript nella head<\/code> del documento HTML rispettivamente come elementi link<\/code> e script<\/code>. Di default, i browser aspettano a rendere il contenuto di una pagina fino a che questi asset non hanno finito il caricamento e il parsing, comportamento noto come blocking<\/em> (fig. 3.3). Di contro, le immagini sono asset non-blocking, dal momento che i browser non aspettano che una immagini si carichi prima di essere visualizzata nella pagina.<\/p>\n

    \"Schema<\/p>\n

    Fig. 3.3: Richieste CSS e JavaScript bloccanti durante il page load.<\/p>\n<\/div>\n

    Nonostante il suo nome, il blocking rendering per CSS in effetti contribuisce al caricamento consistente dell’interfaccia. Se caricate una pagina prima che sia disponibile il suo CSS, vedrete una pagina di default senza stili; quando il CSS finisce il caricamento e viene applicato dal browser, il contenuto della pagina si risistema nel nuovo layout con gli stili. Questo processo in due fasi \u00e8 chiamato flash of unstyled content<\/em>, o FOUC, e pu\u00f2 essere estremamente irritante per gli utenti. Quindi, bloccare il rendering di una pagina fino a che il CSS non \u00e8 pronto \u00e8 sicuramente auspicabile purch\u00e9 il CSS si carichi in un breve lasso di tempo, obiettivo che non sempre si raggiunge facilmente.<\/p>\n

    Il valore del blocking per quel che riguarda JavaScript mina quasi sempre la user experience ed \u00e8 pi\u00f9 una risposta a un metodo JavaScript persistente chiamato document.write<\/code>, utilizzato per fare inject di HTML direttamente nella pagina in qualunque posizione stia facendo il parsing il browser. Solitamente \u00e8 considerata una “bad practice” usare document.write<\/code> ora che ci sono a disposizione metodi pi\u00f9 disgiunti in JS, ma document.write<\/code> \u00e8 ancora utilizzato, particolarmente dagli script che includo le pubblicit\u00e0. Il problema maggiore con document.write<\/code> \u00e8 che se gira dopo che una pagina ha finito il caricamento, sovrascrive l’intero documento con il contenuto che d\u00e0 in output. \u00c8 pi\u00f9 un document.wrong<\/code>, giusto? (Scusatemi). Sfortunatamente, un browser non ha modo di sapere se uno script che sta richiedendo contenga una chiamata a document.write<\/code>, quindi il browser tende ad andare sul sicuro ed assumere che la contenga. Mentre il blocking previene una potenziale cancellazione dello schermo, forza anche gli utenti ad attendere gli script prima di poter accedere alla pagina, anche se gli script non avrebbero causato problemi. Evitare l’uso di document.write<\/code> \u00e8 un passo importante che possiamo fare per gestire questa problematica in JavaScript.<\/p>\n

    Nel prossimo capitolo, vedremo dei modi per caricare gli script che evitano questo comportamento bloccante di default e che come risultato hanno il miglioramento della performance percepita.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

    Dovremmo costruire siti che non sono solo responsive, ma sostenibili, accessibili globalmente e, beh, responsabili, come suggerisce Scott Jehl nel suo nuovo libro, Responsible Responsive Design. I nostri approcci ai siti web responsive devono considerare device in continua mutazione, reti limitate e contesti inaspettati. In questo estratto dal Capitolo 3, Scott discute i tempi di page load e la consegna responsabile del codice.<\/p>\n","protected":false},"author":818,"featured_media":7000758,"comment_status":"open","ping_status":"open","template":"","categories":[247,273,126,274],"tags":[],"coauthors":[442],"class_list":["post-527","article","type-article","status-publish","has-post-thumbnail","hentry","category-html","category-mobile-multidevice","category-numero-109-14-aprile-2015","category-responsive-design"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/527","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/users\/818"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=527"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000758"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=527"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=527"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=527"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=527"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}