![](\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2014\/09\/sketch302222419.png\")
Tutti noi vogliamo che i nostri siti siano veloci. Ottimizziamo le immagini, creiamo le sprite CSS, usiamo i CDN, facciamo caching aggressivo, usiamo gzip e minimizziamo il contenuto statico. Usiamo tutti i trucchi da manuale.<\/p>\nTutti noi vogliamo che i nostri siti siano veloci. Ottimizziamo le immagini, creiamo le sprite CSS, usiamo i CDN, facciamo caching aggressivo, usiamo gzip e minimizziamo il contenuto statico. Usiamo tutti i trucchi da manuale.<\/p>\n
Ma possiamo fare ancora di pi\u00f9. Se vogliamo dei risultati pi\u00f9 rapidi, dobbiamo pensare in maniera diversa. E se, invece di lasciare i nostri utenti a fissare una spinning wheel aspettando che venga consegnato il contenuto, potessimo predire dove vorrebbero andare dopo? E se potessimo avere quel contenuto pronto per loro ancora prima che lo chiedano?<\/p>\n
Tendiamo a vedere il web come un modello reattivo, in cui ogni azione causa una reazione. Gli utenti cliccano e poi noi li portiamo a una nuova pagina. Cliccano di nuovo e noi apriamo un’altra pagina. Ma possiamo fare di meglio. Possiamo essere proattivi con il prebrowsing.<\/p>\n
Steve Souders ha coniato il termine prebrowsing (da predictive browsing<\/em>) in uno dei suoi articoli<\/a> alla fine dello scorso anno. Il prebrowsing consiste nell’anticipare dove gli utenti vogliono andare e nel preparare quel contenuto in anticipo. \u00c8 un grande passo verso un internet pi\u00f9 veloce e meno visibile.<\/p>\n I browser possono analizzare i pattern per prevedere dove gli utenti andranno successivamente e dare inizio alla risoluzione del DNS e ai TCP handshakes non appena gli utenti passano sopra ai link. Ma per ottenere il massimo da questi miglioramenti, possiamo abilitare il prebrowsing sulle nostre pagine web con tre tecniche a nostra disposizione:<\/p>\n Esaminiamo ciascuna di queste separatamente.<\/p>\n<\/div>\n Ogni volta che sappiamo che i nostri utenti probabilmente richiederanno una risorsa da un dominio diverso da quello del nostro sito, possiamo usare il DNS prefetching per riscaldare i motori delle macchine che apriranno il nuovo URL. Il browser pu\u00f2 pre-risolvere in anticipo il DNS per il nuovo dominio, facendo risparmiare diversi millisecondi quando l’utente effettivamente lo richieder\u00e0. Stiamo giocando d’anticipo e preparandoci per un’azione.<\/p>\n I browser moderni sono molto bravi nel fare il parsing delle pagine, guardando avanti per pre-risolvere tutti i domini necessari in anticipo. Chrome si spinge cos\u00ec in l\u00e0 da tenere un elenco con tutti i domini collegati ogni volta che un utente visita un sito, li pre-risolve quando l’utente ritorna (potete vedere questo elenco navigando su chrome:\/\/dns\/ nel vostro browser Chrome). Tuttavia, a volte l’accesso ai nuovi URL pu\u00f2 essere nascosto dietro ai redirect o incorporato in JavaScript e qui sta la nostra opportunit\u00e0 per aiutare il browser.<\/p>\n Diciamo che stiamo scaricando un insieme di risorse dal dominio cdn.example.com usando una chiamata JavaScript dopo che un utente ha cliccato un pulsante. Normalmente, il browser dovrebbe risolvere il DNS nel momento del click, ma noi possiamo accelerare il processo includendo una direttiva Facendo cos\u00ec si informa il browser dell’esistenza del nuovo dominio ed esso combiner\u00e0 questo suggerimento con il suo algoritmo di pre-risoluzione per dare inizio alla risoluzione del DNS il prima possibile. L’intero processo sar\u00e0 pi\u00f9 veloce per l’utente dal momento che stiamo eliminando dall’operazione il tempo necessario per la risoluzione del DNS. (Si noti che i browser non garantiscono che la risoluzione del DNS avvenga in anticipo: usano semplicemente il nostro suggerimento come un segnale per il proprio algoritmo interno di pre-risoluzione.)<\/p>\n Ma esattamente, quanto rende pi\u00f9 rapide le cose la pre-risoluzione del DNS? Nel vostro browser Chrome, aprite chrome:\/\/histograms\/DNS e cercate DNS.PrefetchResolution. Vedrete una tabella come questa:<\/p>\n Questo istogramma mostra la mia personale distribuzione di latenze per le richieste di DNS prefetch. Sul mio computer, per 335 campioni, il tempo medio \u00e8 88 millisecondi, con una media di circa 60 millisecondi. Eliminare 88 millisecondi da tutte le richieste che il nostro sito fa verso un dominio esterno? \u00c8 qualcosa da celebrare!<\/p>\n Ma cosa succede se l’utente non clicca mai sul pulsante per accedere al dominio cdn.example.com? Non stiamo pre-risolvendo inutilmente un dominio? Lo stiamo facendo, ma fortunatamente per noi, il DNS prefetching \u00e8 un’operazione davvero a basso costo: il browser dovr\u00e0 mandare solo poche centinaia di byte sulla rete, quindi il rischio che ci assumiamo facendo una ricerca DNS preventiva \u00e8 molto basso. Detto ci\u00f2, non eccedete nell’uso di questa feature: fate il prefetch solo dei domini di cui siete piuttosto sicuri che l’utente vorr\u00e0 accedervi e lasciate che il browser gestisca il resto.<\/p>\n Cercate situazioni che possano essere ottime candidate per l’introduzione del DNS prefetching sul vostro sito:<\/p>\n Il DNS prefetching \u00e8 attualmente supportato su IE11<\/a>, Chrome<\/a>, Chrome Mobile, Safari, Firefox<\/a> e Firefox Mobile, il che rende molto diffusa questa feature tra i browser attuali. I browser che attualmente non supportano il DNS prefetching ignoreranno semplicemente il suggerimento e la risoluzione del DNS avver\u00e0 in maniera regolare.<\/p>\n<\/div>\n Possiamo spingerci un po’ pi\u00f9 in l\u00e0 e prevedere che i nostri utenti apriranno una pagina specifica del nostro sito. Se conosciamo alcune delle risorse critiche utilizzate da questa pagina, possiamo istruire il browser a fare il prefetch di queste in anticipo:<\/p>\n Il browser user\u00e0 questa istruzione per fare il prefetch delle risorse indicate e le memorizzer\u00e0 nella cache locale. In questo modo, non appena le risorse saranno in effetti necessarie, il browser le avr\u00e0 l\u00ec pronte da mandare.<\/p>\n A differenza del DNS prefetching, il resource prefetching \u00e8 un’operazione pi\u00f9 costosa: state attenti a come e dove la utilizzate. Il prefetch delle risorse pu\u00f2 accelerare i nostri siti in modi che non otteremo mai semplicemente facendo il prefetch dei nuovi domini, ma se ne abusiamo, i nostri utenti pagheranno un overhead per qualcosa che non useranno.<\/p>\n Diamo un’occhiata alla dimensione della risposta media di alcune tra le pi\u00f9 popolari risorse su una pagina web, cortesemente offerte da HTTP Archive<\/a>:<\/p>\n In media, fare il prefetch di un file di script (come facciamo nell’esempio di cui sopra) causer\u00e0 la trasmissione di 16kB sulla rete (senza includere la dimensione della richiesta stessa). Questo significa che risparmieremo dal processo 18kB dal tempo di download, pi\u00f9 il tempo di risposta del serve, che \u00e8 stupefacente, sempre che l’utente vi acceda poi dopo. Se l’utente non accede mai al file, potremmo in effetti rendere l’intero workflow pi\u00f9 lento introducendo un delay non necessario.<\/p>\n Se decidete di usare questa tecnica, fate il prefetch solo delle risorse pi\u00f9 importanti e assicuratevi che il browser le possa mettere in cache. Di solito, le immagini, i CSS, i JavaScript e i files dei font sono buoni candidati per il prefetching, ma le HTML response non lo sono dal momento che non le si pu\u00f2 mettere in cache.<\/p>\n Ecco alcune situazioni in cui, data la probabilit\u00e0 che l’utente visiti una pagina specifica, potete fare in anticipo il prefetch delle risorse:<\/p>\n Il resource prefetching attualmente \u00e8 supportato in IE11<\/a>, Chrome<\/a>, Chrome Mobile, Firefox<\/a> e Firefox Mobile. (Per determinare la compatibilit\u00e0 del browser potete fare un testare velocemente il browser su prebrowsing.com<\/a>.)<\/p>\n<\/div>\n Perch\u00e9 non ci spingiamo oltre e chiediamo un’intera pagina? Supponiamo di essere totalmente<\/em> sicuri che i nostri utenti visiteranno la pagina about.html del nostro sito. Possiamo dare questo suggerimento al browser:<\/p>\n Questa volta il browser scaricher\u00e0 in anticipo e visualizzer\u00e0 la pagina in background, cos\u00ec da averla pronta per l’utente non appena la chieder\u00e0. La transizione dalla pagina corrente a quella pre-visualizzata sarebbe istantanea.<\/p>\n Non \u00e8 necessario dire che il prerendering \u00e8 la tecnica pi\u00f9 rischiosa e costosa delle tre. Farne cattivo uso pu\u00f2 causare grossi sprechi di banda specialmente dannosi per gli utenti sui dispositivi mobile. Per illustrare ci\u00f2, diamo un’occhiata a questo grafico, ancora per gentile concessione di HTTP Archive<\/a>:<\/p>\n Nel giugno di quest’anno, il numero medio di richieste per rendere una pagina web era 96, con una dimensione totale di 1.808kB. Quindi, se il vostro utente alla fine accede alla pagina pre-visualizzata, allora avrete fatto jackpot: risparmierete il tempo di download di quasi 2.000kB, pi\u00f9 il tempo di risposta del server. Ma se vi sbagliate e il vostro utente non accede mai alla pagina pre-visualizzata, gli farete pagare un prezzo molto alto.<\/p>\n Quando dovete decidere se fare in anticipo il prerendering di intere pagine, considerate che Google fa il prerendering dei primi risultati delle sue pagine di ricerca e che Chrome fa la pre-visualizzazione delle pagine basandosi sui pattern della cronologia di navigazione degli utenti. Usando lo stesso principio, potete determinare i pattern di uso comuni e di conseguenza fare il prerender di alcune pagine selezionate. Potete anche usarlo, proprio come il resource prefetching, nei questionari e nei sondaggi in cui sapete che gli utenti completeranno il workflow seguendo un ordine particolare.<\/p>\n Al momento, il prerendering \u00e8 supportato solo in IE11<\/a>, Chrome<\/a> e Chrome Mobile. N\u00e9 Firefox n\u00e9 Safari hanno ancora aggiunto il supporto per questa tecnica (e, come per il resource prefetching, potete controllare prebrowsing.com<\/a> per verificare se questa tecnica sia supportata nel vostro browser).<\/p>\n<\/div>\n Siti come Google<\/a> e Bing<\/a> utilizzano ampiamente queste tecniche per rendere istantanee le ricerche per i propri utenti. Adesso \u00e8 ora che torniamo sui nostri siti e li esaminiamo di nuovo. Possiamo rendere migliori e pi\u00f9 rapide le nostre esperienze con il prefetching e il prerendering?<\/p>\n I browser stanno gi\u00e0 lavorando dietro le quinte per rendere la navigazione quanto pi\u00f9 veloce possibile, cercando dei pattern nei nostri siti. Il prebrowsing poggia su queste fondamenta: possiamo combinare i dati che abbiamo derivanti dalle nostre pagine con ulteriori analisi dei pattern degli utenti. Aiutando i browser a fare un lavoro migliore, acceleriamo e miglioriamo l’esperienza dei nostri utenti.<\/p>\n Illustrazioni: {carlok}<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":" Vogliamo siti web pi\u00f9 veloci e i browser ci aiutano a raggiungere questo obiettivo, ricercando pattern di navigazione degli utenti, analizzandone i comportamenti e facendo supposizioni su dove potrebbero cliccare successivamente. Ma noi conosciamo meglio sia i nostri siti sia i nostri utenti e possiamo usare questi dati per far lavorare i browser in maniera proattiva. Il predictive browsing mette in coda le risorse ancora prima che gli utenti le richiedano, creando un’esperienza pi\u00f9 veloce e senza intoppi. Santiago Valdarrama esamina costi e benefici di tre tecniche a nostra disposizione per il prebrowsing.<\/p>\n","protected":false},"author":818,"featured_media":7000744,"comment_status":"open","ping_status":"open","template":"","categories":[242,247,118],"tags":[],"coauthors":[430],"class_list":["post-492","article","type-article","status-publish","has-post-thumbnail","hentry","category-browser","category-html","category-numero-101-1-ottobre-2013"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/492","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=492"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000744"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=492"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=492"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=492"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=492"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
\nDNS prefetching<\/h2>\n
dns-prefetch<\/code> nella sezione head<\/code> della nostra pagina:<\/p>\n<link rel=\"dns-prefetch\" href=\"http:\/\/cdn.example.com\"><\/code>\n<\/pre>\n![\"Istogramma](\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2014\/09\/fig1-o.jpg\")
<\/div>\n\n
\nResource prefetching<\/h2>\n
<link rel=\"prefetch\" href=\"http:\/\/cdn.example.com\/library.js\"><\/code>\n <\/pre>\n![\"Grafico](\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2014\/09\/fig2-o.jpg\")
<\/div>\n\n
\nPrerendering<\/h2>\n
<link rel=\"prerender\" href=\"http:\/\/example.com\/about.html\"><\/code>\n <\/pre>\n![\"Grafico](\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2014\/09\/fig3-o.jpg\")
<\/div>\n\nConclusioni<\/h2>\n