Andrea Verlicchi

Claude vs Gemini, i miei casi d'uso

2026-07-27T00:00:00Z

C'è molto hype e si fa molto parlare di Claude ed Anthropic, soprattutto dopo l'annuncio di Fable 5 e, ultimamente, di Opus 5. Lo uso Claude eh, mica dico che non lo uso! Però per molte cose preferisco ancora Gemini 3.6 Flash.

Il motivo è semplice: sebbene la mia azienda abbia adottato Claude in full e ne spinga fortemente l'utilizzo, essendo molto in contatto con Google ed altri sviluppatori Google per via del programma GDE (Google Developer Experts), sento pareri entusiasti anche sul fronte Gemini. Quindi voglio continuare a provarli e utilizzarli entrambi.

Non dico che per me si equivalgano in tutto, ma ci sono casi d'uso ben precisi in cui preferisco l'uno e casi in cui preferisco l'altro. Ecco come li ho divisi nel mio workflow quotidiano:

Claude o Gemini? I due fumetti rappresentano le mie opzioni quotidiane di IA.

Claude in Claude Desktop #

Task complessi e multi-tool: Lunghi task che prevedono lettura e scrittura su più strumenti aziendali, tra cui lo Slack aziendale, Hex, o altri tool di integrazione.

Claude in Claude Code #

Sviluppo di codice complesso: Per task di codice impegnativi (quelli che richiedono un bel po' di ragionamento, come i major release refactoring), mi affido ai modelli Fable 5, Opus 4.8 o Sonnet 5. Spesso questi task prevedono l'integrazione diretta con tool via CLI come GitLab (glab), Google Cloud (gcloud), o i nostri server MCP interni.
Troubleshooting di Git (con Haiku): Per uscire da situazioni complicate con git (ad esempio quando devo prendere gli ultimi commit fatti per errore su main e spostarli in un feature branch, oppure forzare il push su staging ignorando quello che c'era già — non giudicatemi: non ho quasi mai usato git da riga di comando, sono pigro!).

Gemini in Antigravity / Antigravity IDE #

Task di codice mediamente complessi: Per feature medio-grandi utilizzo Gemini 3.6 Flash (high).
DevTools e analisi di performance: Per task che prevedono di utilizzare i DevTools for Agents e magari fare analisi approfondite di performance web, uso Gemini 3.6 Flash (medium).
Manutenzione ed evoluzione del blog: Per lavorazioni varie a questo blog (ad esempio di recente l'ho tradotto interamente in italiano, ho creato skill personalizzate per creare nuovi blog post, etc.), uso Gemini 3.6 Flash (medium/high). Spoiler: questo stesso blog post, compresa l'immagine di copertina, è stato generato proprio con Antigravity e Gemini 3.6 Flash (Medium)!

Gemini (web / desktop) – Account Personale #

Per domande sulla vita, l'universo e tutto quanto (tanto la risposta è sempre 42):

Accoglienza gattini: Come accogliere due cuccioli di gatto non avendo mai avuto animali (una lunga chat ancora attiva dopo un mese!).
Alimentazione e nutrizione: Consigli sull'alimentazione e piano alimentare (diverse chat generate mensilmente con Gem sempre aggiornati, per oltre 1 anno).
Progetti di casa: Dimensionare correttamente un impianto fotovoltaico (chat fissata che mi servirà a breve).

Gemini (web / desktop) – Account Aziendale #

Per domande puramente work-related:

Analisi di codice: Analisi di librerie JS minificate.
Ottimizzazione SQL: Comparazione della complessità e dei costi delle query SQL.
Debugging di errori: Analisi di stack trace o errori Python / JavaScript poco chiari.
Workflow Slack: Richieste su come realizzare automazioni e feature avanzate in Slack (workflows, app, automations).

Gemini (web / desktop) – Entrambi gli account #

Ci sono poi casi d'uso trasversali per cui Gemini è il mio punto di riferimento sia sul profilo personale che aziendale:

Ricerche web persistenti: Ricerche i cui risultati voglio che rimangano salvati in una history accessibile, anziché andare persi per sempre come lacrime nella pioggia.
Analisi di documenti e file: Analisi di file caricati per estrarre informazioni ben organizzate.
Domande tech e configurazioni: Risolvere dubbi tecnici, come configurare strumenti o far comunicare servizi tra loro, oppure capire come funzionano internamente alcuni aspetti dei modelli AI.
Brainstorming e presentazioni: Discussione e generazione di idee su come preparare una presentazione.

In conclusione: non esiste un unico modello "vincitore" assoluto per ogni esigenza. Sperimentare con entrambi permette di sfruttare il meglio di ciascun ecosistema e di adattare lo strumento giusto al task specifico!

Dovremmo smettere di usare la parola "Responsive" per il design?

2026-07-07T00:00:00Z

Nel lontano 2010, Ethan Marcotte ha coniato il termine Responsive Web Design. Da allora, abbiamo usato "responsive" per descrivere un sito web che adatta il suo layout alle dimensioni del viewport. Griglie fluide, immagini flessibili, media queries.

Dovremmo usare "adattivo" per i layout e "responsive" per le performance?

Per un certo periodo abbiamo cercato di separarlo dal design "adattivo" (adaptive). A quel tempo, i siti web "adattivi" avevano una cattiva reputazione perché di solito si affidavano al rilevamento del dispositivo lato server (device detection) e allo sniffing dello user-agent per servire codice HTML e CSS completamente diverso al browser. Poiché lo sniffing UA era fragile, la community web ha voluto prenderne le distanze. Il modello responsive di Ethan serviva lo stesso identico codice a tutti, lasciando che fosse il browser a fare il lavoro. Il termine "Responsive" ha vinto la guerra del vocabolario, e "adattivo" è diventato associato a layout obsoleti rilevati dal server.

Ma arriviamo a oggi: questi termini si sono divisi in modi che causano una reale confusione.

La definizione mobile di "adaptive" (Android e iOS) #

Se guardiamo allo sviluppo di app mobili moderne — sia su Android che su iOS — la parola "adaptive" (adattivo) è lo standard.

Google la usa massicciamente per il design delle app Android. Con la diffusione di smartphone pieghevoli e tablet, le app non possono semplicemente allargarsi per riempire lo schermo. Hanno bisogno di ristrutturare completamente il proprio layout. Nella loro guida sui layout adattivi, il focus è interamente sui layout "adaptive" (ovvero che cambiano la struttura del layout in base a breakpoint e stati di piegatura del dispositivo), mentre i concetti "responsive" (come il dimensionamento fluido) sono visti solo come una base di partenza.

Apple segue una logica simile. Nelle loro Human Interface Guidelines per il Layout, inquadrano gli aggiustamenti di layout attorno al concetto di "Adaptability" (Adattabilità) piuttosto che di "Responsiveness". Guidano gli sviluppatori a creare interfacce che si adattano perfettamente a diversi dispositivi, dimensioni di schermo e orientamenti usando classi di dimensione (size classes) e strutture adattive.

Quindi, nel mondo delle app mobili, l'adattamento alle dimensioni dello schermo viene costantemente chiamato design adaptive.

La definizione di "responsiveness" nelle performance web #

Allo stesso tempo, nel mondo delle performance web — dove trascorro molto del mio tempo — la parola "responsive" ha assunto un significato completamente diverso.

Quando gli ingegneri delle performance dicono di voler rendere una pagina "responsive", non parlano affatto di viewport o media query. Parlano di interattività. Nello specifico, di quanto velocemente il browser reagisce agli input dell'utente.

Con la metrica di Google Interaction to Next Paint (INP), la "responsiveness" viene misurata in millisecondi. Se un utente tocca un bottone e la pagina si blocca per 300 ms, quel sito web ha una scarsa reattività (responsiveness).

La collisione terminologica #

Questo ha creato un bel pasticcio.

Se un product manager dice: "Dobbiamo rendere questo sito web più responsive." Cosa intende esattamente?

Dobbiamo modificare le nostre media query CSS per i dispositivi pieghevoli e i tablet?
Oppure dobbiamo spezzare i task JavaScript lunghi per migliorare il nostro INP?

Stiamo usando la stessa identica parola per indicare sia "si adatta alle dimensioni dello schermo" che "reagisce velocemente agli input dell'utente".

E questa confusione è destinata a crescere. Se parli con sviluppatori appena entrati nel settore, o se chiedi a un assistente di programmazione IA di "rendere questa UI più responsive", cosa faranno in realtà? Inizieranno a scrivere regole @media in CSS o apriranno i Chrome DevTools per profilare i tempi di blocco del thread principale (main thread)? Onestamente, entrambe le strade rappresentano un'interpretazione valida della parola.

Una proposta: dividere la terminologia #

Forse è giunto il momento di abbandonare la parola "responsive", almeno quando parliamo di dimensioni dello schermo.

E se iniziassimo a usare "adaptive" per tutto ciò che riguarda l'adattamento del layout (sia sul web che nelle app native), e riservassimo "responsive" puramente alle performance web?

Secondo questo modello:

Un sito o un'app adaptive (adattivo) adatta il proprio layout al viewport (mobile, desktop, pieghevole).
Un sito o un'app responsive (reattivo) risponde velocemente alle interazioni dell'utente (basso INP, nessun blocco del thread principale).

Per dirla in parole semplici, se dovessi spiegare questo concetto a mia madre, direi che un layout si adatta alle dimensioni dello schermo, non che "risponde" ad esse. È un modo di descriverlo decisamente più naturale.

Sembra più pulito, più logico e risolve la sovrapposizione terminologica. Ma la web community è pronta ad abbandonare la definizione del 2010 di Ethan Marcotte? O il "responsive design" è impresso troppo a fondo nei nostri cervelli?

Sono curioso di sapere cosa ne pensi. Questa distinzione ha senso o è troppo tardi per cambiare? Scrivimi pure per farmi sapere cosa ne pensi!

Talk: "Ehi Gemini, sistema il CSS!" al CSS Day Bologna

2026-06-11T00:00:00Z

Talk: "Ehi Gemini, sistema il CSS!" al CSS Day Bologna

Giovedì 11 giugno 2026, ho avuto il piacere di tenere una presentazione alla conferenza CSS Day a Bologna.

Vi siete mai chiesti quanto tempo perdiamo ogni giorno a fare clic con il tasto destro su "Ispeziona", cambiare la dimensione del viewport 50 volte o andare a caccia di quella singola regola CSS che sovrascrive i nostri stili? I tradizionali assistenti di programmazione IA sono eccezionali, ma sono "ciechi" rispetto all'ambiente live del browser: non possono vedere il DOM in memoria, il traffico di rete o gli errori in console.

In questo talk del CSS Day, esploriamo Chrome DevTools for Agents (noto anche come DTA), uno strumento rilasciato in versione 1.0 a maggio durante il Google I/O. Grazie al Model Context Protocol (MCP), questo tool espone le funzionalità native di DevTools direttamente agli agenti IA (come Gemini, Claude Code, Cursor o Antigravity).

Il risultato? L'IA può navigare, ispezionare fogli di stile, compilare moduli ed eseguire un vero e proprio debugging per nostro conto.

Guarda il video #

Slide #

Puoi scaricare o visualizzare le slide della presentazione qui: 🔗 Scarica le slide della presentazione (PDF)

Google Antigravity 2 & Gemini 3.5 Flash: questa accoppiata IA ha cambiato il mio flusso di sviluppo... di nuovo

2026-05-22T00:00:00Z

Sono passati solo pochi giorni da quando ho iniziato a usarlo, ma sono già incredibilmente entusiasta. La velocità, la precisione, il processo di pianificazione e i risultati finali ottenuti sono semplicemente eccezionali.

Google Antigravity 2 è arrivato, ed è una svolta totale.

Facciamo un passo indietro. Antigravity 1 era essenzialmente una shell di VS Code con una chat integrata. Sembrava molto simile alla combinazione VS Code + Copilot, ma con un tocco estremamente interessante: la Planning Mode (Modalità di Pianificazione). Prima di eseguire qualsiasi modifica, la chat si metteva in pausa, rifletteva su ciò che aveva capito, mostrava un piano di implementazione dettagliato passo dopo passo e chiedeva una conferma esplicita. Era molto simile alla modalità di pianificazione di Claude, ma confezionata in un'interfaccia utente molto più pulita, facile da leggere e commentabile.

Con Antigravity 2, hanno fatto un passo audace. Hanno rimosso completamente la modalità editor di codice (o l'hanno nascosta così bene che non l'ho ancora trovata!). Al suo posto, c'è un'interfaccia di chat pura e priva di distrazioni, focalizzata interamente sul flusso di lavoro agentico, mantenendo del tutto intatta quella meravigliosa e comoda Planning Mode della versione 1.

Flussi di lavoro multi-progetto senza interruzioni #

Ciò che rende Antigravity 2 così potente è il modo in cui opera in background:

Supporto multi-progetto: Funziona perfettamente su tutti i progetti attivi nel tuo workspace.
Chat parallele: Ogni progetto può avere più chat concorrenti in esecuzione in parallelo.
Git Worktree: Ogni chat indipendente può essere eseguita direttamente sul tuo branch locale o all'interno del proprio Git worktree dedicato, consentendo all'agente di scrivere codice ed eseguire build in isolamento senza bloccare il tuo tree di lavoro principale.

Consiglio di usarlo affiancato al tuo IDE tradicional preferito. Nel mio lavoro quotidiano, passo costantemente da Antigravity 2 a JetBrains PyCharm. Uso Antigravity per eseguire i compiti degli agenti, pianificare il refactoring e modificare il codice, e poi passo a PyCharm per avviare, testare e gestire tutto il resto proprio come facevo prima. È lo spazio di lavoro ibrido perfetto.

Sotto il cofano: Gemini 3.5 Flash è una bomba #

Antigravity 2 supporta sia Gemini 3.5 che Claude. Se hai un account Google, ottieni un generoso piano gratuito di Gemini 3.5 incluso fin da subito, che consiglio vivamente di provare. Se preferisci Claude, puoi semplicemente collegare il tuo account Anthropic e partire.

Personalmente ho testato quasi tutti i principali modelli in circolazione — da o3 di OpenAI, a Gemini 2.5 Pro, fino a Claude Sonnet 3.7 e Opus 4.6. Nel tempo, ho costantemente finito per apprezzare maggiormente la qualità e la pertinenza delle risposte di Gemini.

E Gemini 3.5 Flash? È una bomba assoluta (una bomba, come diciamo in Italia). È incredibilmente veloce, estremamente preciso e decisamente intelligente. Devi provarlo di persona per capire la differenza di velocità.

Cosa stai aspettando? #

Nel tempo necessario a finire di leggere questo paragrafo, avresti già potuto scaricarlo. E nel tempo che impiegheresti a scrivere una risposta a questo post, potresti scrivere il tuo primo prompt e provarlo in prima persona.

Se sei uno sviluppatore che vuole dare una spinta alla propria produttività, prova l'accoppiata Antigravity 2 e Gemini 3.5 Flash. Penso proprio che non tornerai indietro. 😊

Il mio sogno di un formato d'immagine contenitore: un appello alla web community

2026-04-29T00:00:00Z

Qualche giorno fa, Mat Marquis ha scritto un ottimo articolo sulla fine delle immagini responsive, spiegando come l'attributo sizes="auto", ormai ampiamente supportato, consenta ai browser di calcolare autonomamente le dimensioni di rendering delle immagini caricate in modalità lazy, eliminando la necessità di creare manualmente l'attributo sizes per la maggior parte delle immagini.

Leggerlo ha risvegliato un sogno che porto con me da anni: un formato di immagine che ci permetterebbe di scrivere un tag <img> radicalmente più semplice — persino più semplice di quanto consenta sizes="auto". Ci arriverò più in basso. Ma prima, un rapido riassunto del pezzo di Andy per il contesto.

Un formato di immagine ideale: un solo file, tutte le dimensioni necessarie.

Il TL;DR di Andy #

Per le immagini caricate in modalità lazy (la maggior parte delle immagini su una pagina), possiamo abbandonare la scrittura manuale di sizes e lasciare che sia il browser a fare il lavoro:

<img
  loading="lazy"
  sizes="auto"
  srcset="
    shirt_300w.jpg   300w,
    shirt_600w.jpg   600w,
    shirt_1200w.jpg 1200w,
    shirt_2400w.jpg 2400w
  "
  alt="A shirt"
/>

Per le immagini "hero" — quelle above the fold, candidate a diventare LCP della pagina — dobbiamo ancora essere meticolosi con il dimensionamento preventivo tramite sizes:

<img
  loading="eager"
  srcset="
    shirt_300w.jpg   300w,
    shirt_600w.jpg   600w,
    shirt_1200w.jpg 1200w,
    shirt_2400w.jpg 2400w
  "
  sizes="(min-width: 1200px) 100vw,
         (min-width: 600px) 600px,
         300px"
  alt="A shirt"
/>

Quindi sizes può per lo più sparire. Ma ci rimane comunque quel lungo srcset che elenca ogni variante. Ed è qui che ritorna il mio vecchio sogno.

Ho un sogno #

Da anni sogno un formato di immagine contenitore — un singolo file che contenga al suo interno ogni risoluzione di un'immagine. Immaginatelo come una cartella di immagini compressa, confezionata come un unico file.

Con un formato simile, il tag <img>, almeno per le immagini lazy, potrebbe essere drasticamente semplificato. Qualcosa del genere:

<img srcset="shirt.imgc *w" sizes="auto" loading="lazy" alt="A shirt" />

Niente più srcset complessi con elenchi di larghezze separati da virgole. Il browser aprirebbe il file, vedrebbe quali risoluzioni sono disponibili all'interno e scaricherebbe solo i byte necessari per la dimensione che deve renderizzare.

Il tag <img>, finalmente di nuovo semplice.

Un appello alla community #

L'articolo di Andy dimostra che la piattaforma può assorbire gran parte della complessità che ci portiamo dietro nel nostro markup. Mi piacerebbe vederci andare ancora oltre.

A chi si occupa di standard web, agli autori dei formati di immagine e agli ingegneri dei browser che stanno leggendo: un formato di immagine contenitore è qualcosa che potremmo effettivamente realizzare? Le richieste HTTP range consentono già ai browser di recuperare segmenti di file. I formati contenitore esistono già in altri ambiti. I mattoni fondamentali sono tutti lì.

Custodisco questo sogno da molto tempo. Potremmo finalmente renderlo realtà?

Talk: Migliorare la reattività del web al Web Day 2026, Milano

2026-04-01T00:00:00Z

Andrea Verlicchi sul palco del Web Day 2026, Milano

Ho avuto l'opportunità di parlare al Web Day 2026, la nona edizione della conferenza organizzata da Improove a Milano, tenutasi il 30 marzo 2026 presso il Talent Garden Calabiana.

Il mio talk si intitolava "Enhancing Web Responsiveness — A practical guide to debugging and avoiding slow interactions" (Migliorare la reattività del web — Una guida pratica al debugging ed evitare le interazioni lente), incentrato su Interaction to Next Paint (INP), la metrica dei Core Web Vitals che misura quanto una pagina sia reattiva alle interazioni degli utenti.

Andrea Verlicchi sul palco del Web Day 2026, Milano

Ho condiviso casi di studio reali mostrando come identificare e risolvere una scarsa metrica INP, insieme a tecniche pratiche da applicare fin da subito per rendere i vostri siti web più scattanti. Se vi siete mai chiesti perché il clic su un pulsante sembri lento o un modulo impieghi un'eternità a rispondere, questo talk faceva al caso vostro.

🔗 Pagina del talk sul sito del Web Day

Rifattorizziamo i bias di genere, un commit alla volta

2026-03-27T00:00:00Z

Recentemente ho avuto il piacere di co-presentare un talk con Giulia Naponiello, Senior Software Engineer presso Red Hat, riguardo ai bias di genere nel settore tecnologico in due meetup locali. Il talk, intitolato "Rifattorizziamo i bias di genere, un commit alla volta", ha esplorato come i bias inconsci si manifestino in modo sottile negli ambienti di lavoro tech.

Abbiamo condiviso storie personali ed esaminato come i bias si presentino nelle situazioni quotidiane — dal linguaggio usato nelle code review alle valutazioni durante i colloqui di assunzione, dal riconoscimento dell'autorità tecnica alle dinamiche di team. L'obiettivo non era puntare il dito, ma fare luce sui "bug culturali" che tutti noi portiamo con noi e suggerire modi per risolverli. Pensatelo come un refactoring: stessa base di codice, risultati migliori. 🐛➡️✅

Bologna Front-end 🇮🇹 #

La slide di copertina del nostro talk.

Martedì 10 marzo 2026, abbiamo presentato al 61° episodio di Bologna Front-end presso Granata a Bologna.

🔗 Pagina dell'evento

DevRomagna 🇮🇹 #

Martedì 17 marzo 2026, abbiamo portato lo stesso talk a DevRomagna presso Gellify a Imola.

🔗 Pagina dell'evento

GitBar Podcast: Non toccate quel tag!

2026-03-19T00:00:00Z

GitBar Podcast - Episodio 228

Recentemente ho avuto il piacere di essere ospite di GitBar, il podcast italiano condotto da Mauro "Brainrepo" Murru. Nell'episodio 228, intitolato "Non toccate quel tag!", abbiamo fatto una lunga e divertente chiacchierata sulle web performance — dai Core Web Vitals all'ottimizzazione delle immagini, dal famigerato Interaction to Next Paint ai danni silenziosi del Google Tag Manager.

Abbiamo anche toccato alcuni argomenti nostalgici come Flash, Dreamweaver e MySpace, e parlato di come strumenti di IA come Claude stiano iniziando ad aiutare nell'analisi delle performance. È stato davvero divertente!

Guarda / Ascolta #

Puoi trovare l'episodio anche sul sito di GitBar.

Talk: Gemini + Chrome: Oltre la Chat, Bologna JS Meetup

2026-02-25T00:00:00Z

Bologna JS Meetup

Mercoledì 25 febbraio 2026, ho tenuto una presentazione al Bologna JS Meetup presso Spazio01 Coworking a Bologna.

Il talk, dal titolo "Gemini + Chrome: Oltre la Chat. Usare l'AI per controllare il browser", è stato una demo del Chrome DevTools MCP Server — mostrando come connettere l'IA a Chrome DevTools attraverso il Model Context Protocol.

Ho mostrato esempi pratici di come:

Leggere il DOM in tempo reale e manipolare le pagine web
Eseguire smoke test visivi su diversi viewport
Simulare interazioni utente complesse per test end-to-end
Intercettare richieste di rete e analizzare metriche di performance
Identificare colli di bottiglia nelle prestazioni

🔗 Pagina dell'evento

Video del talk: "Ehi Gemini, sistema il CSS!", Bologna Front-end #58

2025-12-09T00:00:00Z

Bologna Front-end #58

Martedì 9 dicembre 2025, ho tenuto una presentazione durante il 58° episodio di Bologna Front-end presso Granata a Bologna.

Il talk, dal titolo "Ehi Gemini, sistema il CSS!", è stato una demo live del Chrome DevTools MCP Server — uno strumento che permette di controllare Chrome DevTools attraverso il Model Context Protocol (MCP), utilizzando comandi in linguaggio naturale direttamente dal terminale.

Ho mostrato come sfruttarlo per:

Eseguire audit di accessibilità
Effettuare il debug di layout CSS complessi
Simulare diverse condizioni di rete
Testare viewport personalizzati per il responsive design

Tutto attraverso il linguaggio naturale, senza mai lasciare il terminale. Davvero notevole!

Guarda il video #

🔗 Pagina dell'evento

Google Antigravity: il nuovo IDE che abbraccia l'IA agentica

2025-11-24T00:00:00Z

C'è un nuovo IDE di Google che abbraccia l'IA agentica e sfrutta Gemini 3: Google Antigravity.

Grazie al ragionamento avanzato, alla gestione degli strumenti e alle capacità di programmazione autonoma di Gemini 3, Google Antigravity trasforma l'assistenza dell'IA da semplice strumento nella cassetta degli attrezzi di uno sviluppatore a un partner attivo. Sebbene il cuore di Google Antigravity sia una familiare esperienza di IDE con IA, i suoi agenti sono stati elevati a un'interfaccia dedicata e hanno ottenuto l'accesso diretto all'editor, al terminale e al browser. Ora gli agenti possono pianificare ed eseguire autonomamente compiti software complessi ed end-to-end per tuo conto, convalidando al contempo il proprio codice.

Venerdì, io e il mio collega Brian lo abbiamo messo all'opera su un compito complesso nello sviluppo del progetto a cui stiamo lavorando, con il modello Gemini 3, e ne siamo rimasti piuttosto colpiti.

Ciò che amo di Antigravity è che gestisce la pianificazione producendo due artefatti testuali, proprio come farebbe un Tech Lead: un Walkthrough (panoramica) e i Tasks (compiti). Puoi fornire feedback su questi — sia che abbia commesso un errore, sia che il prompt non fosse abbastanza specifico — selezionando il testo e commentandolo, in modo simile a come faresti in Google Docs o Notion. Puoi anche dare un feedback sull'intero approccio, un po' come in una Pull Request. Io ci scrivo quasi sempre "LGTM" (Looks Good To Me). Dopodiché inizia a lavorare. In realtà, ultimamente, inizia a lavorare persino prima del tuo feedback per portarsi avanti, fiducioso del suo piano, potendo poi correggere la rotta in seguito se necessario.

Ho provato a lavorare senza Antigravity, usando solo OpenSpec con Gemini 3 tramite la gemini-cli, ma l'ho trovato più macchinoso e frustrante. La CLI non è asincrona come Antigravity, quindi si perde un sacco di tempo ad aspettare che l'IA pensi. Antigravity suddivide tutto in compiti più piccoli, che sono più facili e veloci da gestire per l'IA, perciò inizia a lavorare prima e finisce più in fretta.

Poi c'è l'Agent Manager. Se ti va di fare lo sviluppatore supereroe potenziato dall'IA, puoi chiedergli di fare diverse cose in parallelo, anche su repository differenti (o su cloni diversi dello stesso repository se hai bisogno di lavorare su due rami diversi).

Volevo saperne di più su come usarlo al meglio, così questo fine settimana ho dedicato del tempo a guardare un paio di video che consiglio caldamente.

Imparare le basi di Google Antigravity #

Il primo è "Learn the basics of Google Antigravity" del team di Antigravity.

Questo video fornisce un'introduzione ufficiale e una panoramica dei componenti principali di Antigravity:

Tre superfici principali: Lo strumento combina un Agent Manager (per creare e gestire gli agenti), un Editor (un'esperienza IDE completa) e un Browser (che integra un agente direttamente all'interno di Chrome per i test autonomi).
Sviluppo assistito da agenti: L'LLM è impostato per prendere decisioni e implementare compiti semplici in modo automatico. Per problemi complessi, può mettersi in pausa e chiedere chiarimenti all'utente.
Artefatti per la trasparenza: L'agente genera file markdown come Piani di implementazione e Panoramiche per documentare i suoi progressi e le modifiche apportate.
Esecuzione parallela dei task: Gli sviluppatori possono avviare un compito per l'agente e iniziarne un altro complesso in autonomia.
Test autonomi: L'agente può avviare il browser integrato per verificare le proprie modifiche al codice.

Google Antigravity: il nuovo miglior editor di IA? #

Se vuoi una visione più approfondita, dai un'occhiata a "Google Antigravity: The New Best AI Editor?" di "AI with Brandon".

Questa recensione evidenzia:

Casella di posta dell'Agent Manager: L'interfaccia principale è progettata come una casella di posta elettronica per gestire più progetti.
Accesso gratuito a Gemini 3 Pro: Include l'accesso gratuito a Gemini 3 Pro all'interno dell'editor.
Gestione di compiti complessi: Il recensore mostra come l'agente implementi con successo una funzionalità full-stack che coinvolge molteplici servizi esterni (trigger.dev, OpenAI TTS, blob store, database e aggiornamenti dell'interfaccia utente).

Sembra che cambierà il modo in cui sviluppiamo, trasformandoci in... orchestratori di agenti?

Migliorare la reattività del web - Ottimizzazioni dell'interattività da casi reali

2025-11-01T00:00:00Z

Mercoledì 29 ottobre 2025, ho avuto il piacere di parlare all'evento performance.sync() ad Amsterdam. È stato un meetup pre-conferenza per la conferenza performance.now(), e una fantastica opportunità per incontrare e imparare da altri esperti di web performance.

Il mio talk, "Improving Web Responsiveness - Interactivity improvements from real-world cases" (Migliorare la reattività del web - Ottimizzazioni dell'interattività da casi reali), è stata una sessione di 15 minuti in cui ho condiviso tecniche pratiche per il debugging e l'ottimizzazione delle interazioni lente sui siti web.

La velocità di interazione è un aspetto chiave della reattività di un sito alle interazioni dell'utente. Questo talk mostra tecniche pratiche per migliorare le interazioni lente attraverso casi di studio reali di debugging e ottimizzazione di una scarsa velocità di interazione.

Guarda il video del talk se vuoi capire come identificare, risolvere e correggere le interazioni lente, garantendo un'esperienza utente costantemente reattiva.

Le slide sono disponibili al seguente link.

📽️ Slide

Ed ecco una foto di me sul palco, giusto per fornire a Eleventy un'immagine per l'elenco dei post. 😉

Sul palco di performance.sync() 2025.

Il gestore degli appunti di macOS che stavi aspettando, ora nativo in macOS 26 Tahoe

2025-09-16T00:00:00Z

Uno screenshot dell'overlay di Spotlight che mostra la cronologia degli appunti (ricercabile).

Hai presente quando copi un pezzo di codice, poi ne copi un altro e perdi quello precedente? O quando sai di avere qualcosa negli appunti, vorresti copiare qualcos'altro, ma devi prima incollare quello che hai negli appunti altrimenti lo perderai? Niente più stress da appunti. Finalmente gli appunti multipli sono arrivati su macOS 26 Tahoe.

Con il rilascio di macOS Tahoe, non dovrai più affidarti ad app di terze parti per accedere agli elementi copiati in passato. È una svolta per chiunque copi e incolli regolarmente più porzioni di testo (inclusi blocchi di codice), link o immagini.

Ecco una guida rapida su come iniziare a usare questa attesissima funzionalità e velocizzare il tuo flusso di lavoro.

Abilitare la cronologia degli appunti #

La cronologia degli appunti è integrata direttamente in Spotlight, ma non è visibile da subito. Al primo utilizzo, dovrai abilitarla. Ecco come:

Premi Command (⌘) + Spazio per aprire Spotlight.
Ora hai due opzioni per accedere alle nuove funzioni degli appunti:
- Premi il tasto Tab per rivelare i nuovi menu di Spotlight.
- Premi Command (⌘) + 4 per andare direttamente alla scheda Clipboard (Appunti).
La prima volta che lo fai, apparirà un avviso che ti chiederà di abilitare la funzione. Fai clic su "Enable" (Abilita) e sarai pronto a partire!

Usare la cronologia degli appunti #

Una volta abilitata, usare la cronologia degli appunti è semplicissimo. Ogni volta che desideri accedere a un elemento copiato in precedenza:

Premi Command (⌘) + Spazio per aprire Spotlight.
Premi Command (⌘) + 4 per visualizzare la scheda Clipboard in Spotlight.
Vedrai un elenco dei testi, link e immagini che hai copiato.
Usa i tasti freccia o il mouse per selezionare l'elemento desiderato.
Premi Invio o fai clic sull'elemento per ricopiarlo negli appunti.

Da lì, puoi incollarlo ovunque usando la scorciatoia standard Command (⌘) + V.

Alcune cose da notare #

Anche se questo è un enorme passo avanti per macOS, vale la pena notare alcune delle sue attuali limitazioni. Ad esempio, salva gli elementi copiati solo per circa otto ore e non c'è modo di fissare (pin) o salvare gli elementi in modo permanente. Se hai bisogno di una soluzione più avanzata con funzioni come scorciatoie personalizzate, cronologia illimitata o filtri intelligenti, un'app di terze parti potrebbe essere ancora la scelta migliore.

Ma per l'utente medio, questa nuova funzione integrata rappresenta un notevole incremento di produttività e un'aggiunta davvero gradita a macOS. Niente più corse a ricopiare!

Video del talk: "Debugging and Optimizing Interaction to Next Paint (INP) for a Smoother Web", Meetup Performance Observer

2025-04-16T00:00:00Z

Il 16 aprile 2025, ho avuto il piacere di parlare a uno degli eccellenti meetup di Performance Observer. La community di Performance Observer si concentra sulla condivisione di conoscenze e spunti pratici sul monitoraggio e sull'ottimizzazione delle prestazioni web. Potete consultare i loro eventi passati e futuri qui.

Il mio talk era intitolato "Debugging and Optimizing Interaction to Next Paint (INP) for a Smoother Web". Ecco la registrazione video della sessione:

In questo intervento ho approfondito gli aspetti pratici dell'identificazione e della risoluzione dei problemi relativi all'Interaction to Next Paint (INP). Ho illustrato le cause più comuni di scarsa reattività che ho riscontrato e mostrato le tecniche da utilizzare con i developer tools dei browser e i dati di monitoraggio delle prestazioni per individuare i colli di bottiglia. L'obiettivo era fornire strategie attuabili per migliorare la velocità di interazione dell'utente e ottenere migliori punteggi INP, mantenendo l'esperienza d'uso scattante.

I meetup di Performance Observer sono una fantastica serie di eventi dedicati a tutto ciò che riguarda le prestazioni web, e ospitano regolarmente talk di esperti del settore su monitoraggio, ottimizzazione e sulle ultime metriche prestazionali. È stato fantastico dare il mio contributo a questa community così competente.

Presentazione durante la sessione del meetup di Performance Observer.

📽️ Slide

Presentazione di yieldy-for-loop: un pacchetto npm per mantenere i loop non bloccanti (e la UI fluida)

2025-01-14T00:00:00Z

Se avete mai dovuto elaborare migliaia (o milioni) di elementi in JavaScript, avrete probabilmente sperimentato quel fastidioso lag o blocco dell'interfaccia utente. Può accadere quando si eseguono cicli intensivi sul thread principale, bloccando gli aggiornamenti dell'interfaccia. Per affrontare questo problema, ho creato un pacchetto npm chiamato yieldy-for-loop. Questa piccola utility vi aiuta a suddividere cicli di grandi dimensioni in blocchi, cedendo periodicamente il controllo al browser per far sì che la vostra applicazione rimanga reattiva.

yieldy-for-loop sul sito web di npm

Contesto #

I long task sono un comune collo di bottiglia per le prestazioni nelle applicazioni front-end. Quando il thread principale è occupato a eseguire cicli di grandi dimensioni, i browser non possono aggiornare l'interfaccia utente e gli utenti potrebbero notare una mancanza di reattività o uno scrolling a scatti. Ispirato dall'articolo “Breaking up with long tasks, or how I learned to group loops and wield the yield” (PerfPlanet 2024), volevo una funzione semplice e riutilizzabile che potesse:

Suddividere cicli di grandi dimensioni in lotti (batch) più piccoli.
Cedere il controllo al browser (yield) dopo ogni lotto, dando al motore di rendering la possibilità di aggiornare la pagina e all'utente quella di interagire.
Adattarsi a seconda che il documento sia visibile o nascosto, dato che il lavoro svolto in una scheda in background (nascosta) può essere deprioritarizzato o addirittura sospeso in molti browser.

Così è nato yieldy-for-loop.

Cosa fa #

Iterazione non bloccante: elabora i vostri elementi in lotti, con l'obiettivo di rimanere entro una determinata frazione di tempo (ad es. 33ms per puntare a circa 30 FPS).
Logica di auto-yield:
- Se la pagina è nascosta, cede il controllo meno frequentemente (ad es. ogni 500ms) per risparmiare risorse.
- Se la pagina è visibile, cede il controllo più di frequente per mantenere fluide le animazioni e le interazioni dell'utente.
Compatibilità del browser: utilizza una competizione (race) tra un breve setTimeout e requestAnimationFrame, ed eventualmente chiama la Scheduler API se disponibile.

Installazione #

npm install yieldy-for-loop

Esempio di utilizzo #

import yieldyForLoop from 'yieldy-for-loop';

const items = Array.from({ length: 100000 }, (_, i) => i);

function processItem(item) {
  // La vostra logica di elaborazione pesante
  console.log('Processing item:', item);
}

(async function main() {
  console.log('Starting yieldy loop...');
  
  await yieldyForLoop(items, processItem, {
    fps: 30,              // Punta a circa 30 fotogrammi al secondo
    hiddenThreshold: 500, // Soglia di yield (in ms) quando la scheda è nascosta
  });
  
  console.log('All items processed without blocking the UI!');
})();

Come funziona #

Calcolo della frazione di tempo (Time Slice):
- I fotogrammi al secondo (FPS) predefiniti sono impostati a 30, quindi viene calcolata una durata del lotto di circa 33ms.
Controllo shouldYield():
- Prima di elaborare ciascun elemento, la funzione controlla quanto tempo è trascorso dall'ultimo yield.
- Se supera la soglia (ad es. circa 33ms, o 500ms se il documento è nascosto), cede nuovamente il controllo al browser.
Meccanismi di Yielding:
- Pagina nascosta: utilizza setTimeout(resolve, 1) — il tempo minimo per consentire ad altri task di inserirsi.
- Pagina visibile: utilizza una combinazione di requestAnimationFrame e un breve timeout. Se il metodo sperimentale scheduler.yield() è disponibile, chiama anche quello.

Dividendo il ciclo in lotti, il browser ha lo spazio di manovra necessario per renderizzare la pagina, rispondere agli input dell'utente ed eseguire altri script, evitando così il temuto problema della "pagina che non risponde".

Perché ne avete bisogno #

Migliore esperienza utente: scrolling fluido, pulsanti reattivi e nessun blocco improvviso.
Facile da usare: basta racchiudere la normale logica del ciclo all'interno di yieldyForLoop.
Micro-ottimizzato: il codice è ridotto all'essenziale e lineare, quindi facile da mantenere o personalizzare.

Prossimi passi #

Provatelo: installate il pacchetto, importatelo e integratelo in qualsiasi ciclo pesante abbiate.
Contributi: segnalazioni di bug e pull request sono i benvenuti! Date un'occhiata alla repo GitHub per segnalare problemi, richiedere funzionalità o aprire PR.
Passate parola: se lo trovate utile, fatelo sapere agli altri.

Ringraziamenti #

Un ringraziamento speciale a Rick Viscomi per aver scritto l'articolo su PerfPlanet che mi ha spinto a realizzare questo strumento. Suddividere i task di grandi dimensioni in blocchi più piccoli è diventata una strategia prestazionale chiave, e yieldy-for-loop mira a renderne ancora più semplice l'adozione.

Conclusione #

I cicli lunghi non devono per forza tradursi in interfacce utente bloccate. Cedendo periodicamente il controllo al browser, potete mantenere un'esperienza fluida per i vostri utenti. yieldy-for-loop si occupa della parte difficile con pochissimo codice, lasciandovi liberi di concentrarvi su ciò che sapete fare meglio: creare fantastiche applicazioni web.

Se avete domande, contattatemi o aprite una segnalazione su GitHub. Ora non vi resta che provarlo e mantenere i vostri cicli fluidi.

Ottimizzare l'uso degli SVG per le prestazioni web: una guida completa

2024-12-05T00:00:00Z

In una recente conversazione tra appassionati di web performance, è stato approfondito il tema del caricamento efficiente degli SVG (Scalable Vector Graphics) sui siti web. La discussione si è concentrata sui metodi migliori per integrare gli SVG, in particolare le icone, con un occhio di riguardo alle prestazioni. Sono state confrontate diverse tecniche: SVG inline, il tag <img>, gli sfondi CSS e gli sprite SVG. Ecco un riassunto dei punti chiave e dei consigli emersi da quel confronto.

Le immagini SVG sono ampiamente utilizzate per creare icone sul web

Vediamo nel dettaglio i metodi per caricare gli SVG.

1. SVG inline #

Utilizzo: Ideale per icone above-the-fold come loghi o pulsanti di menu, specialmente quando è necessario stilizzare o animare singoli elementi all'interno dell'SVG usando CSS o JavaScript.

Vantaggi:

Flessibilità di stile: consente la manipolazione diretta degli elementi SVG.
Rendering immediato: nessuna richiesta HTTP aggiuntiva poiché l'SVG è parte integrante dell'HTML.

Svantaggi:

Aumento delle dimensioni del DOM: ogni SVG inline si aggiunge al DOM, il che può influire sulle prestazioni.
Impatto prestazionale: elementi selezionabili e stilizzabili possono influire sulle prestazioni di rendering.

Best practice:

URL-Encoding invece di Base64: quando si incorporano SVG inline tramite data URL, è preferibile utilizzare l'URL-encoding rispetto a base64 per ottenere una compressione migliore.
Limitarne l'uso: riservare gli SVG inline per elementi grafici essenziali above-the-fold che richiedono interattività.

2. Il tag `<img>` #

Utilizzo: Adatto per icone e immagini generiche dove non sono richiesti stili particolari o interazioni.

Vantaggi:

Lazy Loading: supporta l'attributo loading="lazy" per posticipare il caricamento delle immagini finché non sono necessarie.
DOM più snello: mantiene il DOM più pulito rispetto agli SVG inline.

Svantaggi:

Stile limitato: non è possibile manipolare direttamente gli elementi interni dell'SVG tramite CSS o JavaScript.
Contenuto statico: non è l'ideale per icone che devono cambiare colore o forma al passaggio del mouse.

Best practice:

Attributi delle dimensioni: includere sempre width e height per evitare spostamenti di layout (layout shift).
Evitare il lazy loading per gli asset immediati: non applicare il lazy-loading a immagini cruciali per il rendering iniziale o per interazioni immediate come gli stati di hover.

3. Immagini di sfondo CSS #

Utilizzo: Ideale per elementi grafici decorativi o pattern di sfondo che non richiedono interattività.

Vantaggi:

Separazione dei ruoli (Separation of Concerns): mantiene le immagini di sfondo nel CSS, lasciando la struttura HTML pulita.
Caricamento condizionale: può essere combinato con media query o JavaScript per design reattivi.

Svantaggi:

Controllo limitato: più difficile da manipolare o animare rispetto agli SVG inline.
Problemi di accessibilità: le immagini di sfondo non vengono lette dagli screen reader.

Best practice:

Lazy Loading: utilizzare librerie JavaScript come vanilla-lazyload per posticipare il caricamento delle immagini di sfondo non immediatamente visibili.
Utilizzo appropriato: riservare solo a elementi decorativi non critici.

4. Sprite SVG e tag `<use>` #

Utilizzo: Efficace quando si hanno più istanze di icone che devono essere stilizzate o animate, e quando gli SVG vengono serviti dallo stesso dominio.

Vantaggi:

Simboli riutilizzabili: consente di definire i simboli SVG una sola volta e richiamarli più volte.
Capacità di stile: consente la stilizzazione CSS degli elementi SVG come se fossero inline.
Meno richieste HTTP: raggruppa le icone in un unico file.

Svantaggi:

Complessità di configurazione iniziale: richiede la creazione e la gestione di un file di sprite esterno.
Same-Origin Policy: lo sprite SVG esterno deve trovarsi sullo stesso dominio a causa delle restrizioni di sicurezza del browser.

Best practice:

Organizzazione efficiente: raggruppare le icone usate più di frequente in un unico file di sprite.
Soluzioni di fallback: implementare alternative per i browser che potrebbero non supportare gli sprite SVG esterni.

Scegliere il metodo in base al caso d'uso #

Scegliete il metodo di caricamento degli SVG in base alle esigenze specifiche del progetto. SVG inline per elementi interattivi, tag <img> per icone statiche, sfondi CSS per immagini decorative e sprite SVG per icone riutilizzabili e stilizzabili.

Considerazioni sulle prestazioni #

La dimensione del DOM conta: un numero eccessivo di SVG inline può appesantire il DOM e peggiorare le prestazioni.
Lazy loading intelligente: usate il lazy loading per le immagini non immediatamente necessarie, ma evitatelo per le risorse necessarie per le interazioni iniziali o per gli effetti di hover.
Tecniche di compressione: preferite l'URL-encoding rispetto a base64 quando incorporate gli SVG nei data URL per mantenere rapporti di compressione migliori.

Stile e interattività #

Icone interattive: usate gli SVG inline o gli sprite SVG con il tag <use> quando le icone devono rispondere alle interazioni dell'utente.
Icone statiche: usate il tag <img> per le icone che non richiedono interattività per mantenere il DOM leggero.

Accessibilità e semantica #

Attributi corretti: includete l'attributo alt per i tag <img> e aria-label o role="img" per gli SVG inline per migliorare l'accessibilità.
Evitare immagini di sfondo per contenuti essenziali: poiché le immagini di sfondo CSS vengono ignorate dalle tecnologie assistive, non utilizzatele per contenuti importanti.

Evitare tecniche superate: #

Sprite di immagini: i tradizionali sprite di immagini (CSS sprites) sono ampiamente considerati obsoleti a causa della complessità e dei rendimenti decrescenti nell'era di HTTP/2 e HTTP/3.
Font di icone (Icon Fonts): valutate la migrazione dai font di icone agli SVG per una migliore scalabilità e flessibilità di stile, come descritto nell'articolo di Erwin Hofman.

Conclusione #

Ottimizzare l'uso degli SVG sui siti web richiede un equilibrio tra prestazioni, manutenibilità e funzionalità. Scegliendo il metodo appropriato per caricare gli SVG in base al loro scopo — che si tratti di visualizzazione statica, personalizzazione dello stile o interattività — è possibile migliorare sia l'esperienza utente sia le prestazioni del sito. Ricordate di considerare fattori come la dimensione del DOM, il lazy loading e l'accessibilità quando implementate gli SVG nei vostri progetti.

Approfondimenti #

SVG sprites generator
Styling SVG Content with CSS di Sara Soueidan
From Fonts to SVG: An Icon Migration Strategy di Erwin Hofman
Repository GitHub di vanilla-lazyload di Andrea Verlicchi (il sottoscritto)

Video del talk: "How I made the web more responsive — real-world case studies of INP optimizations", conferenza We Love Speed 2024

2024-11-26T00:00:00Z

Il 17 settembre 2024, ho parlato alla conferenza We Love Speed 2024 su come migliorare la reattività del web. In particolare, ho spiegato come fare il debug ed evitare le interazioni lente sulla base della mia esperienza nell'audit dell'Interaction to Next Paint (INP) sui siti web dei clienti.

Il titolo del talk era "How I made the web more responsive - real-world case studies of INP optimizations", in francese "Comment j’ai rendu le web plus réactif — études de cas concrets d’optimisations d’INP", e questo è il video del mio intervento.

Dopo una spiegazione iniziale dell'INP, mostro come fare il debug delle interazioni lente utilizzando sia Chrome DevTools sia i dati RUM (Real User Monitoring). Illustro poi tre errori comuni che ho riscontrato durante l'audit dell'INP su decine di siti web e spiego come evitarli per garantire interazioni scattanti per l'utente e mantenere l'INP sotto i 200 millisecondi.

Sul palco di We Love Speed 2024.

📽️ Slide

Il web è morto, lunga vita al web (repost)

2024-11-22T00:00:00Z

👀 L'autore di questo articolo è Antonio Moro, in arte Itomi.
🇮🇹 Articolo originale | Itomi Studio | About | Shop

La chiusura di Badtaste.it è solo l'ultimo chiodo su una bara che in realtà è chiusa da anni: l'editoria online come l'abbiamo conosciuta negli ultimi vent'anni è ormai morta e sepolta.

Ieri si è diffusa la notizia che Badtaste.it chiuderà dopo 20 anni di attività. Non è una sorpresa, almeno non per me. È solo l'ultimo di molti segnali degli ultimi cinque anni. E chi dà la colpa alla pandemia ha capito ben poco di quello che è successo realmente.

Sono uno di quelli che ha fatto parte dell'"editoria online", come è stato di moda chiamarla per anni, in Italia fin dai suoi albori — quando si chiamava semplicemente "scrivere su un blog". La festa è durata 20 anni, poi è finita. E anche se qualcuno si attarda ancora all'uscita, non c'è molto da fare. La musica è finita.

Per fortuna ho avuto la lucidità di andarmene prima che implodesse completamente. Tre anni fa ho lasciato la direzione del sito che ho fondato e diretto per 12 anni e ho avviato una casa editrice basata su un progetto completamente diverso — che ritorna all'oggetto fisico e abbandona il concetto di "tutto digitale" tanto caro a questo settore negli ultimi due decenni.

Il web è morto, e in gran parte si è ucciso da solo. Si è ucciso quando ha permesso a una singola azienda e a un singolo motore di ricerca di dettare le regole su cui si basava.

Si è ucciso quando ha consegnato a pochi social network le community che aveva faticosamente costruito nel corso degli anni.

Per anni Google ha dettato come gli articoli online dovessero essere scritti, pubblicati e formattati. Quali parole chiave e quante dovessero essere incluse in ogni pezzo affinché avesse senso pubblicarlo. Abbiamo smesso di scrivere per il nostro pubblico e, senza nemmeno rendercene conto, abbiamo iniziato a scrivere per l'algoritmo di Google — per ottenere più traffico, per portare più persone sui nostri contenuti. Siamo diventati dipendenti da una sostanza che non ci ha mai nutrito: un traffico cieco e inutile fatto di persone che non sapevano nemmeno cosa stessero leggendo o dove lo stessero leggendo. Abbiamo cancellato l'identità dei nostri siti e blog, trasformandoli in sterili contenitori di contenuti privi di personalità.

Facebook, l'unica altra forte fonte di traffico, ha completato l'opera. Ci ha portato via le nostre community, i nostri lettori fedeli. Ha tolto le interazioni, divorando ciò che avevamo costruito. Nel momento in cui abbiamo iniziato a considerare normale la scritta "Commenti: Zero" sotto i nostri articoli, i nostri siti hanno iniziato a morire in modo irreversibile.

Abbiamo abbandonato un pubblico piccolo, fedele e attivo per uno vasto, disinteressato e inconsapevole.

I blog e i siti editoriali sono nati perché pochi appassionati volevano condividere le proprie idee, opinioni e contenuti. Lo facevamo gratis, nel nostro tempo libero. E chi ci leggeva lo faceva gratis. E ne eravamo felici.

Poi è diventato un lavoro, e capire come guadagnarci è diventato fondamentale. Una volta regalati i frutti del nostro lavoro — i nostri contenuti — l'unica opzione rimasta era monetizzare attraverso banner e campagne pubblicitarie.

Su Lega Nerd ho resistito per anni, facendo solo campagne "native" con inserzionisti in linea con la mia nicchia, riducendo al minimo i banner pubblicitari perché rovinavano la leggibilità e l'esperienza complessiva dell'utente. Nel corso del tempo, l'economia di Internet e la pubblicità online si sono spostate sempre più verso nuovi attori — oggi li chiamiamo "influencer", ma sono solo creatori di contenuti come lo eravamo noi, solo che lo fanno in modo diverso e su altre piattaforme, raggiungendo un pubblico enorme.

Gli inserzionisti hanno impiegato qualche anno a capire il potere degli influencer, ma alla fine il budget si è spostato sui creator. Gestire una campagna per il proprio sito era già difficile cinque anni fa, figuriamoci oggi.

Ora, i padroni assoluti dei siti web sono i banner. Sono esplosi alla fine degli anni 2010, grazie all'ascesa delle piattaforme di "Real-Time Bidding" che ne hanno aumentato la redditività, e noi ci siamo buttati a capofitto in questa nuova opportunità, riempiendo i nostri siti di spazzatura. Spazzatura in ogni paragrafo. Spazzatura che compare sopra i contenuti. Spazzatura che si avvia da sola in autoplay e rimane fissa mentre scorri per leggere. Spazzatura ovunque.

Avevamo bisogno di più traffico, e lo abbiamo rincorso con ogni mezzo. Più traffico significava più visualizzazioni di pagina, più visualizzazioni significavano più banner mostrati, e più banner significavano più soldi per tenere a galla la baracca.

Avevamo bisogno di più traffico da Google, quindi abbiamo scritto quello che voleva, ricostruito i nostri siti da zero secondo le sue specifiche, ottimizzato tutto come ci veniva dettato.

Avevamo bisogno di più traffico dai social media, quindi abbiamo iniziato a pubblicare centinaia, migliaia di notizie. Attualità. Giusto poche righe, poca sostanza, ma sufficienti per le persone che scorrono Facebook senza pensare. Migliaia di notizie al giorno. Poi siamo passati al clickbait — per far cliccare le persone e farle atterrare sui nostri siti. E le fake news — centinaia, migliaia di siti creati esclusivamente per generare traffico e monetizzare i banner.

Spazzatura, ricoperta da altra spazzatura.

E chi ci credeva davvero, chi voleva pubblicare contenuti interessanti, indipendenti, educativi, informativi? Fregato.

Fregato perché non può competere con chi gioca con quelle regole senza trasformare a sua volta il proprio sito in spazzatura. Vuoi viverci o vuoi scrivere per quattro gatti senza guadagnare nulla?

Gli anni della pandemia hanno ulteriormente gonfiato il web in modo artificiale. Il traffico è cresciuto, i banner si sono moltiplicati ancora di più e la pazienza degli utenti si è esaurita. Sono stati solo un paio d'anni di buone notizie per gli editori prima di piombare nuovamente nella realtà.

Ora i banner non pagano quasi nulla. Le campagne sono sparite. Monetizzare un sito editoriale è più difficile che mai. Abbiamo reso il web brutto e ora nessuno vuole più guardarlo. Le persone si informano altrove, senza dover subire la spazzatura che ricopre i siti internet.

Abbiamo regalato i nostri contenuti per 20 anni e ora nessuno vuole pagarli — specialmente dopo che abbiamo pubblicato spazzatura per anni. Niente abbonamenti. Niente aree "premium". Non funziona più nulla e non sappiamo dove sbattere la testa.

È ora di chiudere. Di fare altro.

I giovani si inventeranno qualcosa di nuovo, qualcosa di innovativo e adatto ai tempi. Tempi veloci. Tempi brutali.

Vedo un timido ritorno al passato. Stanno nascendo piccole community di persone stanche della bulimia dei social media. Nascono piccoli progetti editoriali che usano il web ma non si affidano esclusivamente ad esso. Il web non morirà mai del tutto.

Il web è morto. Lunga vita al web.

La mia esperienza a performance.now() 2024: la principale conferenza sulla web performance in Europa

2024-11-16T00:00:00Z

Dal 14 al 15 novembre, ho partecipato a performance.now ad Amsterdam, la conferenza più stimata nel campo delle performance web in Europa. Per chi, come me, è profondamente immerso in questa nicchia dello sviluppo web, incontrare altre persone con le stesse passioni all'evento è stato sia stimolante sia prezioso.

Il mio badge di performance.now 2024, oltre a gadget e adesivi

Contenuti e speaker eccezionali #

Il programma delle due giornate di conferenza.

Fin dal primo momento è stato evidente che performance.now() si distingue per l'alto livello dei contenuti e degli speaker. Ogni sessione era curata nei minimi dettagli, con leader del settore che hanno affrontato una vasta gamma di sfide e soluzioni per le moderne performance web.

I keynote hanno esplorato l'evoluzione dello scenario della velocità del web, sottolineando la necessità critica di reattività e di metriche incentrate sull'utente. I talk hanno affrontato svariati argomenti, dall'impatto dell'accessibilità sulle performance alle strategie pratiche per migliorare i Core Web Vitals, in particolare l'INP (Interaction to Next Paint). Altre presentazioni si sono concentrate su strumenti avanzati, ottimizzazione dei font e riduzione dell'impatto degli script di terze parti.

Con studi di caso approfonditi e discussioni orientate al futuro, l'evento ha mostrato tecniche all'avanguardia e promosso una visione olistica delle web performance.

Connettersi con professionisti affini #

Uno dei momenti salienti della conferenza per me è stata l'opportunità di connettermi con colleghi professionisti che condividono la stessa passione per le performance web. Le numerose pause e la vivace festa serale hanno facilitato conversazioni significative e networking. È stato rigenerante scambiare idee, discutere di sfide ed esplorare potenziali collaborazioni con colleghi che comprendono davvero le complessità del nostro settore.

Oltre a partecipare, ho avuto l'onore di contribuire alla conferenza in due modi significativi.

Contribuire all'help desk sponsorizzato da Google #

Morten Sorth e Ismail Gunsaya di Skyscanner che mi chiedono consigli sull'ottimizzazione dell'INP

Uno dei punti salienti per me è stata la partecipazione all'Help Desk sponsorizzato da Google, dove ho risposto per circa mezz'ora alle domande dei partecipanti offrendo soluzioni alle loro sfide di web performance. Questa esperienza mi ha permesso non solo di restituire qualcosa alla community, ma anche di imparare dalla grande varietà di problemi e prospettive presentati da altri professionisti.

Partecipare all'intervista live di Henri Helvetica su YouTube #

Henri Helvetica e io durante lo streaming dal vivo

Un altro momento importante è stato partecipare all'intervista dal vivo di Henri Helvetica su YouTube. Essere intervistato da Henri mi ha dato l'opportunità di condividere la mia esperienza e il mio background con un pubblico più vasto. L'intervista ha approfondito il mio percorso e le mie sfide personali, ed è stato fantastico.

Date un'occhiata al canale YouTube di Henri Helvetica.

Pre-evento: Performance.Sync di Mozilla #

Il 13 novembre, il giorno prima di Performance.now, ho avuto anche il piacere di partecipare a Performance.Sync, un evento organizzato da Mozilla. Durante questa sessione, il mio collega Brian Louis Ramirez ha tenuto una presentazione sul tema "Finding the needle in the haystack" (Trovare il ago nel pagliaio), incentrata sull'identificazione di anomalie nei dati RUM (Real User Monitoring).

Le intuizioni di Brian su come analizzare efficacemente enormi quantità di dati sulle prestazioni per individuare problemi critici sono state illuminanti e molto pratiche. La partecipazione a Performance.Sync mi ha fornito una comprensione più profonda delle tecniche avanzate di analisi dei dati e ha rafforzato l'importanza di un monitoraggio meticoloso nell'ottimizzazione delle performance web.

Mesdames et messieurs, Brian Louis Ramirez sul palco

Spunti raccolti e approfondimenti #

Durante la conferenza ho preso alcuni appunti che rileggerò con attenzione, poiché molti di essi mi hanno spinto a pianificare delle attività.

SpeedCurve ha scritto una guida completa sulle web performance
Ottima idea quella di correlare tasso di conversione e INP
Configurare gli alert solo sui cambiamenti dei KPI principali, non quando cambiano i fattori abilitanti (enabler)
Suddividere le regressioni in moderate, accettabili e critiche, in base alla percentuale di regressione
Quando si verifica una regressione, analizzare chi, cosa, quando, dove e perché è accaduta
~Le immagini caricate in modalità lazy possono essere decodificate in modo asincrono, ma quelle caricate in modalità eager no.~ Discusso, vedi cosa fa effettivamente decode=async.
La nuova funzionalità delle annotazioni nei Chrome DevTools sarà utilissima per me e altri professionisti
Possiamo usare crbug.com/new per segnalare bug al progetto Chromium e richiedere nuove funzionalità
Gli sviluppatori di Chrome stanno spostando le informazioni dal pannello Performance Insights a quello Performance — ce n'è uno anche per le prestazioni CSS, se si esegue una traccia con l'opzione "Selector stats (slow)" attiva
I font variabili sono più leggeri solo se si utilizzano due o più variazioni dello stesso font, altrimenti conviene caricare la singola variazione (es. la versione bold per i titoli)
La scheda CSS overview nei developer tools offre un'idea di quanti elementi della pagina utilizzano determinati font
C'è un nuovo gruppo di lavoro per l'incremental font transfer, per scaricare solo la porzione di font di cui l'utente ha effettivamente bisogno al momento
size-adjust (a livello di box) e font-size-adjust (a livello di font) sono utili per cercare di renderizzare il font di fallback in modo simile al web font. Ho preso nota di uno strumento chiamato css-size-adjust-tester, che al momento non riesco a trovare, mentre ho trovato il generatore di font di fallback di Brian Louis Ramirez.
Google Publisher Tag (GPT) ha una funzionalità per cedere il controllo al main thread (yield) per ottimizzare l'INP
Quando ci sono buchi negli eventi di commit nei dev tools, controllate in altre tracce o caricate la traccia in Perfetto per capire il motivo

Questi appunti sono stati fondamentali per definire i passaggi successivi e integrare nuove tecniche nel mio flusso di lavoro, oltre che per i miei progetti personali. Condividere queste riflessioni sarà indubbiamente utile per chiunque voglia migliorare le proprie competenze sulle web performance.

Riflessioni sull'esperienza #

Mi piace sedermi nelle prime file per interagire visivamente con gli speaker

Partecipare a Performance.now è stata un'esperienza gratificante che ha rafforzato il mio impegno per l'eccellenza nelle performance web. Il mix di contenuti di alto livello, speaker esperti e una community vibrante rende questo evento imperdibile per chiunque operi in questa nicchia. Non vedo l'ora di applicare le conoscenze acquisite e di contribuire ulteriormente al dialogo continuo nel nostro settore.

Se avete la passione per le web performance e desiderate migliorare le vostre competenze, vi consiglio caldamente di partecipare a Performance.now. Non è solo una conferenza: è un incontro tra le menti più brillanti dedicate a spingere i limiti di ciò che è possibile sul web.

Non esitate a contattarmi se avete domande sulla conferenza o sulle web performance in generale!

Come usare Google Meet con due schermi: separare i contenuti condivisi e i volti dei partecipanti

2024-11-06T00:00:00Z

La schermata di benvenuto di Google Meet.

In Google Meet, se si lavora con due schermi, potrebbe essere utile tenere i contenuti condivisi su uno schermo e i volti dei partecipanti sull'altro. Questa configurazione permette un maggiore coinvolgimento durante la riunione, rendendo più facile concentrarsi sui volti dei partecipanti, sulla chat e sulle altre interazioni, pur continuando a tenere d'occhio la presentazione o il contenuto condiviso. Ecco come fare utilizzando la modalità Companion di Google Meet e pochi passaggi manuali.

👀 L'attesa è finita!!! Questo non è più necessario a partire da marzo 2026, perché Google ha rilasciato la funzione per portare il contenuto condiviso in una nuova finestra! 🥳 Lascio l'articolo qui perché è un buon esempio di come usare la modalità Companion e potrebbe essere utile per qualcuno.

Guida passo-passo all'uso della modalità Companion #

L'uso della modalità Companion consente di accedere nuovamente a una riunione di Google Meet da una seconda scheda o finestra senza duplicare l'audio, permettendo di configurare ciascuna finestra singolarmente. Ecco come la imposto io:

Impostare il layout per i volti dei partecipanti
Nella finestra principale della riunione, cliccate sul menu con i tre puntini ... (altre opzioni) e andate su Modifica layout. Scegliete Griglia (Tiled) per assicurarvi che i volti dei partecipanti siano visibili in una griglia.

La schermata di Google Meet per cambiare il layout
Minimizzare la presentazione nella finestra principale
Se la presentazione è bloccata in primo piano, sbloccatela passandoci sopra con il mouse e cliccando sull'icona della puntina (unpin). Questo ridurrà le dimensioni della presentazione e ingrandirà i volti dei partecipanti, assicurando che il vostro focus principale in questa finestra rimanga sulle persone e non sul contenuto.

Questa è l'icona per sbloccare il contenuto presentato.
Duplicare la scheda di Google Meet
Fate clic con il tasto destro sulla scheda di Google Meet e selezionate Duplica. Questa nuova scheda verrà utilizzata esclusivamente per visualizzare il contenuto condiviso.

Ecco il menu a discesa per duplicare una scheda di Chrome
Abilitare la modalità Companion nella scheda duplicata
Nella scheda duplicata, scegliete Usa modalità Companion. La modalità Companion vi farà partecipare nuovamente alla riunione ma senza audio, evitando così fastidiosi echi o fischi. Questa seconda finestra servirà esclusivamente per la visualizzazione dei contenuti.

La modalità Companion si trova proprio lì, evidenziata in blu.
Spostare la scheda in modalità Companion in una nuova finestra e posizionarla sullo schermo principale
Trascinate la scheda in modalità Companion in una finestra separata e spostatela sullo schermo principale dove volete visualizzare il contenuto condiviso. Ora avrete la riunione principale con i volti dei partecipanti su uno schermo e il contenuto in modalità Companion sull'altro.
Migliorare la finestra in modalità Companion con il mio bookmarklet per lo schermo intero reale di Google Meet
Nella finestra in modalità Companion, potete usare il mio bookmarklet Google Meet true full screen per attivare una modalità a schermo intero reale. In questo modo, il contenuto condiviso riempirà lo schermo senza elementi dell'interfaccia utente superflui, rendendo più facile concentrarsi sulla presentazione.
Passaggio bonus Se attivate il Picture-in-Picture (PIP) nella finestra principale di Google Meet, è persino possibile portare i volti dei partecipanti davanti al contenuto presentato da qualcun altro, proprio come si può fare con Zoom.

Perché questa configurazione funziona #

Questa configurazione mantiene i volti dei partecipanti, la chat e i controlli accessibili nella finestra principale, riservando un secondo schermo esclusivamente per i contenuti. Offre un'esperienza più immersiva ed è un ottimo modo per aggirare le attuali limitazioni dell'interfaccia utente di Google Meet.

Considerazioni finali #

Sì, è un processo un po' manuale, ma finché Google non migliorerà il supporto per i doppi schermi, questi passaggi rappresentano il modo più efficace per gestire gli elementi visivi della riunione su più schermi. Questa configurazione è particolarmente utile per conferenze virtuali o riunioni con un alto livello di interazione, poiché mantiene completamente visibili sia la presentazione che le persone che vi partecipano.

Provatela e fatemi sapere come vi trovate! Se avete suggerimenti per snellire il processo, non esitate a condividerli.

Modalità a schermo intero reale per i contenuti condivisi su Google Meet

2024-11-05T00:00:00Z

Google Meet a schermo intero reale, finalmente!

Passando molto tempo su Google Meet, mi sono spesso scontrato con la frustrazione di non poter visualizzare i contenuti condivisi in modalità a schermo intero reale. Massimizzare lo spazio sullo schermo è fondamentale, specialmente quando si analizza del codice complesso o presentazioni di design dettagliate. Tuttavia, per qualche motivo, Meet limita le opzioni di schermo intero lasciando visibili i bordi e gli elementi dell'interfaccia utente, il che può essere fonte di distrazione.

👀 L'attesa è finita!!! Questo non è più necessario a partire da marzo 2026, perché Google ha rilasciato la funzione per portare il contenuto condiviso in una nuova finestra! 🥳 Lascio l'articolo qui perché è un buon esempio di come creare un bookmarklet e potrebbe essere utile per qualcuno.

Mi sono stancato di aspettare che Google fornisse una soluzione, così ho deciso di crearmene una da solo. Ho creato un bookmarklet che permette di visualizzare i contenuti condivisi a schermo intero reale su Google Meet, rimuovendo gli elementi estranei e massimizzando lo spazio utile sullo schermo.

Date un'occhiata e aggiungetelo al vostro browser qui:

👉 Google Meet True Full-Screen Bookmarklet su GitHub

Lì troverete la procedura per aggiungere il bookmarklet al vostro browser e, una volta aggiunto, potrete attivare la modalità a schermo intero reale con un solo clic.

Questo semplice script mira a migliorare l'esperienza durante i meeting mantenendo il focus sui contenuti che contano. Fatemi sapere se lo trovate utile, o se ci sono modifiche o funzionalità che vi piacerebbe aggiungere.

Buona visione a schermo intero!

Il dibattito sul lavoro da remoto: la mia visione per trovare un equilibrio

2024-10-20T00:00:00Z

Dopo quasi tre anni di lavoro completamente da remoto, sei anni di "smart-working" (due da casa, tre in ufficio) e più di 15 anni di lavoro in ufficio, ho acquisito una buona prospettiva sul dibattito relativo al lavoro da remoto. Sebbene sostenga molti dei vantaggi del lavoro da casa, ne riconosco anche gli svantaggi, e penso che esista una via di mezzo ideale.

I vantaggi del lavoro da remoto #

Il lavoro da remoto offre chiari vantaggi. Prima di tutto, è efficace: consente una maggiore produttività, meno distrazioni e una migliore concentrazione quando si ha la giusta configurazione, che si tratti di uno spazio isolato in casa o di una scrivania in un coworking. Per i dipendenti c'è anche il vantaggio della flessibilità. Si ha la libertà di organizzare i propri orari più facilmente in base agli impegni personali e alle proprie preferenze. Anche dal punto di vista economico è una vittoria: nessun costo di pendolarismo, nessuna necessità di pranzare fuori ogni giorno.

L'elemento umano: cosa ci perdiamo #

Ma il lavoro da remoto non ha solo lati positivi. Uno dei maggiori svantaggi è l'isolamento che può portare con sé. È facile compensare questo aspetto rimanendo attivi, andando in palestra o vedendosi con gli amici. Tuttavia, nulla può sostituire gli scambi spontanei che avvengono con i colleghi quando si condivide uno spazio di lavoro. Queste interazioni informali possono far nascere nuove idee e contribuire a rafforzare lo spirito di squadra.

Un esempio personale: proprio giovedì scorso ero ad Amburgo per un evento presso l'ufficio dell'azienda. Durante una pausa, ho fatto una chiacchierata informale con una collega, una studentessa lavoratrice, e ho scoperto che stava preparando la sua tesi su un argomento direttamente correlato a un progetto su cui sto lavorando. Quella preziosa connessione non ci sarebbe stata senza l'interazione di persona.

C'è qualcosa di unico nei legami che si creano lavorando fianco a fianco per molte ore. In molti casi, lavorando a tempo pieno in ufficio, si passa più tempo con i colleghi che con la propria famiglia. Questo è particolarmente vero per i piccoli team, dove queste relazioni possono essere così forti da durare per anni — legami* che restano solidi anche quando si cambia lavoro.

*Marco, Giorgio, Alberto, David e Tommy, se state leggendo questo post, vi sto pensando.

Trovare l'equilibrio: un approccio ibrido #

Nella mia esperienza, la configurazione ideale è un approccio ibrido. Lavorare da casa la maggior parte del tempo, ma con la flessibilità di andare in ufficio quando necessario — ad esempio per sessioni di brainstorming, progetti collaborativi o riunioni importanti.

Ritengo inoltre che le aziende dovrebbero organizzare regolarmente eventi di persona — come workshop o attività di team building — almeno quattro volte all'anno, per mantenere vivo il senso di connessione e di scopo condiviso.

Questo modello trova il giusto equilibrio tra autonomia e collaborazione, assicurandoci che, pur godendo della flessibilità del lavoro da remoto, non si perdano le preziose relazioni interpersonali che alimentano l'innovazione e il cameratismo all'interno di un team.

Talk: Come ho reso il web più reattivo — casi reali di ottimizzazione dell'INP

2024-09-17T00:00:00Z

A partire da maggio 2024 ho iniziato a tenere talk a conferenze e meetup su come migliorare la reattività del web. I miei interventi si concentrano su come fare il debug e prevenire le interazioni lente, attingendo alla mia esperienza di audit dell'Interaction to Next Paint (INP) su decine di siti web di clienti.

📽️ Slide

We Love Speed, Nantes 🇫🇷 - 17 Settembre 2024 #

Sul palco di We Love Speed 2024, Nantes

📺 Video - Pagina dell'evento

We Make Future, Bologna 🇮🇹 - 14 Giugno 2024 #

Sul palco Coding Front-end di WMF 2024: come fare il debug dell'INP, alla vecchia maniera.

Il titolo del talk, in italiano, era "Migliorare la reattività del web — Guida pratica per debug e prevenzione delle interazioni lente".

📺 Video - Pagina dell'evento

Google Developer Group, Madrid 🇪🇸 - 4 Giugno 2024 #

Presentazione al GDG Madrid, in cui mostro la prima sotto-parte dell'INP: l'Input Delay.

Il titolo del talk in spagnolo era: "Hagamos que la web sea mas responsive en 2024".

Evento GDG Madrid

Bologna JS, Bologna 🇮🇹 - 22 Maggio 2024 #

Al meetup di Bologna JS. Questa è l'unica foto che ho 🤷‍♂️. Praticamente la conclusione.

📺 Video · Pagina dell'evento su Meetup

Google Developer Group, Bologna 🇮🇹 - 01 Ottobre 2024 #

Io che parlo sul "palco" al Phygital Hub (Gellify)

Titolo: "Come ho reso il web più reattivo - Guida pratica di come trovare ed evitare le interazioni lente."

Pagina dell'evento

DevRomagna, Faenza 🇮🇹 - 26 Settembre 2024 #

Io che parlo sul palco di DevRomagna, Faenza

Titolo: "Come ho reso il web più reattivo - Guida pratica di come trovare ed evitare le interazioni lente."

Pagina dell'evento

Le mie funzioni preferite di iOS 18: una svolta per gli utenti multilingue (e non solo)

2024-09-13T00:00:00Z

Con ogni nuova versione di iOS, non vedo l'ora di esplorare le ultime funzionalità offerte da Apple. iOS 18 ha introdotto diversi cambiamenti, alcuni piccoli e discreti, altri più profondi, che hanno migliorato notevolmente la mia esperienza d'uso. Ecco le mie nuove funzioni preferite in iOS 18 e perché penso che rappresentino una svolta.

Il selettore della tastiera di iOS 18 che mostra diversi set di tastiere: italiano e inglese, portoghese e francese, spagnolo e tedesco

1. Tastiere bilingue: un'esperienza multilingue fluida #

Uno dei miei aggiornamenti preferiti in assoluto è la nuova funzionalità della tastiera che mi consente di digitare in più lingue senza cambiare manualmente la lingua di input. È molto meglio così! In sostanza, iOS 18 offre tastiere bilingue, quindi posso scrivere messaggi come:

“Guten Tag! Buenos días! Alles gut? Sí, muy bien! Bom dia! Bonjour! Tudo beleza? Oui, ça va très bien!”

E la parte migliore? Non ho bisogno di cambiare il layout della tastiera ogni volta che cambio lingua. Si tratta di un miglioramento enorme, soprattutto per chi passa continuamente da una lingua all'altra come me. È una piccola funzione che aggiunge tantissima fluidità alle conversazioni multilingue.

2. Dettatura migliorata: più veloce e intelligente #

“Ciao, sto provando la nuova funzione di dettatura su iPhone 18. Sembra avere la punteggiatura automatica anche in italiano ora. A che ora hai detto che partiamo oggi?”

Sì, la punteggiatura automatica è arrivata! Si tratta di un aggiornamento semplice ma estremamente utile, che mi fa risparmiare un sacco di tempo in fase di modifica. Un piccolo consiglio, però: per dettare in inglese, assicuratevi di avere abilitata la dettatura in inglese, poiché l'impostazione predefinita in italiano riconoscerà solo parole inglesi elementari. È un piccolo ostacolo, ma il miglioramento generale della dettatura è innegabile.

3. Schermata Home, Centro di Controllo e sfondi migliorati #

iOS 18 ha fatto grandi passi avanti anche nella personalizzazione. Ora la gestione della schermata home e del centro di controllo è molto più flessibile. È possibile posizionare liberamente le icone delle app sulla schermata home senza la rigida griglia di una volta. Inoltre, la gestione degli sfondi è diventata più intuitiva, rendendo più facile cambiare e organizzare i wallpaper.

4. Aggiornamenti a Note, Promemoria e Calendario #

Per chi di noi usa quotidianamente le app di produttività integrate, iOS 18 ha introdotto alcune utili novità. In Note ora ci sono le sezioni comprimibili, mentre in Promemoria la funzione degli elenchi intelligenti rende la gestione delle attività un gioco da ragazzi. L'app Calendario ha introdotto una nuova vista mensile che rende la pianificazione ancora più efficiente. Si tratta di piccoli aggiornamenti incrementali, ma preziosi per rimanere organizzati.

5. Pagine web lette ad alta voce (la vera svolta) #

Questa potrebbe essere la killer feature di iOS 18. Ora è possibile farsi leggere ad alta voce intere pagine web o articoli, anche con lo schermo spento. Siri ora offre controlli per riproduzione, pausa e velocità di lettura, rendendo il tutto incredibilmente comodo. Prima mi affidavo a Microsoft Edge per questo, ma ora Siri è in grado di gestirlo, almeno per i contenuti in italiano (visto che uso Siri in italiano). Per gli articoli in inglese probabilmente continuerò a usare Edge per ora, ma questa funzione è una fantastica aggiunta per la navigazione a mani libere.

6. Una nuova app Password per una gestione sicura #

iOS 18 introduce anche una nuova app Password, che consente di gestire password, passkey e codici di autenticazione a due fattori in un unico posto. È uno strumento utile per chi non utilizza già un gestore di password di terze parti. Personalmente, continuerò a usare KeePass e KeePassX perché ho bisogno di condividere alcune password con dispositivi non Apple e non voglio rischiare di rimanere bloccato fuori da tutto se dovessi perdere l'accesso al mio Apple ID.

Conclusione #

Queste sono le mie funzioni preferite che hanno reso iOS 18 un vero piacere da usare. Con una digitazione multilingue più fluida, una dettatura più intelligente e una maggiore personalizzazione, Apple ha davvero fatto un salto di qualità. E non dimentichiamo la comodità di farsi leggere le pagine web da Siri o il nuovo gestore di password integrato. iOS 18 si presenta come una solida evoluzione che migliora le attività quotidiane, rendendo la vita un po' più semplice.

Mitigare il CLS causato da banner promozionali: una soluzione pratica

2024-08-26T00:00:00Z

Un sito web con un banner promozionale in alto che spinge verso il basso il contenuto sottostante

Il Cumulative Layout Shift (CLS) è una metrica Core Web Vital che misura la stabilità visiva. Si verifica quando il contenuto di una pagina web si sposta in modo imprevisto, causando spesso frustrazione negli utenti.

Una causa comune di CLS è l'iniezione di un banner promozionale nella parte superiore della pagina dopo che il contenuto principale è già stato caricato. Questo spinge verso il basso gli altri elementi della pagina, portando a una pessima esperienza utente. Sfortunatamente, questo esito è un problema molto comune che si verifica nei siti web su cui ho lavorato o per cui ho fatto consulenza.

In questo post, esploreremo un metodo per mitigare il CLS riservando spazio per un banner promozionale tramite il session storage. Questo approccio assicura che il banner non causi spostamenti di layout nei successivi caricamenti di pagina, offrendo un'esperienza più stabile e intuitiva per l'utente.

Il problema #

Nello scenario descritto in precedenza, la logica per determinare se mostrare o meno il banner viene eseguita tramite JavaScript, spesso dopo che il contenuto della pagina è già visibile. Ciò comporta uno spostamento del layout, in cui tutto il contenuto al di sotto del banner viene improvvisamente spinto verso il basso, causando un'esperienza utente fastidiosa.

La soluzione #

Per risolvere questo problema, possiamo usare sessionStorage per ricordare il contenuto e lo stato del banner durante la sessione dell'utente. In questo modo, possiamo iniettare il contenuto del banner immediatamente al caricamento della pagina, evitando qualsiasi spostamento di layout. Se l'utente ha chiuso il banner, ci assicuriamo che rimanga nascosto per il resto della sessione, in modo che non venga mostrato al caricamento successivo.

Ecco come possiamo implementarlo:

Verificare se il banner è stato precedentemente chiuso:
Per prima cosa controlliamo se l'utente ha chiuso il banner nella sessione corrente. In tal caso, non lo mostriamo di nuovo.
Iniettare il contenuto del banner:
Se il banner non è stato chiuso e c'è del contenuto salvato nel session storage, lo iniettiamo nella pagina il prima possibile. Questo evita che il layout si sposti quando il banner viene effettivamente caricato.
Salvare il contenuto del banner:
Quando il contenuto promozionale viene recuperato per la prima volta, lo salviamo nel session storage. Questo ci consente di riutilizzarlo nei successivi caricamenti di pagina senza causare alcuno spostamento di layout.
Gestire la chiusura del banner:
Se l'utente chiude il banner, impostiamo un flag nel session storage per assicurarci che non ricompaia durante la stessa sessione.

Implementazione #

Trovate qui il repository GitHub con il codice e la live demo su GitHub Pages.

Per comodità, ecco il codice copiato e incollato dalla pagina dimostrativa.

document.addEventListener("DOMContentLoaded", function () {
  const bannerContainerId = "promo-banner"; // ID del contenitore del banner
  const bannerSessionKey = "promoBannerContent";
  const bannerClosedKey = "promoBannerClosed";

  // Funzione per verificare se il banner è stato chiuso dall'utente
  const isBannerClosed = () =>
    sessionStorage.getItem(bannerClosedKey) === "true";

  // Controlla se il banner è stato chiuso in precedenza dall'utente. Se sì, non fare nulla.
  if (isBannerClosed()) return;

  // Funzione per iniettare il banner nella pagina
  const injectBanner = (bannerContent) => {
    const bannerContainer = document.getElementById(bannerContainerId);
    if (bannerContainer) {
      bannerContainer.innerHTML = bannerContent;
      bannerContainer.style.display = "block";
    }
  };

  // 👀 Controlla se il contenuto del banner esiste in sessionStorage, ed eventualmente iniettalo
  const savedBannerContent = sessionStorage.getItem(bannerSessionKey);
  if (savedBannerContent) {
    injectBanner(savedBannerContent);
  }

  // Funzione per simulare il recupero della promozione.
  const loadPromotion = () => {
    setTimeout(() => {
      const bannerContent = "<div>Il tuo contenuto promozionale qui</div>";

      // Inietta il contenuto del banner
      injectBanner(bannerContent);

      // 👀 Salva il contenuto del banner in sessionStorage per la prossima volta
      sessionStorage.setItem(bannerSessionKey, bannerContent);
    }, 600);
  };

  // Funzione per gestire l'azione di chiusura del banner
  const closeBanner = () => {
    sessionStorage.setItem(bannerClosedKey, "true");
    const bannerContainer = document.getElementById(bannerContainerId);
    if (bannerContainer) {
      bannerContainer.style.display = "none";
    }
  };

  // Simula il recupero della promozione
  loadPromotion();

  // Esempio di event listener per la chiusura del banner
  document
    .getElementById("close-banner")
    .addEventListener("click", closeBanner);
});
</script>

Come funziona #

Session Storage: viene utilizzato per memorizzare il contenuto promozionale e lo stato di chiusura del banner. I dati persistono tra i caricamenti di pagina all'interno della stessa sessione, garantendo un'esperienza utente coerente.
Iniezione immediata: iniettando immediatamente il contenuto salvato nella pagina, evitiamo qualsiasi spostamento di layout che si verificherebbe se il banner venisse caricato dopo che la pagina è stata completamente renderizzata.
Controllo dell'utente: se l'utente chiude il banner, questo non ricomparirà durante la stessa sessione, garantendo il rispetto delle preferenze dell'utente.

Conclusione #

Sfruttando il session storage per gestire la visualizzazione dei banner promozionali, puoi ridurre significativamente il CLS sul tuo sito web. Questo approccio non solo migliora l'esperienza utente, ma ottimizza anche le metriche prestazionali del sito, contribuendo a una migliore SEO e a tassi di coinvolgimento più elevati.

Questo metodo è particolarmente utile per i siti web con contenuti dinamici, in cui la decisione di mostrare determinati elementi viene presa dopo il caricamento della pagina. Pianificando questi elementi in anticipo, puoi creare un'esperienza più fluida e stabile per i tuoi utenti.

Questo approccio è un modo semplice ma efficace per affrontare una delle cause comuni di CLS, e può essere implementato con modifiche minime al codebase esistente.

Impressioni su Google I/O Connect 2024 + GDE Forum a Berlino

2024-08-01T00:00:00Z

Google I/O è l'evento annuale di Google per sviluppatori che si tiene nei loro uffici in California, negli USA. Google I/O Connect è una serie di eventi pratici in presenza per sviluppatori che si tengono in tutto il mondo, per aiutare a mettere in pratica le tecnologie e gli annunci del Google I/O tramite sessioni dal vivo, demo, codelab, office hour e altro ancora. Come l'anno scorso, sono stato invitato al Google I/O Connect EMEA 2024. E in qualità di Google Developer Expert (GDE), il giorno successivo ho partecipato anche al GDE Forum presso gli uffici Google di Berlino. Continua a leggere per scoprire com'erano questi eventi e cosa mi è piaciuto di più.

Io, comodamente appoggiato alla barra tra la I e la O del logo di Google I/O Connect

La cena della community #

Il giorno prima della conferenza, Google organizza una cena per far incontrare Google Developer Experts (GDE), Women Tech Makers (WTM), organizzatori di Google Developer Groups (GDG) e persone che lavorano in Google (i cosiddetti Googler) nel programma GDE o come developer relationship (devrel).

Persone che chiacchierano alla cena della community

L'obiettivo dell'evento è socializzare, conoscere nuove persone, fare rete con quelle che già si conoscono, rafforzare i legami personali e professionali; il tutto mangiando, bevendo e discutendo delle ultime novità del settore.

Da sinistra: Ines Akrap, io, Barry Pollard, Fabian Krumbholz, Medhat Dawoud, Jad Joubran, Erwin Hofman, Joan León, Anna Migas.

L'evento mi è piaciuto molto, ho trascorso la maggior parte del tempo a chiacchierare con altri GDE di web performance e Googler - in particolare Barry Pollard (web performance developer advocate per Google Chrome) e Jocelyn -, ho passato un po' di tempo con la community dei GDG italiani, ho finito per cantare al karaoke con la mia ex collega Ines e, una volta terminato l'evento, ho fatto una lunga passeggiata fino all'hotel con Paolo Galeone, un GDE di Machine Learning che è volato con me da Bologna.

L'evento principale Google I/O #

Il palco principale è stato calcato dai Googler per il keynote iniziale, e io ero lì, seduto in prima fila come piace a me (soprattutto perché sono miope).

Io, Aleksander Denisov e Rowdy Rabouw seduti in prima fila

Tuttavia, Google I/O Connect NON è una replica del Google I/O, quindi Google richiede di guardare in anticipo i video di ciò che è stato presentato all'evento principale I/O. Poi, a Google I/O Connect, si ha la possibilità di fare domande ai Googler presenti sul palco in merito agli argomenti presentati.

L'evento è suddiviso in diverse aree tematiche (Web, AI, Android, Flutter, ecc.) in modo da poter seguire quelle di maggiore interesse. Ad esempio, ho trascorso la maggior parte del tempo nell'area Web, seguendo interventi sulle nuove funzionalità della UI web, sull'ultima release di Angular, ecc.

Una Kravetz, Bramus e Barry Pollard di Google sul palco di The Latest in Web UI

Lì ho anche avuto la fortuna di incontrare Nishu Goel, che l'anno scorso ha fatto un ottimo lavoro analizzando l'Interaction to Next Paint (INP) e ha tenuto un talk al riguardo alla conferenza Performance Now; per me è una vera rockstar, ma non avevo mai avuto l'opportunità di incontrarla di persona. Quindi, ancora networking.

Ancora networking! Da sinistra: io, Jeremy Wagner, Fabian Krumbholz e Nishu Goel

Questo evento era aperto a tutti gli invitati alla cena della community, più altre persone che hanno partecipato acquistando un biglietto.

GDE Forum #

Il forum GDE era riservato esclusivamente ai Google Developer Experts e aveva un numero di posti limitato (150), per cui vi hanno potuto accedere solo i primi a registrarsi. Io sono stato tra i fortunati, ma conosco molti che sono rimasti in lista d'attesa senza riuscire a entrare.

Io all'ingresso del GDE Forum di Berlino presso gli uffici Google

Qui ho avuto l'opportunità di vedere in anteprima e fornire feedback su alcune delle funzionalità a cui sta lavorando il team di Google Chrome Developer Tools (che non posso rivelare in quanto coperte da NDA) e di partecipare a una sessione di debug live dell'INP con Barry Pollard (l'evento più apprezzato secondo il sondaggio finale).

Keynote iniziale per il GDE Forum

E naturalmente, ancora networking!

Ancora networking con Nishu Goel e Barry Pollard

Per concludere, è stato un evento molto piacevole e utile a cui partecipare, e spero di avere l'opportunità di esserci anche l'anno prossimo.

Il talk di Jake Archibald "In the loop", trascritto

2024-02-17T00:00:00Z

Il talk di Jake Archibald "In the loop" (JS Conf Asia) è ancora una delle migliori fonti di informazioni su come i browser elaborano i task e riescono a rispondere all'input dell'utente. Non avendo trovato nulla di così comprensibile in formato testuale, ho deciso di trascrivere il suo intervento in questo articolo. Trovi il video alla fine.

Main thread e ordine deterministico #

Prendi i seguenti frammenti di codice:

document.body.appendChild(el);
el.style.display = 'none';

el.style.display = 'none';
document.body.appendChild(el);

Diresti che si comportano allo stesso modo per quanto riguarda l'esperienza dell'utente? Gli utenti vedranno un lampeggiamento dovuto all'elemento aggiunto al DOM e subito nascosto?

La risposta è che i due frammenti di codice si comportano esattamente allo stesso modo, e questo a causa di come funziona il thread principale (main thread).

Il thread principale (main thread) #

Lo chiamiamo thread principale perché qui accadono un'infinità di cose. È dove viene eseguito JavaScript. È dove avviene il rendering. È dove vive il DOM.

Ciò significa che le operazioni sul web hanno un ordine deterministico. Non abbiamo diversi frammenti di codice che girano contemporaneamente cercando di modificare lo stesso DOM, il che porterebbe a una sfilza di terribili race condition.

Ma significa anche che se qualcosa sul thread principale richiede molto tempo (ad esempio 200 millisecondi, che è un'eternità in termini di interazione dell'utente), allora diventa estremamente evidente perché ha bloccato molte altre cose, come il rendering e l'interattività.

Pensa a un blocco del thread principale come a quando starnutiamo. Tutto il resto si ferma finché lo starnuto non è finito. Inutile dire che non vogliamo scrivere codice che si comporti come uno starnuto.

Quindi, sebbene ci sia questo thread principale, tendiamo ad avviare tutta una serie di thread collaterali (ad esempio per le richieste di rete, la codifica e decodifica, la crittografia, il monitoraggio dei dispositivi di input), ma una volta che questi thread hanno completato un'operazione di cui la pagina deve essere a conoscenza, devono in qualche modo tornare al thread principale per fornirgli queste informazioni. Ed è proprio l'event loop che orchestra tutto questo.

Le code dei task (Task queues) #

Prendi setTimeout, ad esempio. Hai mai pensato a come funzioni in realtà? Quando viene invocato, deve eseguire i seguenti passaggi:

attendere ms millisecondi
invocare la callback

Fatto.

Eseguiamo questi passaggi in parallelo — il che è un modo per dire che usciamo dal thread principale per eseguire questa roba contemporaneamente ad altro — ma così facendo creiamo un nuovo problema, perché ora stiamo invocando una callback da qualcosa che non è il thread principale, e questo non può funzionare. Finiresti per avere molto codice JavaScript in esecuzione in parallelo che modifica lo stesso DOM, creando inevitabili race condition.

Quindi facciamo così: accodiamo un task. Accodiamo un task per tornare sul thread principale a un certo punto, e a quel punto eseguiamo JavaScript sul thread in cui vive JavaScript, facendo funzionare tutto correttamente.

Conosciamo l'event loop #

Questo è come Jake descrive l'event loop. È un cerchio, l'esecuzione gira continuamente finché un task non viene accodato nella "deviazione dei task" a sinistra.

Ora, cosa succede se facciamo questo:

setTimeout(callback1, 1000);
setTimeout(callback2, 1000);

Ebbene, secondo le specifiche, questi due algoritmi vengono eseguiti in parallelo, ciascuno attende mille millisecondi, e poi devono tornare al thread principale. E lo fanno accodando un task.

Quindi, il browser dice all'event loop: "Ehi, ho qualcosa qui che vuole eseguire del lavoro sul thread principale. Anzi, ho due cose", e aggiunge ciascuna di esse come un elemento separato nella coda dei task.

Ora due task sono pianificati per l'esecuzione nella coda dei task

L'event loop risponde: "Certo, va bene, me ne occuperò". Quindi, esegue la prima callback, fa un giro dell'event loop ed esegue la seconda.

E questi sono i task. Sarebbe piuttosto semplice se fosse tutto qui, ma le cose si complicano quando consideriamo gli step di rendering.

Gli step di rendering (render steps) #

Questo è ciò che il browser utilizza per aggiornare effettivamente ciò che appare sullo schermo.

Sul lato destro dell'event loop, gli step di rendering: style, layout, painting

Gli step di rendering sono un'altra deviazione e coinvolgono il calcolo dello stile.

Style (S): consiste nell'analizzare tutto il CSS presente e calcolare cosa si applica a ciascun elemento.
Layout (L): consiste nel creare un render tree, calcolando la posizione e le dimensioni di ogni elemento nella pagina.
Paint (P): consiste nel generare i dati effettivi dei pixel, eseguendo il disegno vero e proprio sulla pagina.

Quindi, a un certo punto il browser dirà all'event loop: "Ehi, sai, dobbiamo aggiornare lo schermo" e l'event loop risponderà: "Nessun problema, me ne occuperò al prossimo giro dell'event loop".

Un ciclo infinito con `while(true)` #

Ecco una pagina con una GIF, del testo e un grande pulsante che avvia un ciclo infinito in JavaScript.

Una pagina semplice con la GIF di un gatto, del testo e un pulsante per il ciclo infinito

button.addEventListener('click', (event) => {  
    while(true);
});

Quindi, se clicco quel pulsante, tutto si ferma. La GIF si blocca. Non posso più selezionare il testo. L'intera scheda va in stallo.

Visualizzazione dell'event loop che esegue un ciclo infinito

L'utente clicca sul pulsante, quindi il browser dice: "Ehi, event loop, ho un task per te", e l'event loop risponde: "Sì, nessun problema, me ne occupo io". Ma questo task non finisce mai. Continua a eseguire JavaScript all'infinito.

Un paio di millisecondi dopo il browser dice: "Ehi, event loop, dobbiamo aggiornare la GIF sulla pagina. Quindi, se potessi effettuare il rendering non appena sei libero, sarebbe fantastico". L'event loop risponde: "Sì, okay, me ne occuperò subito dopo aver finito questo ciclo infinito in cui sono impegnato in questo momento".

Poi l'utente prova a evidenziare del testo, il che comporta operazioni come l'hit testing ed esaminare il DOM per capire quale sia il testo effettivo. Quindi, il browser dice: "Ehi, ho altri elementi da aggiungere alla tua lista di cose da fare". E l'event loop risponde: "Stai scherzando? Hai idea di quanto tempo ci voglia per completare un ciclo infinito? È un sacco di tempo. C'è un indizio nel nome stesso".

Ecco perché un ciclo while blocca il rendering e le altre interazioni della pagina. Ma nella pratica questo è un bene. Diamo di nuovo un'occhiata al codice iniziale.

document.body.appendChild(el);
el.style.display = 'none';

Un tempo mi preoccupavo che questo potesse causare un lampeggiamento dei contenuti (flash of content), ma non è possibile, giusto? Perché questo script viene eseguito come parte di un task, il quale deve essere completato del tutto prima che il browser possa tornare a occuparsi degli step di rendering.

L'event loop garantisce che il tuo task sarà completato prima che avvenga il rendering successivo.

Un ciclo infinito con `setTimeout()` #

Questo è un ciclo, ma ogni volta che lo eseguiamo usiamo setTimeout per accodare la chiamata successiva.

function loop() {
    setTimeout (loop, 0);
}
loop();

Se eseguiamo questo ciclo setTimeout nella pagina demo, sembra che non sia cambiato nulla, ma ecco cosa succede dietro le quinte.

L'esecuzione di un ciclo setTimeout esegue un singolo task, per poi accodarne un altro

Accodiamo un task, facciamo un giro dell'event loop, prendiamo quel task e, di conseguenza, ne accodiamo un altro.

Questo continua a succedere all'infinito, ma come abbiamo già visto, può essere elaborato solo un task alla volta. Quindi, quando elabora un task, l'event loop deve fare un intero giro completo per raccogliere il task successivo.

Ciò significa che a un certo punto il browser può dire: "Uhm, dovremmo aggiornare la visualizzazione di quella GIF", perché in quel momento ha la possibilità di deviare e aggiornare lo schermo.

Dopo l'esecuzione di quella callback di setTimeout, il ciclo è in grado di effettuare il rendering

Ed è per questo che un ciclo setTimeout non blocca il rendering.

`requestAnimationFrame` #

Ora, se vuoi eseguire del codice che ha a che fare con il rendering, un task è davvero il posto sbagliato per farlo, perché un task si trova all'estremo opposto rispetto a tutto ciò che riguarda il rendering, per quanto concerne l'event loop. Quello che vogliamo fare è eseguire il codice negli step di rendering.

Vogliamo eseguire il codice qui:

requestAnimationFrame è il riquadro giallo etichettato come "rAF" che appare prima del blocco di calcolo dello stile (S) nella deviazione del rendering

E il browser ci permette di farlo utilizzando requestAnimationFrame.

Le callback "rAF" vengono eseguite come parte degli step di rendering. Per mostrare perché questo sia utile, animerò una scatola, una semplice scatola, usando questo codice.

Il riquadro che sta per essere animato

function callback() {
	moveBoxForwardOnePixel();
	requestAnimationFrame(callback);
}
callback();

Quindi sposterò il riquadro in avanti di un pixel, e poi userò requestAnimationFrame per creare un ciclo. Tutto qui. Non fa nient'altro.

Ma cosa succederebbe se sostituissimo requestAnimationFrame con setTimeout?

function callback() {
	moveBoxForwardOnePixel();
	setTimeout(callback, 0);
}
callback();

Il risultato è questo:

I due riquadri mentre vengono animati. Quello con setTimeout si muove più velocemente di quello con requestAnimationFrame

Il nuovo riquadro animato con setTimeout si muove circa 3,5 volte più velocemente, il che significa che questa callback viene chiamata più spesso, e questo non è affatto un bene.

Abbiamo visto in precedenza che il rendering può avvenire tra un task e l'altro. Ma solo perché può avvenire, non significa che debba per forza succedere.

Possiamo eseguire un task, chiederci "Dobbiamo fare il rendering?" e la risposta potrebbe essere "No, non ne vale ancora la pena".

Dobbiamo renderizzare? Non ancora.

Facciamo un giro dell'event loop, prendiamo un altro task. "Renderizziamo adesso?", "No, non sembra il momento giusto". Possono verificarsi molti task prima che il browser decida: "Sì, in realtà al prossimo giro aggiorneremo lo schermo".

Dobbiamo renderizzare? Ora è il momento.

Il browser decide quando fare questo e cerca di essere il più efficiente possibile. Gli step di rendering avvengono solo se c'è effettivamente qualcosa da aggiornare. Se non è cambiato nulla, non si disturberà.

Ad esempio, se la scheda del browser è in background e non è visibile, non eseguirà mai gli step di rendering perché non avrebbe senso. Inoltre, la maggior parte degli schermi si aggiorna a una frequenza fissa. Nella maggior parte dei casi si tratta di 60 volte al secondo. Alcuni schermi sono più veloci, altri più lenti, ma i 60 Hz rappresentano lo standard più comune.

Quindi, se modificassimo gli stili della pagina mille volte al secondo, il browser non eseguirebbe gli step di rendering mille volte al secondo: si sincronizzerà con lo schermo e renderizzerà solo fino alla frequenza massima supportata dal display. Solitamente, 60 volte al secondo.

Altrimenti sarebbe solo una perdita di tempo; non ha senso renderizzare elementi che l'utente non vedrà mai. Ma è proprio quello che fa setTimeout in questo caso. Si muove più velocemente perché aggiorna la posizione del riquadro più volte di quante l'utente possa effettivamente vederlo, più volte rispetto a quanto il display sia in grado di mostrare.

Altri modi per accodare un task #

Finora abbiamo usato setTimeout come scorciatoia per dire "accodare un task", ma in realtà non lo è. Anche se impostiamo 0 millisecondi per la callback, il browser utilizzerà di default circa 4,7 millisecondi (le specifiche dicono che il browser può scegliere qualsiasi numero, ma Jake ha effettuato test e misurazioni precise).

I tre riquadri mentre vengono animati. Quello etichettato come queueTask si muove così velocemente da apparire in posizioni casuali sulla sua riga

Non esiste un singolo metodo che si limiti ad accodare un task, ma possiamo simularlo usando i MessageChannel. Jake ha fatto un test proprio con questo approccio.

Il risultato è che si verificano così tanti task che il riquadro sembra assumere posizioni casuali. Riceviamo un task ogni due centesimi (2/100) di millisecondo. Quindi il rendering può avvenire tra i task, ma si possono avere molti task, persino decine di migliaia, tra un rendering e l'altro.

Task e frame nel tempo #

Immaginiamo che ciascuno di questi sia un frame mostrato all'utente.

Quindi, i nostri step di rendering avvengono all'inizio di ciascun frame e questo include il calcolo dello stile, il layout e il paint, anche se non necessariamente tutti e tre ogni volta.

Tre frame, ciascuno contenente un task di stile (viola) e uno di rendering (verde)

Dipende da cosa deve effettivamente essere aggiornato, ma questo mi piace. È molto ordinato e pulito. È una bellissima rappresentazione.

I task vengono eseguiti ovunque durante un singolo frame

I task, d'altro canto, non si curano affatto del frame. Appaiono semplicemente dove capita. L'event loop garantisce che avvengano nel giusto ordine, ovvero l'ordine in cui sono stati accodati, ma in termini di tempistiche all'interno di un singolo frame non vi è alcun tipo di sincronizzazione.

E lo abbiamo visto con il nostro setTimeout. Ne ricevevamo tre o quattro per frame, il che significa che tre quarti di quelle callback erano sforzi inutili in termini di rendering.

3 task su 4 evidenziati come sforzo sprecato in termini di rendering

Le vecchie librerie di animazione facevano qualcosa del genere, cercando di usare un valore in millisecondi che desse loro circa 60 callback al secondo...

setTimeout (animFrame, 1000 / 60);

...e assumevano molto sullo schermo. Si dava per scontato che lo schermo fosse a 60 Hz, che all'epoca era il caso comune.

I task vengono pianificati in ogni frame usando setTimeout

Funzionava in qualche modo, eliminando parte del lavoro duplicato. Purtroppo si trattava di un enorme hack, perché setTimeout non è stato progettato per le animazioni e questo si nota: a causa di imprecisioni temporali si finisce per avere delle discrepanze (drift).

Un task doveva essere eseguito nel secondo frame, ma è stato eseguito nel terzo frame

Quello che succede qui è che non facciamo nulla in un frame e poi nel frame successivo facciamo il doppio del lavoro; questo provoca un'interruzione visiva (visual jank) per l'utente, e non è bello da vedere.

Inoltre, si blocca uno dei tuoi task per molto tempo, puoi finire per spostare gli step di rendering perché tutto gira sullo stesso thread, andando a disturbare quella precisa routine del browser.

I frame partono all'interno di ciascun blocco, e il primo di essi viene eseguito a cavallo del frame successivo

Se usiamo requestAnimationFrame anziché setTimeout, la situazione apparirà molto più simile a questa. Tutto pulito e ordinato. Tutto in fila. Ogni cosa rientra nelle tempistiche del frame, persino questo task più lungo.

I task sono raggruppati all'inizio di ogni frame, utilizzando requestAnimationFrame invece di setTimeout

Jake afferma che quando vede tracce di performance come queste si sente felice, perché mostrano una buona esperienza utente.

Ovviamente non si possono evitare completamente i task, perché elementi come gli eventi click ti verranno recapitati tramite un task, e in genere si desidera rispondere ad essi il prima possibile. Ma se hai timer o dati provenienti dalla rete, Jake consiglia di usare requestAnimationFrame per raggruppare quel lavoro, specialmente se hai già delle animazioni in corso, in modo da risparmiarti un sacco di lavoro duplicato.

Task e tempistiche di rendering #

C'è un ultimo dettaglio su cui voglio soffermarmi, ed è qualcosa che trae in inganno molti sviluppatori (ha ingannato anche me). requestAnimationFrame viene eseguito prima dell'elaborazione del CSS e prima del paint.

button.addEventListener('click', () => {
	box.style.display = "none";
	box.style.display = "block";
	box.style.display = "none";
	box.style.display = "block";
	box.style.display = "none";
	box.style.display = "block";
	box.style.display = "none";
	box.style.display = "block";
	box.style.display = "none";
});

Quindi, un codice come questo potrebbe sembrare costoso, dato che stiamo mostrando e nascondendo un elemento molte volte, ma in realtà è molto economico, poiché JavaScript completerà sempre la sua esecuzione prima che avvenga il rendering.

Quindi, mentre fai questo, il browser si rilassa, ti lascia divertire a cambiare i valori e non pensa minimamente al CSS. Alla fine, quando arriva il momento di eseguire gli step di rendering, analizza la situazione e si chiede: "Ok, cosa hai effettivamente cambiato alla fine?" E l'unica parte che conta davvero è l'ultima riga.

So il codice sopra, in termini di rendering, equivale al seguente frammento:

button.addEventListener('click', () => {
	box.style.display = "none";
});

Animare un elemento? #

Sto omettendo la parte in cui Jake spiega come accodare del codice JavaScript per animare un elemento da 1000 a 500 pixel utilizzando una doppia callback requestAnimationFrame, poiché non è più rilevante al momento della scrittura: le Web Animation API, che all'epoca del talk di Jake erano disponibili solo su Chrome, sono ormai supportate da tutti i browser.

Microtask #

Negli anni '90, i browser volevano fornire agli sviluppatori un modo per monitorare le modifiche al DOM e il W3C creò i mutation event.

document.body.addEventListener('DOMNodeInserted', () => {
	console.log('Stuff added to the <body>');
});

In questo modo potevo dire, ad esempio, che volevo sapere quando un nodo veniva inserito all'interno dell'elemento body. E si riceveva anche una serie di altri eventi correlati.

Ma nella pratica questo approccio si è rivelato alquanto problematico.

Prendiamo questo pezzo di codice: sto inserendo cento elementi span all'interno dell'elemento body.

for (let i=0; i<100; i++) {
	const span = document.createElement('span');
	document.body.appendChild(span);
	span.textContent = 'Hello';
}

Quanti eventi ti aspetteresti di ricevere come risultato? Un solo evento? Un evento unico per l'intera operazione? No. 100 eventi? Uno per ogni span. Sì.

Ma anche un altro centinaio per span.textContent = 'Hello'; quando il nodo di testo entra nello span. E poiché questi eventi si propagano (bubble), questo semplice frammento di codice finirà per generare ben 200 eventi.

A causa di ciò, modifiche del DOM relativamente semplici finivano per scatenare migliaia di eventi, e se eseguivi anche solo un minimo lavoro all'interno di questi listener, questo si accumulava rapidamente diventando un disastro in termini di prestazioni.

Quello che volevamo davvero era un modo per ricevere notifiche su un blocco (batch) di queste operazioni, in modo simile a quanto visto prima per gli stili. Vogliamo che il browser si rilassi, ci lasci fare le nostre operazioni e poi, in un momento opportuno, ci segnali che qualcosa è cambiato. Qualcosa che rappresenti cumulativamente tutti questi cambiamenti.

Vogliamo ricevere la notifica una sola volta, non 200 volte. E la soluzione sono stati i mutation observer. Che hanno introdotto una nuova coda chiamata microtask.

Molta documentazione che ho letto sui microtask suggerisce che vengano eseguiti a ogni giro dell'event loop o dopo un task o qualcosa del genere, ed è in parte vero. C'è un punto specifico dell'event loop in cui i microtask vengono elaborati, ma in genere non è lì che li incontrerai. Essi vengono eseguiti anche ogni volta che JavaScript termina l'esecuzione di uno script.

Ciò significa che lo stack di JavaScript si svuota completamente, ed è proprio in quel momento che eseguiamo i microtask.

Quindi puoi trovarti con microtask eseguiti a metà di un task, o all'interno degli step di rendering come parte di requestAnimationFrame, praticamente ovunque possa essere eseguito JavaScript.

for (let i=0; i<100; i++) {
	const span = document.createElement('span');
	document.body.appendChild(span);
	span.textContent = 'Hello';
}

Ciò significa che questo JavaScript verrà eseguito fino alla fine, aggiungendo i cento span e i relativi contenuti. JavaScript termina l'esecuzione e viene attivata la callback del nostro mutation observer.

Anche le Promise fanno uso dei microtask.

Promise.resolve().then(() => console.log('Hey!'));
console.log('Yo!');

Quindi, qui accodiamo un microtask e poi stampiamo 'Yo!'. JavaScript ha terminato l'esecuzione. Quindi, passiamo ai microtask e stampiamo 'Hey!'.

Questo significa che quando la callback della Promise viene eseguita, hai la garanzia che nessun altro codice JavaScript si trovi a metà esecuzione in quel momento, poiché la callback della Promise è proprio alla base dello stack, ed è per questo che le Promise utilizzano i microtask.

Un ciclo infinito con `Promise.resolve()` #

Ma cosa succede se creiamo un ciclo utilizzando i microtask? In termini di codice, in modo simile a quanto fatto in precedenza con setTimeout in precedenza.

function loop() {
	Promise.resolve().then(loop);
}
loop();

Di nuovo la stessa demo: la GIF di un gatto, del testo e un pulsante con scritto "Microtask Loop"

Cliccando sul pulsante... il rendering si blocca e la scheda va in stallo esattamente come succedeva con il ciclo while, in modo del tutto diverso rispetto al setTimeout visto prima.

Quindi, le callback delle Promise sono asincrone, d'accordo, ma cosa significa in realtà asincrono? Significa semplicemente che avvengono dopo l'esecuzione del codice sincrono, ed è per questo che viene stampato 'Yo!' prima di 'Hey!'. Ma il semplice fatto di essere asincrono non significa che debba cedere il controllo al rendering, né che debba cedere il passo a una parte specifica dell'event loop.

Tre tipi di code: Tasks, Animation Callbacks, Microtasks

Finora abbiamo esaminato tre diverse code. Abbiamo visto la coda dei task, la coda delle callback di animazione (in cui avvengono le callback di requestAnimationFrame) e ora stiamo guardando i microtask. E, giusto per semplificarci la vita, ognuna di esse viene elaborata in modo leggermente diverso.

Come abbiamo visto con la coda dei task, preleviamo un solo elemento alla volta. E se viene accodato un altro elemento, questo va semplicemente alla fine della coda. E fin qui tutto bene.

L'elemento aggiuntivo aggiunto alla coda dei task non viene elaborato immediatamente

Le callback di animazione vengono eseguite fino al completamento, ad eccezione di quelle accodate durante l'elaborazione delle callback stesse, le quali vengono rimandate al frame successivo.

Tutti i task della coda requestAnimationFrame vengono elaborati, tranne quelli appena aggiunti

I microtask, d'altro canto, vengono elaborati fino al completo svuotamento della coda, inclusi tutti gli elementi che vengono accodati durante l'elaborazione stessa.

I nuovi microtask continuano ad essere elaborati fino a quando la coda non è vuota

Quindi, se aggiungi elementi alla coda alla stessa velocità con cui li elabori, continuerai a elaborare microtask all'infinito. L'event loop non può proseguire finché quella coda non si è svuotata del tutto. Ed è per questo che il rendering si blocca.

Altro nel video #

Il talk termina con alcuni quiz JavaScript sui microtask e sull'ordine di esecuzione, ma questo articolo è già lunghiiiiiissimo, quindi se vuoi davvero risolvere i quesiti ti consiglio di guardare il video.

Dovresti davvero guardare il video originale se non l'hai ancora fatto, perché le "slide" create da Jake utilizzano animazioni straordinarie che spiegano tutto in modo perfetto.

Conclusione #

Spero che tu abbia trovato utile questa trascrizione del talk di Jake! Mi ha davvero aiutato a capire come funzionano i browser sotto il cofano.

Mi ci è voluto un po' per scriverlo, se ti va offrimi un caffè su Kofi.

Snippet di web performance per il debug dell'INP in Chrome DevTools

2024-02-14T00:00:00Z

Uno screenshot del debug di un'interazione nella performance trace. Crediti: web.dev

Dopo averli tenuti sul mio computer per alcuni giorni, ho deciso di pubblicare su GitHub questa raccolta di snippet di web performance per fare il debug dell'INP in Chrome Developer Tools, o per inviare i dati ai tuoi sistemi di analytics.

👉 Trovali qui

Buon debug delle web performance!

Come usare scheduler.yield per migliorare la reattività delle pagine web

2023-08-31T00:00:00Z

Un'immagine casuale per rappresentare il dare la precedenza (yield)

Nell'agosto del 2023, Google ha introdotto scheduler.yield, disponibile come origin trial in Chrome 115 e versioni successive.

Cos'è #

scheduler.yield è una nuova funzionalità di Chrome che consente agli sviluppatori web di cedere esplicitamente il controllo (yield) al thread principale. Ciò può essere utile per attività che richiedono molto tempo, in quanto consente ad altri task di ottenere tempo di esecuzione sul thread principale prima (rispetto a dover attendere il completamento di task molto lunghi).

Quando cedi esplicitamente il controllo, stai dicendo al browser: "Ehi, capisco che il lavoro che sto per fare potrebbe richiedere del tempo, e non voglio che tu debba completarlo interamente prima di poter rispondere agli input dell'utente o ad altri task che potrebbero essere altrettanto importanti".

Questo aiuta a migliorare la reattività complessiva della pagina web, poiché il browser sarà in grado di concentrarsi su altre attività mentre il task a lungo corso è in esecuzione.

E, naturalmente, questo si rivelerà estremamente utile nel lavoro di ottimizzazione della metrica Interaction to Next Paint (INP), che diventerà una Core Web Vital a partire da marzo 2024.

Come usarlo #

Ecco come si usa:

async function yieldy () {
  // Do some work...
  // ...

  // Yield!
  await scheduler.yield();

  // Do some more work...
  // ...
}

Ma aspetta, si può usare solo su Chrome? Sì, ma in alternativa puoi ripiegare sul buon vecchio setTimeout per ottenere un comportamento simile.

L'unica differenza è che i browser che non supportano scheduler.yield cederanno il controllo senza il comportamento "front of queue" (in testa alla coda), poiché setTimeout sposta il lavoro rimanente in coda all'elenco dei task.

// A function for shimming scheduler.yield and setTimeout:
function yieldToMain () {
  // Use scheduler.yield if it exists:
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();
  }

  // Fall back to setTimeout:
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

// Example usage:
async function doWork () {
  // Do some work:
  // ...

  await yieldToMain();

  // Do some other work:
  // ...
}

Vuoi provarlo? #

Puoi provare scheduler.yield sul tuo browser abilitando il flag "experimental web platform features", come mostrato nella figura seguente:

Come abilitare le funzionalità sperimentali della piattaforma web nel browser Chrome

Dopodiché, potrai utilizzarlo:

Come appare `scheduler.yield` quando viene invocato nella console dei developer tools

Vuoi provarlo in produzione? #

Sì, puoi farlo! Al momento della scrittura di questo articolo (settembre 2023), scheduler.yield è in fase di origin trial in Chrome 115 e versioni successive. Puoi scoprire di più sulle origin trial e su come partecipare alla sperimentazione sul sito Chrome Developers: Guida introduttiva alle origin trial.

Leggi l'articolo completo con una spiegazione dettagliata sul blog di Chrome Developers: Introducing the scheduler.yield origin trial

Prepararsi a Interaction to Next Paint (INP), una nuova Core Web Vital da marzo 2024

2023-07-12T00:00:00Z

Il dipinto "Creazione di Adamo" di Michelangelo

Come consulente di web performance, sono sempre attento alle novità che influenzano l'esperienza utente dei siti web. Una di queste novità è l'introduzione da parte di Google di una nuova metrica chiamata Interaction to Next Paint (INP). Destinata a diventare una Core Web Vital a marzo 2024, l'INP è progettata per misurare il tempo impiegato da un sito web per rispondere alle interazioni degli utenti. In questo articolo approfondiremo cos'è l'INP, perché è importante e come le aziende possono prepararsi per garantire che i loro siti web soddisfino questa metrica fondamentale.

Comprendere l'Interaction to Next Paint (INP) #

L'INP è un'importante aggiunta alle Core Web Vitals, un insieme di metriche che Google utilizza per valutare e posizionare i siti web in base all'esperienza utente.

A differenza di altre metriche come il Largest Contentful Paint (LCP) e il Cumulative Layout Shift (CLS), che misurano rispettivamente il caricamento e la stabilità visiva, l'INP si concentra sull'interattività, ovvero sulla rapidità con cui un sito web risponde agli input degli utenti dopo il caricamento. Questa metrica quantifica il tempo necessario affinché il sito sia pronto a mostrare un aggiornamento visivo (paint) dopo l'interazione dell'utente, con l'obiettivo di garantire un'esperienza priva di ritardi percepibili.

Perché l'INP è importante #

Nel panorama digitale odierno, le aspettative degli utenti sono più alte che mai. Le persone esigono interazioni rapide e fluide quando navigano sul web, e qualsiasi ritardo o elemento che non risponde può causare frustrazione e abbandono. L'INP affronta direttamente questo problema misurando il tempo impiegato da un sito web per rispondere agli input degli utenti, un fattore cruciale per offrire un'esperienza utente eccezionale.

Inoltre, Google ha sottolineato l'importanza delle Core Web Vitals como fattore di posizionamento per la SEO. I siti web che offrono esperienze utente migliori, misurate da queste metriche, hanno maggiori probabilità di posizionarsi più in alto nei risultati di ricerca. Con l'INP destinato a diventare una Core Web Vital, le aziende che daranno priorità all'interattività del proprio sito non solo miglioreranno l'esperienza d'uso, ma otterranno anche un vantaggio in termini di visibilità sui motori di ricerca.

Prepararsi all'INP #

Con l'avvicinarsi della scadenza di marzo 2024, le aziende devono prepararsi all'inclusione dell'INP come Core Web Vital. Ecco alcuni passaggi per assicurarsi che il proprio sito sia pronto:

Valutare le prestazioni attuali dell'INP: inizia analizzando le prestazioni attuali dell'INP del tuo sito. Il modo più semplice per verificare i valori di INP del tuo sito web è tramite la Google Search Console. In alternativa, puoi utilizzare il Chrome User Experience Report (CrUX) o PageSpeed Insights. Misura i tuoi punteggi INP attuali e stabilisci obiettivi di miglioramento.
Migliorare l'INP: consulta il capitolo successivo per scoprire cosa fare per migliorare l'INP sul tuo sito web.
Monitorare e iterare continuamente: le prestazioni web sono un processo continuo, ed è fondamentale monitorare e misurare l'INP regolarmente. Analizza costantemente le prestazioni del tuo sito, implementa ottimizzazioni e ripeti i test per assicurarti che i punteggi INP soddisfino i target desiderati. Consulta regolarmente la documentazione per sviluppatori di Google e i forum della community per rimanere aggiornato sulle best practice.

Come migliorare l'INP #

Entriamo ora un po' più nel tecnico. Ci sono 3 tipi di azioni che puoi intraprendere per migliorare l'INP sul tuo sito web: evitare o spezzare i task lunghi (long tasks), evitare il JavaScript non necessario ed evitare aggiornamenti di rendering troppo grandi.

Evitare o spezzare i task lunghi #

I task (compiti) sono singole unità di lavoro eseguite dal browser. Includono il rendering, il calcolo del layout, il parsing, la compilazione e l'esecuzione degli script. Quando i task diventano "task lunghi" (long tasks)—ovvero durano 50 millisecondi o più—bloccano il thread principale (main thread), impedendogli di rispondere rapidamente agli input dell'utente.

Un'altra opzione è considerare l'uso di API come isInputPending e la Scheduler API. isInputPending è una funzione che restituisce un valore booleano indicante se c'è un input utente in attesa. Se restituisce vero, puoi cedere il controllo (yield) al thread principale in modo che possa gestire l'interazione pendente. Scopri di più su isInputPending per cedere il controllo solo quando necessario.

La Scheduler API è un approccio più avanzato, che consente di pianificare il lavoro in base a un sistema di priorità che tiene conto se l'attività in corso sia visibile all'utente o in background. Scopri di più sulla Scheduler API.

Spezzando i task lunghi, offri al browser maggiori opportunità di inserire tempestivamente il lavoro critico visibile all'utente, come la gestione delle interazioni e i relativi aggiornamenti di rendering.

Evitare il JavaScript superfluo #

Non c'è dubbio: i siti web stanno inviando più JavaScript che mai, e la tendenza non sembra destinata a cambiare a breve. Quando invii troppo JavaScript, crei un ambiente in cui i vari task competono per l'attenzione del thread principale. Questo può influire negativamente sulla reattività del tuo sito, specialmente durante la cruciale fase di avvio (startup).

Tuttavia, questo non è un problema irrisolvibile. Hai a disposizione diverse opzioni:

Usa lo strumento Coverage in Chrome DevTools per individuare il codice inutilizzato nelle risorse del tuo sito. Riducendo le dimensioni delle risorse necessarie all'avvio, farai in modo che il sito passi meno tempo a fare il parsing e a compilare il codice, a tutto vantaggio di una migliore esperienza utente iniziale. Scopri lo strumento Coverage.
A volte il codice inutilizzato trovato con lo strumento Coverage è contrassegnato come tale semplicemente perché non è stato eseguito all'avvio, ma è comunque necessario per funzionalità future. Questo è codice che puoi spostare in un bundle separato tramite il code splitting (divisione del codice). Scopri di più sul code splitting.
Se utilizzi un tag manager, assicurati di controllare periodicamente i tag per verificare che siano ottimizzati o se siano ancora effettivamente necessari. I vecchi tag con codice inutilizzato possono essere rimossi per rendere il JavaScript del tag manager più leggero ed efficiente. Ulteriori best practice per i tag manager.

Evitare aggiornamenti di rendering di grandi dimensioni #

Il JavaScript non è l'unico fattore che può influire sulla reattività del tuo sito. Il rendering stesso può essere un'attività molto onerosa e, quando si verificano aggiornamenti di rendering di grandi dimensioni, questi possono ostacolare la capacità del sito di rispondere tempestivamente agli input dell'utente.

Ottimizzare il lavoro di rendering non è un processo lineare e spesso dipende da ciò che si vuole ottenere. Ciononostante, ci sono alcune accortezze che puoi adottare per garantire che gli aggiornamenti di rendering siano contenuti e non si trasformino in task lunghi:

Evita di usare requestAnimationFrame() per attività non visive. Le chiamate a requestAnimationFrame() vengono gestite durante la fase di rendering dell'event loop e, se si esegue troppo lavoro in questa fase, gli aggiornamenti visivi possono subire ritardi. È fondamentale che qualsiasi operazione eseguita all'interno di requestAnimationFrame() sia riservata strettamente ad attività legate agli aggiornamenti di rendering.
Mantieni ridotte le dimensioni del DOM. Esiste una correlazione diretta tra la dimensione del DOM e l'onerosità del calcolo del layout. Quando il renderer deve aggiornare il layout per un DOM molto grande, il lavoro richiesto per ricalcolarlo aumenta in modo significativo. Evitare un DOM dalle dimensioni eccessive.
Usa il CSS containment. Questa tecnica si basa sulla proprietà CSS contain, che fornisce istruzioni al browser su come gestire il layout per il contenitore su cui è applicata, arrivando persino a isolare l'ambito del layout e del rendering a una radice specifica nel DOM. Non è sempre un processo semplice, ma isolando le aree con layout complessi si evita di eseguire per esse lavori di layout e rendering non necessari. Scopri di più sul CSS Containment.

Conclusione #

Con l'Interaction to Next Paint (INP) destinato a diventare una Core Web Vital a marzo 2024, le aziende dovrebbero iniziare a dare priorità all'interattività del proprio sito web per offrire un'esperienza utente eccezionale e migliorare il posizionamento sui motori di ricerca.

Valutando le prestazioni INP attuali, ottimizzando l'interattività e monitorando e iterando costantemente, le aziende possono prepararsi al meglio a questo cambiamento.

Adottare l'INP come metrica fondamentale per le prestazioni non porterà solo benefici agli utenti, ma contribuirà anche al successo a lungo termine della propria presenza online.

Hai bisogno di aiuto? #

Se desideri saperne di più sull'INP, su come ottimizzarlo o se hai bisogno di una consulenza sulle prestazioni web, non esitare a contattarmi.

Talk: Come e perché ($) migliorare le prestazioni web nel 2023

2023-06-16T00:00:00Z

Nel 2023 ho parlato di web performance in conferenze, Google Developer Groups (GDG) e meetup locali in tutta Europa. Il titolo di questo talk è "Come e perché ($) migliorare le prestazioni web: consigli pratici per il 2023".

La prima parte del talk illustra i motivi per cui ottimizzare le prestazioni web, mentre la seconda parte spiega come farlo, con consigli pratici provenienti da Google e basati sui dati raccolti nel capitolo dedicato alle performance del Web Almanac 2022.

Di seguito trovi le slide del mio talk, sia in inglese che in italiano.

Slides in English 🇬🇧 · Slide in Italiano 🇮🇹

WaysConf, Cracovia 🇵🇱 – 4 settembre 2023 #

Io che spiego la differenza tra strumenti di laboratorio (lab) e di monitoraggio reale degli utenti (RUM) al WaysConf 2023

📺 Video · Pagina del talk sul sito della conferenza

Dev BCN Conference, Barcellona 🇪🇸 – 4 luglio 2023 #

Io che presento una slide sulle Core Web Vitals sul palco della conferenza Dev BCN

Pagina del talk sul sito della conferenza

DevFest, Vienna 🇦🇹 – 14 ottobre 2023 #

Io sul palco che spiego cos'è Interaction to Next Paint

Programma del DevFest

Google Developer Group, Monaco di Baviera 🇩🇪 – 7 giugno 2023 #

Io che parlo davanti al pubblico negli uffici Google di Monaco di Baviera

Pagina dell'evento

Google Developer Group, Firenze 🇮🇹 – 25 maggio 2023 #

Io che parlo davanti al pubblico a Nana Bianca, Firenze

Titolo in italiano: "Come e perché ($) migliorare le Prestazioni Web: consigli pratici per il 2023".

Pagina dell'evento

Bologna JS + Google Developer Group, Bologna 🇮🇹 – 5 aprile 2023 #

Io sul palco durante l'evento a Bologna

Titolo in italiano: "Come e perché ($) migliorare le Prestazioni Web: consigli pratici per il 2023".

📺 Video · Pagina dell'evento Bologna JS · Pagina dell'evento GDG

Dev Romagna, Imola 🇮🇹 – 22 marzo 2023 #

La location e il pubblico durante la presentazione del gruppo Dev Romagna

Titolo in italiano: "Come e perché ($) migliorare le Prestazioni Web: consigli pratici per il 2023".

Pagina dell'evento Dev Romagna

Google Developer Group, Torino 🇮🇹 – 23 febbraio 2023 #

Un miglioramento di 1 secondo nel tempo di caricamento può migliorare il tasso di conversione del sito e ridurre la frequenza di rimbalzo

La splendida platea a Torino

Titolo in italiano: "Web Talks: from Design to Performance".

Pagina dell'evento

Bologna Front-End, Bologna 🇮🇹 – 15 febbraio 2023 #

Io sul palco dell'evento Bologna Front-End

Titolo in italiano: "Web performance per tutti".

📺 Video · Pagina dell'evento

Sono un Google Developer Expert per le Web Performance

2022-12-06T00:00:00Z

Nel dicembre 2023 sono diventato un Google Developer Expert (GDE) per le Web Performance. Google Developer Experts è un programma di Google per creare una rete globale di professionisti, influencer e leader di pensiero, e consentire loro di condividere le proprie conoscenze con la community degli sviluppatori, ad esempio parlando a eventi, condividendo best practice e offrendo mentorship ad altri.

Il logo di Google Developer Experts

Entrando a far parte del programma GDE, mi sono unito a una community di tecnologi appassionati da tutto il mondo, il che mi permette di fare rete con loro e con i team di Google.

Oltre ad essere inserito nella directory dei Google Developer Experts, avrò accesso anticipato ai prodotti e alle novità relative alle web performance.

Sentiti libero di contattarmi se vuoi fare due chiacchiere sul programma o sulle web performance.

aspect-ratio: Un modo moderno per riservare spazio a immagini e contenuti asincroni nel responsive design

2022-11-19T00:00:00Z

Per evitare lo spostamento del layout (layout shifting) e ottimizzare la metrica Cumulative Layout Shift delle Core Web Vitals nelle tue pagine web, devi riservare spazio per qualsiasi contenuto che potrebbe essere renderizzato in un secondo momento. Questo è il caso di immagini, video e qualsiasi contenuto caricato in modo asincrono (ad esempio tramite chiamate AJAX). Ecco un nuovo modo per farlo.

Il buon vecchio metodo #

Il metodo tradizionale per riservare spazio alle immagini consiste nell'utilizzare il trucco del padding verticale (padding-bottom hack).

<div class="image-wrapper">
	<img alt="An image" src="image.jpg" />
</div>

.image-wrapper {
	width: 100%;
	height: 0;
	padding-bottom: 150%;
	/* 👆 image height / width * 100% */
	position: relative;
}
.image {
	width: 100%;
	height: auto;
	position: absolute;
}

Il metodo moderno 1 - `aspect-ratio` mappato #

Il metodo moderno e più semplice consiste nel definire implicitamente un rapporto d'aspetto larghezza/altezza impostando gli attributi width e height su immagini e video. Questo approccio è noto come "mapped aspect-ratio".

<img alt="An image" src="image.jpg" width="200" height="300" />

<video alt="A video" src="video.mp4" width="1600" height="900">...</video>

/* Modern browser stylesheets will add a default
  aspect ratio based on the element's existing
  width and height attributes */
img,
video {
	aspect-ratio: attr(width) / attr(height);
}

La buona notizia è che sia i browser basati su Chromium (Chrome, Microsoft Edge e Opera), sia Firefox e Safari (a partire dalla versione 14) ora supportano l'aspect-ratio mappato! Di conseguenza, la stragrande maggioranza dei browser è coperta, mentre Internet Explorer sta scomparendo e Microsoft Edge si sta diffondendo.

Tuttavia, ci sono alcune accortezze da considerare quando si utilizza il lazy loading gestito da JavaScript.

Demo #

Ho creato una serie di demo su Codepen per testare l'aspect-ratio mappato in diversi scenari.

Caso d'uso	Funziona?	Demo
Lazy loading nativo (nessun placeholder richiesto)	🟢 Sì	Demo
Lazy loading Javascript (nessun placeholder, senza fix `display`)	🔴 No	Demo
Lazy loading Javascript (nessun placeholder, con fix `display`)	🟢 Sì	Demo
Lazy loading Javascript (placeholder SVG, senza fix `display`)	🟢 Sì	Demo

Con "fix display" intendo che ho dovuto impostare la proprietà display delle immagini su block, poiché lasciare il valore predefinito (inline-block) non funzionava correttamente per le immagini caricate in lazy loading tramite JavaScript.

Con "Funziona?" intendo se il browser ha riservato lo spazio per le immagini prima del loro effettivo caricamento. Per verificare tu stesso il funzionamento, usa i developer tools del tuo browser per disabilitare la cache ed emulare una velocità di rete "slow 3G". Dovresti notare che lo spazio viene riservato prima che le immagini inizino a caricarsi, posizionando il paragrafo di testo molto al di sotto delle immagini.

Il metodo moderno 2 - `aspect-ratio` esplicito #

In alternativa, è possibile impostare esplicitamente il rapporto d'aspetto direttamente nel codice CSS utilizzando la regola CSS aspect-ratio.

<div class="async">Content is loading...</div>

.async {
	aspect-ratio: 16/9;
}

~~Sfortunatamente, al momento (aprile 2021) questa funzionalità è supportata solo dai browser Chromium. Non sappiamo ancora se e quando sarà supportata nelle future versioni di Safari.~~

Aggiornamento di novembre 2021: questa proprietà è ora supportata da tutte le ultime versioni di tutti i browser (tranne Internet Explorer, ma... vabbè).

Conclusione #

Evviva! Oggi è finalmente possibile utilizzare l'aspect-ratio mappato per riservare lo spazio ai tuoi contenuti caricati in lazy loading, come immagini e video!

Basta impostare gli attributi width e height sulle immagini e scegliere una delle seguenti tre modalità:

Usare il lazy loading nativo con loading="lazy"
Usare il lazy loading JavaScript senza placeholder, ma applicando display: block alle immagini
Usare il lazy loading JavaScript con i placeholder

Non vedo l'ora di sapere come sei riuscito a ridurre il CLS delle tue pagine usando queste tecniche. Per favore contattami e fammi sapere!

Contro lo streaming online dei meetup locali

2022-11-19T00:00:00Z

Mi piace partecipare ai meetup locali. Sono informativi, divertenti e allo stesso tempo stimolanti dal punto di vista sociale. A volte viene chiesto agli organizzatori dei meetup di trasmettere gli eventi online. Sarebbe una bella funzionalità, ma a mio parere farebbe più male che bene alla community. Vi spiego perché.

Ascoltare l'argomento del meetup di persona, insieme ad altre persone che condividono i tuoi stessi interessi, concentrati sul relatore e sulle sue slide, è un tipo di esperienza. Guardare lo stesso evento da casa, davanti a uno schermo, da soli, con distrazioni che richiamano la tua attenzione e lontano da dove si svolge l'evento, è un'esperienza decisamente più debole.

Potresti facilmente trovare articoli di blog o tutorial online sullo stesso argomento del meetup, molto probabilmente di qualità superiore. Il vero valore di un meetup in presenza risiede nella socializzazione, nel fare rete, nello scambio di idee che avviene prima e dopo il talk e, se si vuole, in pizzeria subito dopo.

Inoltre, il fatto che un evento sia trasmesso anche online indebolisce l'evento in presenza. Qualcuno potrebbe pensare: "Ma chi me lo fa fare di andare in città, posso guardarlo in streaming". E poi, quando arriva il momento: "Ma chi me lo fa fare di guardarlo in diretta, guarderò la registrazione più tardi". E infine: "Ah, perché dovrei guardare la registrazione, cercherò un tutorial online". Forse.

Se parliamo di conferenze, tuttavia, ci sono alcune differenze. Le conferenze possono essere online, ma penso che debbano essere o online o offline, non entrambe le cose. Le conferenze online possono avere un pubblico più ampio, persino mondiale, e possono ridurre i costi per i partecipanti, oltre a essere più accessibili per chi ha disabilità motorie. Tuttavia, a mio parere, le conferenze in presenza rimangono le migliori, per gli stessi motivi: stare insieme a persone che condividono i tuoi stessi interessi, scambiare idee, ecc.

E tu cosa ne pensi? Sentiti libero di contattarmi e farmelo sapere!

Abbiamo ancora bisogno delle librerie di lazy loading e di `data-src`?

2022-11-13T00:00:00Z

In passato, quando il supporto dei browser per il lazy loading nativo non era diffuso, la best practice consisteva nell'usare gli attributi data-src e una libreria JavaScript come la mia vanilla-lazyload per caricare le immagini man mano che entravano nella viewport. Questa è ancora la best practice oggi?

Cos'è il lazy loading? #

Il lazy loading delle immagini è una tecnica per rimandare il caricamento delle immagini below-the-fold (sotto la piega) fino a quando non stanno per entrare nella viewport (la parte visibile della pagina). Questa tecnica fa risparmiare larghezza di banda, riduce i costi del CDN, abbassa l'impronta di carbonio del sito web e migliora il tempo di rendering della pagina, in particolare il Largest Contentful Paint.

Lazy loading delle immagini gestito da JavaScript #

Tradizionalmente, il lazy loading delle immagini comportava la sostituzione dell'attributo src con un attributo data-src e l'uso di JavaScript per rilevare quando le immagini si avvicinavano alla viewport, per poi copiare gli attributi data in quelli corretti, avviando così il loro caricamento differito.

<img
  data-src="turtle.jpg"
  alt="Lazy turtle"
  class="lazy"
/>

Lazy loading nativo #

Con il lazy loading nativo, detto anche lazy loading a livello di browser, basta aggiungere l'attributo loading="lazy" al tag <img>.

<img
  src="turtle.jpg"
  alt="Lazy turtle"
  loading="lazy"
/>

Questo funziona su tutti i browser moderni.

Abbiamo ancora bisogno del lazy loading gestito da JavaScript? #

No, a meno che non si desideri un maggiore controllo sul processo di lazy loading.

Vediamo quali sono i casi in cui ha senso usare il lazy loading guidato da JavaScript invece di affidarsi solo a loading="lazy".

1. Supportare gli utenti con connessioni lente o instabili #

Le librerie JavaScript come vanilla-lazyload possono annullare il download delle immagini che escono dalla viewport e riprovare i download se interrotti, migliorando l'esperienza utente sulle connessioni lente.

Un caso d'uso tipico è:

pagine con molte immagini +
utenti con connessioni lente +
scorrimento veloce verso il basso

Il lazy loading nativo fa sì che i browser scarichino le immagini in lazy loading dall'alto verso il basso, con conseguente ritardo nel mostrare le immagini in fondo.

Le librerie Javascript come vanilla-lazyload annulleranno il download delle immagini che escono dalla viewport, mantenendo la larghezza di banda dell'utente concentrata sulle immagini attualmente visibili.

Un altro caso d'uso è:

download delle immagini in corso
connessione di rete interrotta

vanilla-lazyload riproverà a scaricare quelle immagini una volta ripristinata la connessione.

Puoi provare queste funzionalità in una qualsiasi delle demo di vanilla-lazyload, come la demo del caso base, limitando o disattivando la velocità di connessione nei developer tools del tuo browser.

2. Callback avanzate o classi CSS #

Il lazy loading gestito da JavaScript fornisce callback e classi CSS per vari eventi (inizio caricamento, fine caricamento, errore, ingresso nella viewport, uscita dalla viewport, ecc.), consentendo di monitorare il processo e creare effetti visivi avanzati.

Queste callback e classi CSS possono essere molto utili per creare effetti visivi sulla pagina.

Scopri di più su callback e classi nelle API di vanilla-lazyload / opzioni.

3. Ottimizzare le performance web, nello specifico il Largest Contentful Paint #

Il lazy loading guidato da JavaScript offre un maggiore controllo su quali immagini vengono scaricate, aiutando a ottimizzare il Largest Contentful Paint (LCP).

Con il lazy loading nativo, non hai il controllo su quali immagini vengono scaricate dal browser.

Il caso d'uso:

alcune immagini sono sotto la piega ma non molto lontane
alcune immagini compaiono appena nella parte visibile della pagina

Il lazy loading nativo inizierebbe a scaricare queste immagini, che condividerebbero la larghezza di banda con il download dell'immagine LCP, mentre vorresti scaricare quest'ultima con la massima priorità.

Il lazy loading gestito da JavaScript come vanilla-lazyload fornisce API e opzioni per controllare con precisione quanto debbano essere distanti dalla viewport le immagini prima di iniziare a scaricarle.

4. Lazy loading di altre risorse #

Per effettuare il lazy loading di immagini di sfondo, video, SVG animati e altro, è ancora necessaria una libreria JavaScript come vanilla-lazyload.

Scopri di più #

Consulta la documentazione di vanilla-lazyload o il mio post sul blog lazy load delle immagini responsive nel 2020.

Talk: Velocizzare il web con le immagini responsive - LazyLoad Conference 2022

2022-06-24T00:00:00Z

Questo è un fermo immagine del video, prima di entrare nelle parti tecniche

Il 24 giugno 2022 ho parlato di ottimizzazione delle immagini responsive 4.0 alla conferenza LazyLoad 2022.

Il talk spiega come migliorare le prestazioni del proprio sito web automatizzando le immagini responsive con un approccio basato sui dati. Ecco il video dell'intervento.

Lo strumento menzionato nel talk è responsive-images-automator.

Talk: Ottimizzazione delle immagini 4.0, automatizza il tuo lavoro con un approccio incentrato sull'utente - CSS Day 2022

2022-04-01T00:00:00Z

Io sul palco del CSS Day 2022, Faenza

Il 1° aprile 2022 ho parlato di ottimizzazione delle immagini responsive 4.0 alla conferenza CSS Day 2022 a Faenza. Questo talk affronta il tema di come diventare più produttivi automatizzando la gestione delle immagini responsive. Ecco il video del mio intervento.

Lo strumento di cui ho parlato nel talk è responsive-images-automator.

Il talk è stato valutato molto positivamente! Leggi i feedback su joind.in.

Trovi di seguito le slide dell'intervento.

Come integrare git nel Terminale (shell) di Mac OS

2022-03-11T00:00:00Z

Ora che zsh è la shell predefinita sul terminale di Mac OS, potresti voler configurare il tuo nuovo Mac o il terminale di VS Code per avere un'integrazione intelligente con git, simile a git bash per Windows.

..." to update what will be committed) | (use "git restore ‹file>..." to discard changes in working directory) | modified: content/blog/how-integrate-git-autocomplete-mac-shell-terminal-bash-zsh/index.md | no changes added to commit (use "git add" and/or "git commit -a")" loading="eager" fetchpriority="high" src="https://andreaverlicchi.eu/img/fTQn3en4qR-648.png" width="648" height="403">

Terminale Mac OS con integrazione git

Dopo aver cercato in giro per un po' e aver trovato strumenti per l'integrazione con bash, ho finalmente trovato questo articolo che spiega come integrare git con zsh nel Terminale (o shell) di Mac OS.

Poiché zsh viene fornito con un framework per ottenere informazioni dai sistemi di controllo versione, chiamato vcs_info, puoi includere il nome del branch nel prompt sul lato destro aggiungendo queste righe al tuo file ~/.zshrc:

autoload -Uz vcs_info
precmd_vcs_info() { vcs_info }
precmd_functions+=( precmd_vcs_info )
setopt prompt_subst
RPROMPT='${vcs_info_msg_0_}'
# PROMPT='${vcs_info_msg_0_}%# '
zstyle ':vcs_info:git:*' formats '%b'

Zsh è così potente che esistono interi framework dedicati a migliorarlo. Uno di questi si chiama oh-my-zsh. Il sistema di plugin di oh-my-zsh offre un potente autocompletamento (tab-completion) per git e dispone di una varietà di "temi" per il prompt, molti dei quali mostrano i dati del controllo versione.

Puoi installare oh-my-zsh eseguendo il seguente comando:

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

Goditi il tuo nuovo terminale zsh integrato con i comandi git!

Una tecnica elegante per il lazy loading delle immagini in Swiper e la creazione lazy delle istanze di Swiper

2021-10-27T00:00:00Z

Immagina di avere più caroselli in una pagina, ognuno contenente più immagini, e di voler scaricare solo le immagini che si trovano all'interno della porzione visibile della pagina, magari risparmiando tempo di CPU creando le istanze del carosello in modalità lazy. Credo di aver trovato una tecnica valida ed elegante per farlo.

La tecnica seguente riguarda il lazy loading delle immagini all'interno di un'istanza di Swiper JS e la creazione differita (lazy) delle istanze di Swiper below-the-fold, utilizzando Swiper insieme a vanilla-lazyload.

Il codice HTML del primo carosello imposta un paio di immagini da caricare immediatamente (eager) in modo che i browser diano priorità al loro scaricamento, lasciando tutto il resto al lazy loading.

<div class="swiper swiper--eager">
	<div class="swiper-wrapper">
		<!-- Immagini caricate immediatamente (eager) -->
		<div class="swiper-slide">
			<img
				alt="Stivaletti"
				src="https://via.placeholder.com/220x280?text=S01E01"
				srcset="https://via.placeholder.com/440x560?text=S01E01 2x"
				width="220"
				height="280"
			/>
		</div>
		<div class="swiper-slide">
			<img
				alt="Stivaletti"
				src="https://via.placeholder.com/220x280?text=S01E02"
				srcset="https://via.placeholder.com/440x560?text=S01E02 2x"
				width="220"
				height="280"
			/>
		</div>
		<!-- Immagini caricate in lazy loading -->
		<div class="swiper-slide">
			<img
				alt="Stivaletti"
				class="lazy"
				data-src="https://via.placeholder.com/220x280?text=S01E03"
				data-srcset="https://via.placeholder.com/440x560?text=S01E03 2x"
				width="220"
				height="280"
			/>
		</div>
		<div class="swiper-slide">
			<img
				alt="Stivaletti"
				class="lazy"
				data-src="https://via.placeholder.com/220x280?text=S01E04"
				data-srcset="https://via.placeholder.com/440x560?text=S01E04 2x"
				width="220"
				height="280"
			/>
		</div>
		<div class="swiper-slide">
			<img
				alt="Stivaletti"
				class="lazy"
				data-src="https://via.placeholder.com/220x280?text=S01E05"
				data-srcset="https://via.placeholder.com/440x560?text=S01E05 2x"
				width="220"
				height="280"
			/>
		</div>
	</div>
	<div class="swiper-button-prev"></div>
	<div class="swiper-button-next"></div>
</div>

A partire dal secondo carosello, tutte le immagini vengono caricate in modalità lazy.

<div class="swiper swiper--lazy" id="swiperLazy1">
	<div class="swiper-wrapper">
		<!-- Tutte le immagini caricate in lazy loading -->
		<div class="swiper-slide">
			<img
				alt="Stivaletti"
				class="lazy"
				data-src="https://via.placeholder.com/220x280?text=S02E01"
				data-srcset="https://via.placeholder.com/440x560?text=S02E01 2x"
				width="220"
				height="280"
			/>
		</div>
		<div class="swiper-slide">
			<img
				alt="Stivaletti"
				class="lazy"
				data-src="https://via.placeholder.com/220x280?text=S02E02"
				data-srcset="https://via.placeholder.com/440x560?text=S02E02 2x"
				width="220"
				height="280"
			/>
		</div>
		<div class="swiper-slide">
			<img
				alt="Stivaletti"
				class="lazy"
				data-src="https://via.placeholder.com/220x280?text=S02E03"
				data-srcset="https://via.placeholder.com/440x560?text=S02E03 2x"
				width="220"
				height="280"
			/>
		</div>
		<div class="swiper-slide">
			<img
				alt="Stivaletti"
				class="lazy"
				data-src="https://via.placeholder.com/220x280?text=S02E04"
				data-srcset="https://via.placeholder.com/440x560?text=S02E04 2x"
				width="220"
				height="280"
			/>
		</div>
		<div class="swiper-slide">
			<img
				alt="Stivaletti"
				class="lazy"
				data-src="https://via.placeholder.com/220x280?text=S02E05"
				data-srcset="https://via.placeholder.com/440x560?text=S02E05 2x"
				width="220"
				height="280"
			/>
		</div>
	</div>
	<div class="swiper-button-prev"></div>
	<div class="swiper-button-next"></div>
</div>

Ecco il codice JavaScript che compie la magia.

const swiperOptions = {
	loop: true,
	slidesPerView: "auto",
	navigation: {
		nextEl: ".swiper-button-next",
		prevEl: ".swiper-button-prev",
	},
	on: {
		// Carica in modalità lazy le immagini di Swiper dopo l'inizializzazione di Swiper
		afterInit: (swiper) => {
			new LazyLoad({
				container: swiper.el,
				cancel_on_exit: false,
			});
		},
	},
};

// Inizializza subito il primo swiper
const eagerSwiper = new Swiper(".swiper--eager", swiperOptions);

// Inizializza tutti gli altri swiper non appena entrano nel viewport
new LazyLoad({
	elements_selector: ".swiper--lazy",
	unobserve_entered: true,
	callback_enter: function (swiperElement) {
		new Swiper("#" + swiperElement.id, swiperOptions);
	},
});

Ho testato questa soluzione emulando una connessione "3G lento", e ho apprezzato la cascata di chiamate di rete e il valore ottimale ottenuto per il Largest Contentful Paint.

Provalo live qui.

vanilla-lazyload vs lazysizes

2021-09-26T00:00:00Z

Come autore di vanilla-lazyload, non è la prima volta che mi viene posta questa domanda: Quali sono le differenze tra vanilla-lazyload e lazysizes? Questo post è la risposta a tale domanda.

Cosa sono vanilla-lazyload e lazysizes? #

vanilla-lazyload e lazysizes sono due popolari librerie JavaScript per il lazy-loading di immagini e altri elementi DOM, il che significa caricarli solo quando entrano nella porzione visibile della pagina web (il viewport del browser), o poco prima.

L'uso di una di esse è fondamentale per migliorare il tempo di rendering del tuo sito web, posticipando il caricamento di tutti i contenuti non critici a un momento successivo, al fine di ottenere migliori Core Web Vitals e in particolare di ridurre il Largest Contentful Paint.

Quali sono quindi le differenze tra vanilla-lazyload e lazysizes? Di seguito viene riportato un confronto dettagliato tra le due librerie.

Confronto tra vanilla-lazyload e lazysizes #

Trovi le caratteristiche principali di vanilla-lazyload a confronto con quelle di lazysizes nella tabella seguente.

Caratteristica	vanilla-lazyload	lazysizes
È leggera (fonte: bundlephobia)	✔ (2.8 kB)	✔ (3.4 kB)
È estendibile	✔ (via API)	✔ (via plugin)
È SEO friendly	✔	✔
Ottimizza le prestazioni annullando i download delle immagini già uscite dal viewport	✔
Riprova il caricamento se la connessione di rete cade e poi si ripristina	✔
Supporta l'uso condizionale del lazy loading nativo	✔
Funziona con il tuo DOM, le tue classi e i tuoi attributi data-*	✔
Può caricare in modalità lazy immagini responsive	✔	✔
...e calcolare automaticamente il valore dell'attributo sizes		✔
Può caricare in modalità lazy gli iframe	✔	✔
Può caricare in modalità lazy i video	✔
Può caricare in modalità lazy immagini di sfondo	✔
Può eseguire codice in modalità lazy quando determinati elementi entrano nel viewport	✔
Può ripristinare il DOM allo stato originale	✔

Spiegazione delle righe della tabella #

È estendibile #

Sia vanilla-lazyload sia lazysizes sono estendibili, vedi le API di vanilla-lazyload e i plugin di lazysizes.

È SEO friendly #

Entrambi gli script non nascondono le immagini o gli asset ai motori di ricerca, indipendentemente dal pattern di markup utilizzato. I motori di ricerca non scorrono né interagiscono con il tuo sito. Questi script rilevano se lo user agent è in grado di scorrere la pagina e, in caso contrario, mostrano istantaneamente tutte le immagini.

Ottimizza le prestazioni annullando i download delle immagini già uscite dal viewport #

Se i tuoi utenti mobili hanno connessioni lente e scorrono velocemente, vanilla-lazyload annulla il download delle immagini ancora in fase di caricamento ma che sono già uscite dal viewport. Se per qualche motivo preferisci evitare questo comportamento, questa funzione può essere disattivata.

Riprova il caricamento se la connessione di rete cade e poi si ripristina #

Se i tuoi utenti da mobile hanno connessioni instabili e passano offline per poi tornare online, vanilla-lazyload riprova a scaricare le immagini che avevano generato un errore.

Supporta l'uso condizionale del lazy-loading nativo #

Se i tuoi utenti utilizzano un browser che supporta il lazy-loading nativo e desideri utilizzarlo, con vanilla-lazyload puoi attivarlo in modo condizionale impostando l'opzione use_native a true. Trovi qui maggiori informazioni e la demo del lazy-loading nativo condizionale.

Funziona con il tuo DOM, le tue classi e i tuoi attributi data-* #

Entrambi gli script funzionano per impostazione predefinita con l'attributo data-src e la classe lazy nel tuo DOM. Tuttavia, in vanilla-lazyload puoi modificarli (ad esempio in data-origin), se desideri migrare da altri script di caricamento lazy a vanilla-lazyload senza dover cambiare il markup HTML.

Può caricare in modalità lazy le immagini responsive #

Sia vanilla-lazyload sia lazysizes possono caricare in modalità lazy immagini responsive di ogni tipo, dal semplice tag img al tag picture con tag source multipli.

Per ulteriori informazioni, consulta l'articolo Lazy loading delle immagini responsive nel 2020 scritto dal sottoscritto.

...e calcolare automaticamente il valore dell'attributo `sizes` #

Lo script lazysizes ha una funzione che può risparmiarti la "fatica" di scrivere il valore dell'attributo sizes nel tuo markup HTML. Inserendo data-sizes="auto" nel markup delle tue immagini, la libreria calcola il valore tramite JavaScript basandosi sul tuo CSS.

Questa funzionalità manca intenzionalmente in vanilla-lazyload. Per fare in modo che i browser visualizzino i contenuti del tuo sito il più velocemente possibile, dovrai combinare lazy loading ed eager loading (eager è il contrario di lazy). La best practice in questo caso consiste nel caricare immediatamente (eager) le immagini above-the-fold e in modalità lazy quelle below-the-fold. Nelle immagini caricate subito (eager), dovrai comunque impostare un valore corretto per l'attributo sizes. Ciò significa che dovrai calcolare quel valore in ogni caso e, una volta fatto, che senso ha calcolarlo di nuovo tramite JavaScript? Puoi utilizzare lo stesso valore calcolato sia per le immagini eager sia per quelle lazy.

Può caricare in modalità lazy gli iframe #

Sia vanilla-lazyload sia lazysizes possono caricare in modalità lazy il tag iframe.

Può caricare in modalità lazy i video #

Solo vanilla-lazyload può caricare in modalità lazy il tag video, anche con tag source multipli.

Vedi la sezione lazy video nella documentazione di vanilla-lazyload per maggiori dettagli.

Può caricare in modalità lazy le immagini di sfondo #

Solo vanilla-lazyload può caricare in modalità lazy le immagini di sfondo, comprese quelle multiple. Offre inoltre una modalità per supportare display HiDPI come Retina e Super Retina.

Vedi la sezione lazy background images nella documentazione di vanilla-lazyload per maggiori dettagli.

Può eseguire codice in modalità lazy quando determinati elementi entrano nel viewport #

Solo con vanilla-lazyload puoi eseguire del codice quando determinati elementi entrano nella parte visibile della pagina.

Vedi la sezione lazy functions nella documentazione di vanilla-lazyload per saperne di più.

Può ripristinare il DOM allo stato originale #

A volte è necessario ripulire il DOM prima di scaricarlo ed effettuare una navigazione fluida verso un'altra pagina, ad esempio quando si utilizza TurboLinks.

vanilla-lazyload ti consente di ripristinare tutto il DOM che ha manipolato al suo stato originale chiamando il metodo restoreAll().

Conclusione #

vanilla-lazyload offre più funzionalità per il lazy-loading di immagini, immagini di sfondo, video e iframe; è ottimizzato per connessioni lente, riprova automaticamente a caricare le immagini dopo una disconnessione di rete, supporta il lazy loading nativo condizionale, può eseguire codice in modalità lazy e ripristinare il DOM allo stato originale.

Dall'altro lato, lazysizes è estendibile e offre la possibilità di calcolare automaticamente l'attributo sizes delle immagini, se preferisci non farlo manualmente.

Link:

Case study su Quicklink: pagine più veloci, aumento delle visualizzazioni

2021-06-18T00:00:00Z

QuickLink è una libreria leggera creata da Addy Osmani (Google) che esegue il prefetch delle pagine collegate alla pagina corrente non appena i link a tali pagine entrano nella porzione visibile della pagina (viewport).

Abbiamo utilizzato Quicklink su alcuni dei nostri siti di e-commerce per migliorare i tempi di rendering delle pagine di dettaglio prodotto (PDP), ottenendo buoni risultati sia in termini di prestazioni sia per i KPI di business.

Continua a leggere su Medium

Un modo intelligente per servire immagini WebP ai browser moderni e JPG a Internet Explorer

2020-11-29T00:00:00Z

Prima che Safari iniziasse a supportare le immagini WebP, eravamo costretti a usare il tag picture per servire le immagini WebP ai browser che le supportavano. Oggi tutti i browser moderni supportano il formato WebP, quindi c'è probabilmente un modo intelligente per farlo usando un singolo tag: img.

Come facevamo prima #

Il vecchio metodo consisteva nell'utilizzare un tag picture contenente il normale tag img con gli attributi src e srcset per i browser che non supportavano il formato WebP, e un tag source fratello — contrassegnato con type="image/webp" — contenente lo srcset per i browser in grado di visualizzare il formato WebP.

In poche parole, questo:

<picture>
    <source
        type="image/webp"
        srcset="
            {url-standard}.webp 1x,
            {url-retina}.webp   2x
        "
    />
    <img
        alt="Vecchio metodo"
        src="{url-standard}.jpg"
        srcset="
            {url-standard}.jpg 1x,
            {url-retina}.jpg   2x
        "
    />
</picture>

Ma ora Safari è più moderno #

Ora che tutti i browser moderni supportano il formato WebP, possiamo presumere che tutti i browser che supportano l'attributo srcset supportino anche il WebP. Possiamo quindi eliminare il tag picture e utilizzare un singolo tag img.

In questo modo:

<img
    alt="Nuovo metodo intelligente"
    src="{url-standard}.jpg"
    srcset="
        {url-standard}.webp 1x,
        {url-retina}.webp   2x
    "
/>

I browser legacy utilizzeranno come fallback l'attributo src, scaricando l'immagine JPG. Semplice.

Vantaggi #

Il primo e più ovvio vantaggio è che è necessario scrivere e mantenere meno markup HTML.

Un secondo vantaggio si potrebbe avere se si stesse utilizzando una CDN per immagini per servire automaticamente il formato corretto in base al browser che lo richiede. In tal caso, probabilmente si può fare a meno di questo servizio, risparmiando tempo e denaro.

Compatibilità #

Se devi supportare versioni di iOS precedenti alla 14, probabilmente ti converrà continuare a utilizzare il tag picture per farlo. Questo dipende dal pubblico a cui ti rivolgi. Puoi scoprire di più sul tuo pubblico analizzando i dati di Google Analytics.

Come limitare la fedeltà delle immagini a 2x e risparmiare il 45% del peso sui telefoni cellulari di fascia alta

2020-11-11T00:00:00Z

Con la diffusione di schermi ad altissima densità “super retina” nei dispositivi di fascia alta più recenti, limitare la fedeltà delle immagini a 2x porta a un notevole miglioramento nei tempi di rendering, senza alcuna perdita di qualità percepibile per gli utenti. Ecco una nuova best practice su come fare.

Immagini e densità degli schermi #

Nel giugno 2010, Apple ha introdotto il primo display Retina sull'iPhone 4. "Retina" è solo un nome commerciale per descrivere uno schermo HiDPI, che ha il doppio dei pixel in orizzontale e in verticale (2x).

Gli schermi HiDPI sono perfetti per il rendering di vettori come font e immagini SVG, ma quando si tratta di immagini bitmap, se non forniamo un'immagine specifica per display HiDPI, la nostra immagine standard viene allungata (ingrandita) per coprire tutti i pixel aggiuntivi. E le immagini allungate non hanno un bell'aspetto.

Così, la prima cosa che abbiamo iniziato a fare è stata fornire sia un'immagine standard sia un'immagine ottimizzata per gli schermi Retina, utilizzando l'attributo srcset e il descrittore x. In questo modo:

<img
	src="batman_1x.jpg"
	srcset="batman_1x.jpg 1x, batman_2x.jpg 2x"
	alt="Batman, Super-man and Wonder Woman"
	width="1280"
	height="720"
/>

Quel descrittore x nell'attributo srcset serve ad associare le sorgenti alle densità dello schermo. 1x significa "questa è l'immagine per schermi normali", 2x significa "questa è l'immagine per display HiDPI / Retina". A seconda dello schermo del dispositivo, i browser sceglieranno la sorgente corrispondente.

Immagini responsive #

Quella delle immagini responsive è una specifica HTML che ci consente di servire la dimensione corretta dell'immagine agli utenti, a seconda dello spazio che l'immagine occupa sul loro schermo e tenendo conto del pixel ratio del dispositivo.

Il modo più semplice per scrivere il codice per le immagini responsive è elencare tutte le dimensioni d'immagine disponibili in un attributo srcset, utilizzando il descrittore w, e indicare al browser quanto è grande la nostra immagine tramite l'attributo sizes. I browser faranno i calcoli e scaricheranno l'immagine più appropriata.

<img
	src="batman_1280w.jpg"
	srcset="batman_1280w.jpg 1280w, batman_1024w.jpg 1024w, batman_768w.jpg 768w"
	alt="Batman, Super-man and Wonder Woman"
	sizes="100vw"
/>

Inoltre, se la dimensione delle immagini cambia a seconda delle media query, possiamo aggiungere le stesse media query nell'attributo sizes.

<img
	src="batman_1280w.jpg"
	srcset="
		batman_1440w.jpg 1440w,
		batman_1280w.jpg 1280w,
		batman_1024w.jpg 1024w,
		batman_768w.jpg   768w
	"
	alt="Batman, Super-man and Wonder Woman"
	sizes="(min-width: 640px) 50vw, 100vw"
/>

Se ti senti confuso, ti consiglio di leggere Srcset and Sizes di Eric Portis. Quell'articolo mi ha illuminato la strada quando ho iniziato a sperimentare con le immagini responsive.

Dispositivi con schermi 3x #

Al momento della scrittura di questo articolo, ci sono diversi dispositivi di fascia alta, sia di Apple che di Google, che montano uno schermo HiDPI con una densità di pixel pari a 3x o superiore. Apple li chiama display Super Retina, Google li chiama display FHD+.

Dispositivi con display super HiDPI

Apple ha lanciato il suo primo display Super Retina con l'iPhone X; lo stesso tipo di display è montato su iPhone XS / Max, iPhone 11 Pro / 11 Pro Max e su tutti i telefoni della linea iPhone 12, compreso il 12 Mini.

I telefoni Google Pixel hanno display FHD+ con densità di pixel 3x, e display QHD+ con una densità di 3.5x sul Pixel 4 XL.

Limitare la fedeltà delle immagini #

Secondo l'analisi effettuata su una modifica all'app mobile di Twitter, limitare la fedeltà dell'immagine a 2x porta a un notevole miglioramento dei tempi di rendering e a nessuna perdita di qualità percepibile dagli utenti.

Le immagini nelle timeline sui dispositivi a risoluzione ultra-elevata ora si caricano circa il 33% più velocemente consumando un terzo di dati in meno, e senza alcuna variazione visibile della qualità.

Il problema con la gestione delle immagini responsive tramite il tag img, come abbiamo visto sopra, è che non c'è modo di impedire ai browser di scaricare l'immagine 3x. Il motivo è che per determinar quale immagine scaricare dallo srcset, effettuano questo calcolo:

larghezza dell'immagine sullo schermo × densità di pixel del dispositivo = larghezza dell'immagine da scaricare

Ad esempio, se un'immagine deve essere visualizzata con una larghezza di 300px su un iPhone 12, i browser eseguiranno il seguente calcolo:

300 × 3 = 900

E scaricherebbero l'immagine larga 900 pixel. Quello che vogliamo fare noi è limitare la fedeltà a 2x in modo che scarichi invece l'immagine larga 600 pixel.

L'unico modo per farlo sul web è utilizzare il tag picture in questo modo:

<picture>
	<!-- Tablet in modalità landscape / computer -->
	<source
		media="(min-width: ####px)"
		srcset="batman_###w.jpg 1x, batman_###w.jpg 2x"
	/>
	<!-- Tablet in modalità portrait / smartphone in modalità landscape -->
	<source media="(min-width: ###px)" srcset="batman_###w.jpg 2x" />
	<!-- Smartphone più grandi -->
	<source media="(min-width: ###px)" srcset="batman_###w.jpg 2x" />
	<!-- Smartphone più piccoli -->
	<img
		src="batman_###w.jpg"
		srcset="batman_###w.jpg 2x"
		alt="Batman Super-man e Wonder"
	/>
</picture>

Nota: ho sostituito i numeri reali con un segnaposto ### perché quei valori non sono rilevanti per questa spiegazione.

Nota che:

nelle media query degli smartphone descriviamo solo l'immagine 2x, poiché oggi tutti gli smartphone montano un display retina
nelle media query per tablet in modalità landscape (orizzontale) e computer, dovremmo descrivere sia le immagini 1x sia quelle 2x.
l'attributo src sul tag img è obbligatorio, ma verrà utilizzato solo dai browser legacy, incluso IE 11

Ridurre opzionalmente la complessità sulle media query di tablet e computer #

Se il tuo layout richiede più di una media query per tablet e computer, dovresti considerare l'uso dell'attributo srcset con il descrittore w e l'attributo sizes, ottenendo questo:

<picture>
	<!-- Tablet in modalità landscape / computer -->
	<source
		media="(min-width: ###px) "
		sizes="(min-width: ###px) 33vw, 50vw"
		srcset="
            batman_####w.jpg ####w,
            batman_####w.jpg ####w,
            batman_###w.jpg   ###w
        "
	/>
	<!-- Tablet in modalità portrait / smartphone in modalità landscape -->
	<source media="(min-width: ###px)" srcset="batman_###w.jpg 2x" />
	<!-- Smartphone più grandi -->
	<source media="(min-width: ###px)" srcset="batman_###w.jpg 2x" />
	<!-- Smartphone più piccoli -->
	<img
		src="batman_###w.jpg"
		srcset="batman_###w.jpg 2x"
		alt="Batman Super-man e Wonder"
	/>
</picture>

In questo modo, a partire dalla media query per tablet landscape e computer, non avrai bisogno di aggiungere altri tag source, poiché non c'è necessità di limitare la qualità dell'immagine sui computer. Il tag source più in alto si occuperà di tutto.

“È un sacco di markup per una sola immagine”, dirai? #

Se utilizzi immagini responsive, probabilmente hai già tag img di dimensioni considerevoli, ognuno dei quali elenca un set di URL di immagini nell'attributo srcset e un set di media query e dimensioni nell'attributo sizes. Il codice mostrato sopra può essere leggermente più esteso, ma non in modo significativo.

Detto questo, strumenti come GZip e Brotli — che funzionano nativamente nella maggior parte dei server applicativi e delle CDN — svolgono un lavoro eccellente nel comprimere i caratteri ripetuti nel markup, e ci sono molti caratteri ripetuti in questi tag di immagine.

Ho fatto un test e ho scoperto che un file HTML contenente 54 immagini pesa 37 kb non compresso, ma solo 530 byte una volta compresso con GZip. Se si confronta questo dato con un risparmio del 45% sui dati per le immagini scaricate, si tratta sicuramente di un ottimo compromesso.

Risultato: immagini più leggere del 45% #

L'utilizzo di questa tecnica sulla pagina dell'elenco dei prodotti di uno dei siti che gestiamo ha portato a una riduzione del peso delle immagini del 45%. Il peso delle immagini su un iPhone 11 Pro era di 1.7 MB prima ed è di soli 949 kB dopo la limitazione.

Peso delle immagini prima (a sinistra) e dopo la limitazione (a destra)

Demo #

Ho creato una repository su GitHub e un Codepen. Sentiti libero di provarli e di farne un fork.

Singola immagine con fedeltà limitata a 2x:

O prova la pagina mostrata nel video sopra.

🌟 Apri la demo live 💻

Psst! Puoi ancora caricare le immagini in modalità lazy #

Una delle migliori pratiche per ridurre al minimo il Largest Contentful Paint (LCP) del tuo sito consiste nel caricare immediatamente (eager) le immagini above-the-fold e in modalità lazy quelle below-the-fold. Puoi farlo utilizzando data-src, data-srcset, data-sizes al posto di src, srcset, sizes sia nei tag img sia in quelli source.

<picture>
	<!-- Tablet in modalità landscape / computer -->
	<source
		media="(min-width: ###px) "
		data-sizes="(min-width: ###px) 33vw, 50vw"
		data-srcset="
            batman_####w.jpg ####w,
            batman_####w.jpg ####w,
            batman_###w.jpg   ###w
        "
	/>
	<!-- Tablet in modalità portrait / smartphone in modalità landscape -->
	<source media="(min-width: ###px)" data-srcset="batman_###w.jpg 2x" />
	<!-- Smartphone più grandi -->
	<source media="(min-width: ###px)" data-srcset="batman_###w.jpg 2x" />
	<!-- Smartphone più piccoli -->
	<img
		data-src="batman_###w.jpg"
		data-srcset="batman_###w.jpg 2x"
		alt="Batman Super-man e Wonder"
	/>
</picture>

Maggiori informazioni sul lazy loading delle immagini responsive nel 2020.

Per concludere #

Nel web design con immagini responsive, limitare la fedeltà delle immagini su dispositivi super HiDPI è una best practice relativamente nuova, dovuta al numero sempre crescente di smartphone dotati di schermi super HiDPI.

Limitare la fedeltà dell'immagine migliorerà la velocità di rendering del tuo sito, l'esperienza dei tuoi utenti e la metrica Largest Contentful Paint delle tue pagine.

Come ottimizzare il CLS quando si caricano altri contenuti in modo asincrono

2020-08-31T00:00:00Z

Il Cumulative Layout Shift (CLS) è un'importante metrica incentrata sull'utente per misurare la stabilità visiva, poiché aiuta a quantificare la frequenza con cui gli utenti riscontrano spostamenti imprevisti del layout — un CLS basso aiuta a garantire che l'esperienza sulla pagina sia piacevole.

Quello che forse non sai è che:

Il CLS viene misurato continuamente. Di fatto, il suo valore viene aggiornato anche mentre gli utenti scorrono la pagina, se lo scorrimento genera movimenti del layout
La misurazione del CLS viene sospesa per 500 ms ogni volta che si verifica un'interazione dell'utente, come un clic o un evento da tastiera

In parole povere, il Cumulative Layout Shift misura ogni movimento imprevisto del layout che si verifica mentre gli utenti interagiscono con la pagina, incluso quando scorrono verso il basso.

Quando carichiamo altri contenuti nelle nostre pagine, la causa più comune di CLS è il footer della pagina che diventa visibile per un momento, per poi essere spinto nuovamente below-the-fold dal nuovo contenuto aggiunto dinamicamente.

Quindi, come possiamo evitare che il CLS aumenti quando dobbiamo caricare dinamicamente nuovi contenuti, ad esempio per caricare un'intera nuova pagina di prodotti?

Continua a leggere su Medium

Lazy loading delle immagini responsive nel 2020

2020-05-24T00:00:00Z

Vuoi migliorare le prestazioni del tuo sito web? Puoi farlo usando le immagini responsive e il lazy loading! In questo articolo troverai il codice HTML, JavaScript e CSS per il lazy-loading delle immagini responsive, per fare in modo che i browser utilizzino formati di immagine moderni come WebP e Jpeg2000, e per abilitare il lazy-loading nativo dove supportato.

Definizioni #

Le immagini responsive sono tag img che scaricano la sorgente d'immagine corretta a seconda del design e del dispositivo dell'utente. Puoi fornire informazioni sul layout nell'attributo sizes e un elenco di sorgenti d'immagine nell'attributo srcset. Puoi anche utilizzare le media query racchiudendo il tag img in un tag picture. Maggiori informazioni sulle immagini responsive su MDN.

Il lazy-loading delle immagini è una tecnica che velocizza il rendering del tuo sito web posticipando il caricamento delle immagini below-the-fold a quando entrano nel viewport. Oltre alle prestazioni, questo ti consente anche di risparmiare larghezza di banda e denaro, ad esempio se paghi un servizio CDN per le tue immagini.

Prima l'above-the-fold #

Tieni a mente che l'uso di uno script per il lazy-loading delle immagini è un'attività basata su JavaScript ed è sensibilmente più lento rispetto al normale caricamento delle immagini (d'ora in poi chiamato eager loading), che inizia non appena viene analizzato il documento HTML.

☝️ Per questo motivo, la best practice consiste nel caricare immediatamente (eager) le immagini above-the-fold e caricare in modalità lazy solo le immagini below-the-fold.

A questo punto, di solito ci si chiede:

💬 Il mio sito è responsive, come faccio a sapere quante immagini saranno above-the-fold al caricamento della pagina?

La risposta è: contale! Apri la pagina web in un browser, ridimensiona il viewport alle dimensioni più comuni (smartphone, computer e tablet) magari utilizzando lo strumento di emulazione dei dispositivi, e contale.

Se vedi 4 immagini above-the-fold su uno smartphone e solo la parte superiore di altre 4 su desktop, sii prudente e carica immediatamente (eager) solo le prime 4.

E ora un po' di codice! #

Ecco il markup HTML di un'immagine responsive caricata immediatamente (eager).

<!-- Caricata immediatamente (eager),
     solo above-the-fold -->
<img
  alt="Eager above"
  src="220x280.jpg"
  srcset="
    220x280.jpg 220w,
    440x560.jpg 440w
  "
  sizes="220px"
/>

Ed ecco il markup per caricare un'immagine responsive in modalità lazy.

<!-- Caricata in modalità lazy,
     solo below-the-fold -->
<img
  alt="Lazy below"
  class="lazy"
  data-src="220x280.jpg"
  data-srcset="220x280.jpg 220w,
    440x560.jpg 440w"
  data-sizes="220px"
/>

Vuoi mostrare un'anteprima a bassa risoluzione mentre le immagini lazy si stanno caricando? Puoi farlo inserendo una piccola immagine di bassa qualità nel tag src, come nell'esempio seguente.

<!-- Caricata in modalità lazy,
     + anteprima a bassa risoluzione,
     solo below-the-fold -->
<img
  alt="Lazy below con anteprima"
  class="lazy"
  src="11x14.jpg"
  data-src="220x280.jpg"
  data-srcset="220x280.jpg 220w,
    440x560.jpg 440w"
  data-sizes="220px"
/>

Apri la demo 👀, quindi apri gli strumenti per sviluppatori del browser e vai alla scheda Rete (Network). Vedrai che le prime 2 immagini vengono caricate immediatamente (eager) appena la pagina si apre, mentre le restanti vengono caricate in modalità lazy man mano che scorri verso il basso.

Stiamo usando il tag HTML img e non il tag picture, poiché quest'ultimo non è necessario in questo caso. Approfondirò i casi d'uso del tag picture più avanti in questo articolo. ⏩ Vai direttamente ai casi d'uso del tag picture

Inclusione dello script #

Per caricare le immagini lazy quando entrano nel viewport, hai bisogno di uno script di lazy-loading come vanilla-lazyload, uno script leggero (2.5 kb gzipped), velocissimo, configurabile e ottimizzato per la SEO che ho creato e continuo a migliorare costantemente dal 2014.

Ecco il modo più semplice per includerlo nella tua pagina.

<script src="https://cdn.jsdelivr.net/npm/vanilla-lazyload@18.0.0/dist/lazyload.min.js"></script>

Dai un'occhiata alla documentazione per scoprire altri modi per includere LazyLoad nelle tue pagine web, come l'utilizzo di uno script async con auto-inizializzazione, l'uso di RequireJS, WebPack o Rollup.

Inizializzazione di LazyLoad #

L'inclusione dello script vanilla-lazyload ti fornisce la classe JS LazyLoad che puoi usare per caricare le immagini identificate dalla classe CSS lazy. Devi creare un'istanza di LazyLoad in questo modo:

var lazyLoad = new LazyLoad({
  // Le tue impostazioni personalizzate vanno qui
});

Minimizzare il reflow del layout #

Quando usi il lazy loading, le immagini che non hanno ancora iniziato a caricarsi collassano a un'altezza pari a 0, per poi espandersi una volta avviato il caricamento. Questo reflow del layout renderebbe il tuo sito scattoso (janky), quindi è una best practice stabilizzare il layout occupando lo spazio esatto che le immagini occuperanno una volta caricate, prima ancora che inizi il caricamento.

La soluzione universale per farlo è utilizzare il trucco del padding verticale (padding hack), mentre in futuro sarà possibile utilizzare la proprietà CSS aspect-ratio (al momento della scrittura, è disponibile solo su Chrome Canary).

.image-wrapper {
  width: 100%;
  height: 0;
  padding-bottom: 150%;
  /* ☝️ altezza immagine / larghezza immagine * 100% */
  position: relative;
}
.image {
  position: absolute;
  top: 0;
  left: 0;
  right: 0;
  bottom: 0;
}

Ecco anche un utile mixin SASS per farlo (fonte: CSS-Tricks).

@mixin aspect-ratio($width, $height) {
  position: relative;
  &:before {
    display: block;
    content: "";
    width: 100%;
    padding-top: ($height / $width) * 100%;
  }
  > .content {
    position: absolute;
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;
  }
}

Maggiori informazioni in Sizing Fluid Image Containers with a Little CSS Padding Hack di Andy Shora.

Evitare l'effetto immagini "rotte" #

Per evitare che le immagini lazy appaiano come rotte, anche solo per un breve istante, usa il CSS. Nascondi le immagini che non hanno ancora impostato né l'attributo src né srcset.

img:not([src]):not([srcset]) {
  visibility: hidden;
}

Nessun polyfill richiesto #

Potresti essere tentato di aggiungere uno o più polyfill per supportare Internet Explorer (sì, l'ho nominato ed è il 2020). Non farlo, non ne hai bisogno. Ti spiego perché:

Immagini responsive: Internet Explorer non supporta le immagini responsive, mas non serve un polyfill poiché IE si adatta (degrada) elegantemente mostrando l'immagine specificata nell'attributo src. Ti basterà quindi scegliere un'immagine adatta a uno schermo desktop standard, inserirla nell'attributo src e sei a posto.
IntersectionObserver: Internet Explorer non supporta l'API IntersectionObserver, che viene utilizzata da vanilla-lazyload, ma non è necessario fornire un polyfill poiché vanilla-lazyload rileverà il supporto per quell'API e, in caso di mancanza, caricherà immediatamente tutte le immagini. Questo produce lo stesso risultato che si otterrebbe senza usare LazyLoad sulla pagina, ma senza generare errori.

Il che è ottimo, visto che Internet Explorer oggi non è usato da più del 5% degli utenti, e Microsoft lo sta silenziosamente sostituendo con Edge tramite Windows Update.

In ogni caso, se per qualche motivo vuoi che funzioni esattamente allo stesso modo su Internet Explorer, puoi includere il polyfill di IntersectionObserver prima di vanilla-lazyload.

<!-- Non farlo se non sei sicuro! Leggi sopra -->
<script src="https://cdn.jsdelivr.net/npm/intersection-observer@0.10.0/intersection-observer.js"></script>
<script src="https://cdn.jsdelivr.net/npm/vanilla-lazyload@18.0.0/dist/lazyload.min.js"></script>

Mettiamo tutto insieme #

Per tua comodità, ecco tutto il codice HTML, JS e CSS riunito.

<!-- Caricata immediatamente (eager),
     solo above-the-fold -->
<img
  alt="Eager above"
  src="220x280.jpg"
  srcset="
    220x280.jpg 220w,
    440x560.jpg 440w
  "
  sizes="220px"
/>

<!-- Caricata in modalità lazy,
     solo below-the-fold -->
<img
  alt="Lazy below"
  class="lazy"
  data-src="220x280.jpg"
  data-srcset="220x280.jpg 220w,
    440x560.jpg 440w"
  data-sizes="220px"
/>

var lazyLoad = new LazyLoad({
  elements_selector: ".lazy",
  cancel_on_exit: true
});

/*
Contenitore delle immagini per occupare spazio
quando le immagini non sono ancora caricate
*/
.image-wrapper {
  width: 100%;
  height: 0;
  padding-bottom: 150%;
  /* ☝️ altezza immagine / larghezza immagine * 100% */
  position: relative;
}
.image {
  position: absolute;
  /* ...altre regole di posizionamento */
}

/*
Nascondi le immagini "rotte" prima
che inizino a caricare
*/
img:not([src]):not([srcset]) {
  visibility: hidden;
}

E questo è tutto per quanto riguarda il semplice tag img.

Casi d'uso del tag picture #

Fino ad ora ho parlato del tag img con gli attributi srcset e sizes, che rappresenta la soluzione per la stragrande maggioranza delle immagini responsive che potresti dover usare in un sito o in un'applicazione web. Ora, in quali casi dovresti invece usare il tag picture?

Rapporto larghezza/altezza differente (Art Direction) #

Caso d'uso: devi mostrare immagini con un rapporto larghezza/altezza differente a seconda di una media query. Ad esempio, vuoi mostrare immagini verticali (portrait) su dispositivi mobili e verticali, e immagini orizzontali (landscape) su viewport più ampi come tablet e computer.

Ecco il codice di cui avrai bisogno in questo caso. Per caricare le immagini immediatamente (eager), usa semplicemente gli attributi standard src e srcset, senza il prefisso data-.

<picture>
  <source
    media="(min-width: 1024px)"
    data-srcset="1024x576.jpg 1x,
      2048x1152.jpg 2x"
  />
  <source
    media="(max-width: 1023px)"
    data-srcset="640x960.jpg 1x,
      1280x1920.jpg 2x"
  />
  <img
    class="lazy"
    alt="Ritratto o panorama"
    data-src="1024x576.jpg"
  />
</picture>

Apri la demo 👀, quindi apri gli strumenti per sviluppatori del browser e vai alla scheda Rete (Network). Vedrai che viene scaricata solo la sorgente d'immagine corrispondente alla prima media query soddisfatta.

Caricare formati moderni come WebP e Jpeg2000 #

Caso d'uso: vuoi che sia il browser a scegliere la sorgente per caricare un formato moderno come WebP o Jpeg2000 in base al supporto per quel determinato formato.

Avrai bisogno del tag source e dell'attributo type che contiene il MIME type delle immagini nell'attributo data-/srcset.

<picture>
  <source
    type="image/jp2"
    data-srcset="1024x576.jp2 1x,
      2048x1152.jp2 2x"
  />
  <source
    type="image/webp"
    data-srcset="1024x576.webp 1x,
      2048x1152.webp 2x"
  />
  <img
    data-src="1024x576.jpg"
    data-srcset="1024x576.jpg 1x,
      2048x1152.jpg 2x"
    data-sizes="1024px"
    alt="Jp2, WebP o Jpg"
    class="lazy"
  />
</picture>

Apri la demo 👀, apri gli strumenti per sviluppatori del browser e vai alla scheda Rete (Network). Vedrai che scaricherà solo la sorgente dell'immagine corrispondente al primo formato supportato dal tuo browser.

💬 Questo markup non è un po' troppo lungo per una singola immagine?

Sì, lo è. E se hai budget da investire nell'ottimizzazione delle immagini, ci sono altri modi per farlo. La maggior parte dei server di immagini basati su cloud presenti sul mercato serve automaticamente diversi formati di immagine allo stesso URL. Ciò significa che puoi richiedere 1024x576.jpg e ottenere un file WebP o Jpeg2000 di conseguenza. Cloudinary e Akamai Image & Video Manager fanno proprio questo, tra gli altri.

Limitare la fedeltà delle immagini a 2x #

Con la diffusione di schermi ad altissima densità "super retina" nei dispositivi di fascia alta più recenti (come le serie iPhone 12 o Google Pixel), limitare la fedeltà dell'immagine a 2x porta a un notevole miglioramento nei tempi di download, senza alcuna perdita di qualità percepibile per gli utenti.

👉 Ecco una nuova best practice su come fare.

Lazy loading nativo #

Forse avrai sentito o letto dell'arrivo del lazy-loading nativo sul web. Fantastico, vero? A partire da maggio 2020, è supportato da Chrome, Firefox, Edge, Opera e, dietro un flag, da Safari.

Quindi il supporto al 100% dei browser non è ancora arrivato, ma nel caso in cui tu voglia abilitarlo sui browser supportati, puoi optare per il lazy loading ibrido impostando l'opzione use_native di vanilla-lazyload su true.

new LazyLoad({
  use_native: true
});

Funzionalità a cui potresti dover rinunciare #

Se opti per il lazy-loading nativo o quello ibrido, potresti perdere alcune funzionalità offerte dal lazy-loading gestito da JavaScript:

applicazione automatica delle classi in base agli eventi (loading, loaded, ecc.)
riprovo automatico del caricamento delle immagini in caso di errore di rete non appena si torna online
cancellazione del download quando le immagini escono dal viewport mentre si stanno ancora caricando, in modo da dare priorità a quelle nuove
callback sugli eventi attivati (ingresso/uscita dal viewport, caricamento iniziato/finito, ecc.)

Rifletti attentamente prima di passare al lazy-loading nativo. Se la mancanza di queste funzioni non rappresenta un problema per te, allora puoi procedere tranquillamente.

Conclusioni #

Ecco un riassunto:

Usa vanilla-lazyload per gestire il caricamento delle tue immagini.
Non caricare tutte le immagini in modalità lazy, ma solo quelle below-the-fold
Usa il tag img per le immagini responsive semplici
Usa il tag picture per:
- modificare il rapporto larghezza/altezza delle immagini a specifiche media query
- servire in modo condizionale le immagini in formati moderni come WebP o Jpeg2000
Non utilizzare alcun polyfill se non è strettamente necessario

Buon lazy loading!

Riguardo questo articolo #

Se qualcosa non è chiaro o ritieni possa essere migliorato, fammelo sapere nei commenti o scrivimi su Twitter.

☕ Se hai trovato utile questo articolo, puoi esprimere la tua gratitudine offrendomi un caffè. ☕

Risorse utili #

Responsive images in practice @ A List Apart
Responsive images @ Mozilla Developer Network
Responsive images in CSS @ CSS Tricks
Sito del Responsive Images Community Group

Come usare in modo produttivo il nuovo browser Microsoft Edge basato su Chromium

2020-01-16T00:00:00Z

Ecco una guida pratica su come usare in modo produttivo il nuovo browser Microsoft Edge basato su Chromium: scaricarlo, cambiare il motore di ricerca predefinito, installare estensioni e altro ancora.

Indice #

Scaricare Microsoft Edge
Modificare il motore di ricerca predefinito
Installare estensioni dal Chrome Web Store
Impostare il tema scuro
Configurare uno o più profili
Diventare un insider

Download per qualsiasi piattaforma #

Non importa se utilizzi Windows 10, 8, 7 o macOS, puoi scaricare Microsoft Edge per il tuo computer.

Modificare il motore di ricerca predefinito #

Dopo averlo installato, la prima cosa che vorrai fare è cambiare il tuo motore di ricerca predefinito impostando Google o DuckDuckGo (a meno che tu non preferisca davvero Bing). Puoi farlo dal pannello delle Impostazioni, nella scheda Privacy e servizi.

Clicca sul pulsante ...
Seleziona "Impostazioni"
Seleziona "Privacy e servizi" nel menu a sinistra
(scorri fino in fondo)
Clicca su "Barra degli indirizzi"
Seleziona il tuo motore di ricerca preferito dal menu a discesa "Motore di ricerca utilizzato nella barra degli indirizzi"

Buon utilizzo!

Installare estensioni #

Microsoft Edge ha il suo marketplace per le estensioni, ma su Microsoft Edge puoi anche installare estensioni dal Chrome Web Store.

Quando visiti il Chrome Web Store, Edge mostra una barra blu in alto che ti informa che puoi installare estensioni da lì. Fai semplicemente clic sul pulsante "Consenti estensioni da altri store" e sei pronto a partire.

Come impostare il tema scuro #

Se come me ami i temi scuri per gli strumenti di sviluppo, puoi attivare il tema scuro dal pannello Impostazioni, nella scheda Aspetto.

Clicca sul pulsante ...
Seleziona "Impostazioni"
Seleziona "Aspetto"
Seleziona "Scuro" dal menu a discesa "Tema"

C'è dell'altro? I profili #

Se sei un utente Chrome, al tuo primo utilizzo di Microsoft Edge tutto verrà magicamente migrato da Chrome a Edge. Almeno, questo è quello che è successo a me quando ho iniziato a usare Edge Dev qualche mese fa.

Potrebbe interessarti creare uno o più profili e configurare le opzioni di sincronizzazione, in modo che quando usi Edge sugli altri tuoi dispositivi (PC, altri PC, Mac, ecc.) troverai le tue password, i dati di compilazione automatica e la cronologia di navigazione a portata di mano.

Diventa un insider #

Puoi anche diventare un insider e utilizzare le versioni preliminari di Microsoft Edge. Ci sono 3 canali: Beta, Dev e Canary.

Canary è aggiornato più frequentemente (ogni giorno) ma è anche il più instabile
Beta è aggiornato meno frequentemente (ogni 6 settimane) ed è quindi il più stabile
Dev è aggiornato settimanalmente ed è quindi più stabile di Canary, ma meno stabile di Beta.

Scarica una qualsiasi di queste versioni nella pagina dei canali Microsoft Edge Insider.

Personalmente ho utilizzato Microsoft Edge Dev come browser principale per mesi, sia su Mac che su Windows, sia per svago che per sviluppo, con un altissimo livello di soddisfazione. Sfortunatamente, le ultime versioni Dev e Canary hanno smesso di funzionare su una delle mie macchine a partire dal 9 gennaio, ma l'ho già segnalato a Microsoft e mi aspetto una soluzione a breve.

È la fine di Internet Explorer? #

Ci sono ancora aziende che utilizzano Internet Explorer per motivi di compatibilità (vecchi strumenti web o siti intranet). Questa versione di Edge dispone di una "modalità Internet Explorer", in modo che queste aziende possano finalmente impostare Microsoft Edge come browser predefinito per i propri lavoratori, che potranno così navigare sul web utilizzando un browser moderno senza compromettere il funzionamento dei loro vecchi strumenti.

Aiuta il web #

Se conosci aziende che utilizzano ancora Internet Explorer per motivi di compatibilità, dovresti parlargliene.

E se sei uno sviluppatore web come me, dovresti assolutamente provare Microsoft Edge sia per testare sia per sviluppare i tuoi siti web.

➡ Scarica Microsoft Edge (stabile)

Buon divertimento!

Critical CSS con Jekyll e SASS

2019-06-17T00:00:00Z

In passato il mio blog era gestito da Jekyll su GitHub Pages e il suo CSS era compilato usando SASS. Oggi ho deciso di migliorare ulteriormente le prestazioni integrando inline il critical CSS che blocca il rendering, ma anche cercando su internet ho faticato a trovare un modo semplice per farlo. Questo post fa al caso tuo, se vuoi fare la stessa cosa.

Lo stile critical #

Nel file SASS per il critical CSS, usa la direttiva SASS @import per includere tutti i partial che hanno un impatto sul layout della tua pagina. Includi anche le tue variabili (variables) e mixin che potrebbero essere richiesti dai partial importati.

Ad esempio, io sto importando:

il partial base, che contiene le regole di base del sito come il CSS reset e le regole tipografiche,
il partial layout, che definisce lo stile dell'header e del layout della pagina,
il partial posts_above, che definisce lo stile della parte above-the-fold dell'elenco dei post e del dettaglio del post,
il partial utils, che contiene alcune classi di utilità (ad es. visuallyHidden).

Il partial posts_above inizialmente era un unico file chiamato posts, ma ho deciso di dividerlo in due file separati per ottimizzare ancora di più. L'altro partial, chiamato posts_below, contiene le informazioni di stile per il footer del post (la sezione dell'autore, il pulsante di condivisione), quindi non è incluso qui.

→ Crea un file critical.scss all'interno della cartella includes.

File includes/critical.scss:

// Importa i partial per il contenuto del critical css
@import "variables", "mixins", "base",
  "layout", "posts_above", "pages",
  "utils";

IMPORTANTE: Posiziona questo file nella cartella includes! Più tardi dovrai includerlo nel tuo HTML.

Inseriscilo nella sezione `head` #

Inserisci il critical CSS inline all'interno di un tag style nella sezione <head> del tuo HTML. Puoi farlo usando il seguente codice Jekyll, basato sul motore di template Liquid utilizzato in Jekyll.

→ Apri il tuo partial head.html, se ne hai uno.

File includes/head.html:

{% capture critical %}
  {% include minima_critical.scss %}
{% endcapture %}

{{ critical | scssify }}

Il resto del tuo foglio di stile #

Se il tuo sito è abbastanza semplice, puoi importare il resto dei tuoi partial all'interno di un singolo file SCSS, che caricherai in modo asincrono usando JavaScript.

Io, ad esempio, ho importato lì tutti i partial SASS che definiscono lo stile delle sezioni della pagina che probabilmente appariranno below-the-fold:

lo stile di evidenziazione della sintassi (syntax highlighting),
lo stile del footer,
lo stile della paginazione,
lo stile delle icone SVG,
lo stile degli iframe e delle tabelle

→ Inserisci il resto delle tue regole SASS all'interno del tuo normale file CSS.

File assets/main.scss:

---
---

// Importa i partial per il contenuto below-the-fold
@import "variables", "mixins",
  "posts_below", "syntax-highlighting",
  "footer", "code", "pagination",
  "icons", "iframes", "tables";

IMPORTANTE: Le due righe con tre trattini all'inizio del file sono richieste da Jekyll per riconoscere ed elaborare il file come contenuto.

Carica il resto del foglio di stile #

Ci sono molti modi per caricare il resto del tuo CSS usando JavaScript, ma ho deciso di usare la tecnica asincrona moderna che fa sì che un file CSS venga caricato con bassa priorità, per poi applicarlo alla pagina una volta caricato.

File head.html:

<link
  rel="stylesheet"
  href="{{ '/assets/main.css' | relative_url }}"
  media="nope!"
  onload="this.media='all'"
/>

Funziona!

Conclusione #

Integrare inline la parte critica del tuo CSS fa sì che le tue pagine vengano visualizzate più velocemente, poiché il CSS si trova nel percorso di rendering critico (critical rendering path) del browser.

Fai una prova! Se hai commenti, fammi sapere nella sezione commenti qui sotto!

Web Share API, il passo successivo alla PWA

2019-06-14T00:00:00Z

Oggi ho sperimentato con la Web Share API e l'ho implementata su questo sito, tanto per iniziare. Ecco cosa ho fatto e come puoi implementarla sul tuo sito.

Dopo aver trasformato questo sito in una Progressive Web Application, ho rimosso lo script AddThis che veniva utilizzato per aggiungere i pulsanti di condivisione alla fine di ogni post, perché rallentava il sito. Mi sono poi reso conto che, dopo aver aggiunto il sito alla schermata iniziale del telefono come app standalone, gli utenti non potevano più condividere i post.

Ho aggiunto il seguente script alle pagine dei post del mio sito:

(function() {
  // Rileva il supporto per la funzionalità di condivisione web
  var supportsShare = "share" in navigator;

  // Nessun supporto?
  // - Aggiunge una classe "noShare" al documento
  // - Non fa nient'altro
  if (!supportsShare) {
    document.documentElement.classList.add("noShare");
    return;
  }

  // Supportato? Recupera:
  // - il pulsante di condivisione (elemento DOM)
  // - il canonicalUrl della pagina
  // - il titolo della pagina
  var shareButton = document.querySelector(".post-share");
  var canonicalUrl = document
    .querySelector("link[rel=canonical]")
    .getAttribute("href");
  var title = document.querySelector("title").innerText;

  // Aggiunge un listener al pulsante di condivisione
  shareButton.addEventListener("click", function(event) {
    // Chiama navigator.share con il titolo e l'URL canonico
    navigator
      .share({
        title: title,
        url: canonicalUrl
      })
      .then(() => {
        // Fai quello che vuoi qui
        console.log("Grazie per la condivisione!");
      })
      .catch(e => {
        // Gestisci gli errori qui
        console.error(e, "Condivisione fallita")
      });
  });
})();

Poi, per nascondere i pulsanti di condivisione tramite CSS quando la classe noShare viene aggiunta al documento:

.noShare .post-share {
  display: none;
}

Facile, no?

Il supporto per la Web Share API è ancora limitato, ma per lo meno è supportato da Safari e Chrome per Android, quindi aiuterà chiunque abbia installato la tua PWA sulla schermata iniziale del proprio smartphone.

Trasformare il mio blog in una Progressive Web Application

2019-06-10T00:00:00Z

Alcuni colleghi ed io abbiamo partecipato a un Hackathon di Google sulle Progressive Web Application e abbiamo imparato molto, così ho deciso di abilitare questo sito web come PWA. Ecco cosa ho fatto...

Per rendere un'app installabile, è necessario aggiungere un manifest al sito web. Ecco il manifest di questo sito.

{
    "name": "Andrea Verlicchi’s Blog",
    "short_name": "AV's Blog",
    "icons": [
        {
            "src": "/android-chrome-192x192.png?v=wAXeG66EQW",
            "sizes": "192x192",
            "type": "image/png"
        },
        {
            "src": "/android-chrome-512x512.png?v=wAXeG66EQW",
            "sizes": "512x512",
            "type": "image/png"
        }
    ],
    "theme_color": "#D90009",
    "background_color": "#977f34",
    "display": "standalone",
    "start_url": "/"
}

Se vuoi abilitare il tuo sito web come PWA, ti consiglio di iniziare leggendo la guida Workbox Getting Started.

Il file del Service Worker #

Utilizzo Workbox per abilitare i Service Worker e gestire le strategie di cache, ecc.

importScripts('https://storage.googleapis.com/workbox-cdn/releases/4.3.1/workbox-sw.js');

/*
 * REGOLE DI ROUTING
 */

// Caching di tutti i file JS con la strategia Stale While Revalidate
workbox.routing.registerRoute(
  /\.js$/,
  new workbox.strategies.StaleWhileRevalidate({
    cacheName: "js-cache",
  })
);

// Caching di tutti i file CSS con la strategia Stale While Revalidate
workbox.routing.registerRoute(
  /\.css$/,
  new workbox.strategies.StaleWhileRevalidate({
    cacheName: 'css-cache',
  })
);

// Caching di tutti i file immagine con la strategia Cache First
workbox.routing.registerRoute(
  /\.(?:png|jpg|jpeg|svg)$/,
  new workbox.strategies.CacheFirst({
    cacheName: 'image-cache',
    plugins: [
      new workbox.expiration.Plugin({
        maxEntries: 20,
        maxAgeSeconds: 7 * 24 * 60 * 60,
      })
    ],
  })
);

// Caching dell'HTML di tutti i post con la strategia Network First
workbox.routing.registerRoute(
  /\/[^\/]+\/$/,
  new workbox.strategies.NetworkFirst({
    cacheName: 'posts-cache',
    plugins: [
      new workbox.expiration.Plugin({
        maxEntries: 20
      })
    ],
  })
);

Ho temporaneamente disabilitato il precaching delle altre pagine perché ho scoperto che queste informazioni vengono poi aggiunte alla strategia di routing con la strategia Cache First, il che non è ideale per fare in modo che il sito recuperi sempre informazioni aggiornate.

/*
 * PRECACHING
 */

// DISATTIVATO PERCHÉ QUESTE RISORSE SAREBBERO SOLO CACHE-FIRST!
/*workbox.precaching.precacheAndRoute([
  { url: '/', revision: '20190607' },
  { url: '/about/', revision: '20190607' },
  { url: '/contact/', revision: '20190607' }
]);*/

Ma sto studiando e approfondendo come gestire questa cosa.

Risultati #

Il risultato è che questo sito web ora è:

Installabile
Accessibile offline
Moderno :)

Se hai suggerimenti o commenti, per favore contattami e fammi sapere!

Un fantastico articolo sul lazy loading ibrido

2019-05-16T00:00:00Z

Il 6 maggio 2019 ho scritto il mio primo articolo su Smashing Magazine: Lazy Loading Ibrido: Una Migrazione Progressiva Al Lazy Loading Nativo.

Uno screenshot dell'articolo su Smashing Magazine

Il lazy loading nativo sta arrivando sul web. Poiché non dipende da JavaScript, rivoluzionerà il modo in cui oggi carichiamo i contenuti in modalità lazy, rendendo più semplice per gli sviluppatori gestire immagini e iframe. Ma non è una funzionalità che possiamo polyfillare, e ci vorrà del tempo prima che diventi utilizzabile su tutti i browser. In questo articolo imparerai come funziona e come puoi sostituire progressivamente il tuo lazy loading basato su JavaScript con la sua alternativa nativa, grazie al lazy loading ibrido.

Nelle ultime settimane, potresti aver sentito o letto parlare del lazy loading nativo, in arrivo su Chromium 75 nei prossimi mesi.

“Sì, ottima notizia, ma dovremo aspettare che tutti i browser lo supportino.”

Se questo è stato il primo pensiero che ti è passato per la testa, continua a leggere. Cercherò di convincerti del contrario.

Iniziamo con un confronto tra il lazy loading nativo e il caro vecchio caricamento gestito da JavaScript.

→ Leggi l'articolo completo

Lazy loading nativo e fallback js con vanilla-lazyload 12

2019-04-11T00:00:00Z

Il 6 aprile 2019, Addy Osmani ha scritto sul lazy-loading nativo delle immagini. Due giorni dopo Yvain, uno sviluppatore front-end di Parigi, mi ha chiesto se il mio vanilla-lazyload potesse fungere da polyfill per l'attributo loading, ispirandomi a sviluppare e rilasciare la versione 12 dello script, che introduce la nuova opzione use_native per abilitare il lazy-loading nativo dove supportato. Puoi già usarlo oggi stesso.

Aspetta... cosa? #

Nel caso ti fossi perso l'articolo di Addy Osmani, sarà possibile caricare le immagini e gli iframe in modalità lazy nativamente tramite l'attributo loading="lazy", ed è già possibile farlo su Chrome 75 (attualmente Canary).

<img loading="lazy" src="..." />
<iframe
  loading="lazy"
  src="..."
></iframe>

I browser scaricheranno inizialmente una piccolissima parte delle immagini (~2kb) per ottenere alcune informazioni iniziali (ad es. le dimensioni), per poi scaricare il resto quando stanno per entrare nel viewport.

Il problema è che se assegni direttamente il src (e/o srcset) alle immagini, i browser che non supportano ancora il lazy loading nativo le scaricheranno tutte immediatamente, e questo è qualcosa che potresti voler evitare per risparmiare larghezza di banda e velocizzare il tuo sito o applicazione web.

Per questo motivo, ho aggiunto l'opzione use_native nella versione 12 di vanilla-lazyload, che abilita il lazy-loading nativo dove supportato.

Maggiori informazioni sul lazy loading nativo possono essere trovate nel post di Addy Osmani native image lazy-loading.

Il browser necessario #

A partire dal 10 aprile 2019, il lazy loading nativo è nelle prime fasi (developer preview) ed è disponibile solo in Chrome 75 (attualmente Canary), e dietro un flag. Quindi per testarlo, devi:

Scarica Chrome Canary e installalo
In Chrome Canary, vai all'URL chrome://flags e abilita i seguenti flag:
- Enable lazy image loading
- Enable lazy iframe loading
Riavvia Chrome Canary

Demo #

Ora che hai il browser Chrome Canary con il lazy loading nativo abilitato, puoi iniziare visitando la seguente pagina demo.

→ Apri la demo e/o Controlla il codice

Se hai fatto tutto correttamente, ecco cosa succederà:

Su Chrome 75 (Canary), LazyLoad attiverà il lazy-loading nativo
Su altri browser e versioni precedenti di Chrome, verrà eseguito il lazy loading basato su JavaScript

Provalo sul tuo sito! #

Per provarlo tu stesso, devi seguire questi passaggi.

Markup #

Per assicurarti che i tuoi utenti vedano le tue immagini il prima possibile, ti consiglio di caricare immediatamente le immagini in cima alla tua pagina web, solo quelle che sai che saranno posizionate above-the-fold nei viewport più comuni, considerando smartphone, tablet e computer.

Per farlo, le prime immagini nella pagina dovrebbero essere caricate usando normali tag <img>. Puoi usare l'attributo loading="eager" per assicurarti che vengano caricate il prima possibile.

<img
  src="eager-eagle.jpg"
  loading="eager"
  alt="Eager Eagle"
/>

Tutte le altre immagini below-the-fold dovrebbero invece essere caricate usando gli attributi data-src, data-srcset e data-sizes al posto di src, srcset e sizes, per evitare un caricamento immediato (eager) nei browser che non supportano loading="lazy".

<img
  data-src="lazy-sloth.jpg"
  class="lazy"
  alt="Lazy Sloth"
/>

Link: per una guida completa su come caricare in modo lazy le immagini responsive, leggi maggiori informazioni sul lazy loading delle immagini responsive.

E ora passiamo al codice Javascript! #

Avrai bisogno della versione 12 di vanilla-lazyload.
Puoi includerla tramite CDN:

<script src="https://cdn.jsdelivr.net/npm/vanilla-lazyload@12.0.0/dist/lazyload.min.js"></script>

Oppure installarla tramite npm:

npm install vanilla-lazyload@12.0.0

Nel tuo codice, imposta l'opzione use_native a true quando istanzi LazyLoad:

new LazyLoad({
  elements_selector: `.lazy`,
  use_native: true // Questo qui
});

Il flag use_native: true imposta questi comportamenti contestuali:

dove il lazy loading nativo è supportato, LazyLoad aggiunge l'attributo loading="lazy" alle immagini, quindi si limita a sostituire gli attributi data-* con quelli corretti. A questo punto il browser gestirà il lazy loading da solo.
dove il lazy loading nativo NON è supportato, il lazy loading continuerà a essere gestito da JavaScript, sfruttando l'API IntersectionObserver del browser.

Per concludere #

Caricare i contenuti in modalità lazy è molto importante per migliorare la velocità di caricamento di un sito web; i produttori di browser stanno finalmente iniziando a implementarlo nativamente e non vedo l'ora che sia disponibile su Edge, Safari e Firefox.

Fino ad allora, puoi avere sia il lazy loading nativo che quello basato su JavaScript usando vanilla-lazyload 12, semplicemente impostando l'opzione use_native a true.

Provalo!

Se ti piace, metti una stella ⭐ alla repository. Se trovi qualcosa che non va, apri una segnalazione (issue) in modo che io possa provare a risolverlo. Per qualsiasi domanda, contattami su Twitter.

Un saluto!

Design di tabelle responsive e accessibili

2019-03-08T00:00:00Z

Come fare in modo che una tabella potenzialmente larga si adatti ai dispositivi più piccoli, senza perdere in leggibilità e accessibilità? Ecco alcune semplici soluzioni per far apparire le tabelle come liste e le liste come tabelle, all'interno di un design responsive e accessibile.

Ipotizziamo di avere una tabella HTML <table> contenente degli ordini, ognuno dei quali ha:

un'immagine
una descrizione
un prezzo

E abbiamo la necessità di far sì che:

appaia come una lista su viewport piccole, tipicamente gli smartphone
appaia come una tabella su viewport più grandi, come tablet e computer
sia accessibile (vedi accessibilità), ad esempio per gli utenti non vedenti

Il markup della tabella #

Ecco il markup della tabella di partenza.

<table>
  <thead>
    <tr>
      <th scope="col">Foto</th>
      <th scope="col">Descrizione</th>
      <th scope="col">Prezzo</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><img src="https://via.placeholder.com/70x100&text=Product"></td>
      <td>Descrizione</td>
      <td>EUR 12.345</td>
    </tr>
    <tr>
      <td><img src="https://via.placeholder.com/70x100&text=Product"></td>
      <td>Descrizione</td>
      <td>EUR 12.345</td>
    </tr>
  </tbody>
</table>

La soluzione in questo caso consiste nell'impostare display: flex sulle righe (tr), e poi orientare le celle in verticale usando flex-direction: column.

tr {
  display: flex;
  flex-direction: column;
}

@media (min-width: 400px) {
  tr {
    flex-direction: row;
  }
}

E boom. Ecco l'esempio su CodePen.

Vedi la Pen Table markup, list layout (on small viewports) di Andrea Verlicchi (@verlok) su CodePen.

Ma si tratta davvero di una tabella? #

Il tag table è davvero quello corretto da usare in questo caso? Non è che forse lo abbiamo scelto solo per comodità di layout? In fin dei conti, non si tratta semplicemente di una lista di ordini? Allora perché non utilizzare invece un tag ul?

<ul>
  <li>
    <div class="photo"><img src="https://via.placeholder.com/70x100&text=Product"></div>
    <div class="description">Descrizione</div>
    <div class="price">EUR 12.345</div>
  </li>
  <li>
    <div class="photo"><img src="https://via.placeholder.com/70x100&text=Product"></div>
    <div class="description">Descrizione</div>
    <div class="price">EUR 12.345</div>
  </li>
</ul>

In questo caso, nel CSS, dobbiamo solo allineare orizzontalmente i div all'interno degli elementi della lista (li), quando c'è abbastanza spazio per farlo.

@media (min-width: 400px) {
  li {
    display: flex;
  }
}

div {
  padding: 10px;
}

Ecco il risultato:

Vedi la Pen List markup, table layout (on large viewports) di Andrea Verlicchi (@verlok) su CodePen.

Considerazioni sull'accessibilità #

Le tabelle (table) possono essere estremamente accessibili se sviluppate correttamente, ma credo che abbia senso utilizzarle solo quando i dati in ogni singola cella hanno almeno 2 intestazioni (header): una all'inizio della colonna e una all'inizio della riga.

Se hai solo un titolo per ogni colonna e poche colonne in totale, probabilmente è meglio considerarla come una lista e scriverne il markup di conseguenza, usando ul o ol a seconda delle preferenze. Assicurati di fare la scelta corretta!

Infine, ma non meno importante: se utilizzi un markup non tabellare (ul, div, span) che viene mostrato visivamente come una tabella e desideri renderlo accessibile, assicurati di utilizzare i ruoli ARIA (ARIA roles) per definire rowgroup, columnheader, rowheader, cell, ecc.

Conclusione #

Puoi usare Flexbox per far sì che una tabella sembri una lista, o una lista sembri una tabella con grande facilità. Tieni sempre a mente l'accessibilità! Quando sviluppi tabelle reali, usa gli header per righe e colonne. Quando sviluppi pseudo-tabelle, usa i ruoli ARIA per definire chi fa cosa.

Caricamento lazy di immagini responsive nel 2019

2019-03-01T00:00:00Z

Negli ultimi anni, sia per lavoro che come autore e manutentore di uno script LazyLoad, mi sono specializzato nel lazy loading (caricamento pigro) di immagini responsive. Oggi ti mostrerò quale codice HTML, CSS e JavaScript devi scrivere nel 2019 per servire immagini responsive e caricarle in modalità lazy. Nella seconda parte del post, ti mostrerò anche come fare in modo che il browser scelga nativamente l'immagine in formato WebP quando lo supporta.

Articolo obsoleto! 👀 #

Un momento! Stai leggendo una vecchia versione di questo articolo.

👉 Leggi l'aggiornamento del 2020

Lazy responsive... cosa? #

Le immagini responsive sono le immagini che si adattano allo schermo dell'utente e al contempo mantengono veloci i nostri siti web scaricando solo la sorgente corretta per la specifica larghezza della viewport (dai piccoli dispositivi mobili ai grandi computer desktop), considerando anche la densità dello schermo dell'utente (display retina, hiDPI, ecc.).

Il lazy loading delle immagini è una tecnica per velocizzare il sito web evitando di caricare le immagini che si trovano sotto la piega (below the fold), caricandole poi solo quando entrano nella viewport. Oltre alle prestazioni, questo ti consente anche di risparmiare larghezza di banda e denaro, ad esempio se paghi un servizio CDN a consumo per le immagini.

Ricevuto! Ora mostrami un po' di codice! #

→ Dai un'occhiata ai risultati ← che otterrai. Apri gli strumenti per sviluppatori (developer tools) del tuo browser e vai nel pannello Network. Vedrai che le prime immagini vengono caricate immediatamente (in modalità eager) all'atterraggio sulla pagina, mentre le restanti vengono caricate via via che scorri verso il basso del documento.

Il markup HTML #

Ecco il markup di un'immagine responsive caricata immediatamente.

<!-- Immagine responsive caricata immediatamente -->
<img
	alt="Image 01"
	src="https://via.placeholder.com/220x280?text=Img+01"
	srcset="
		https://via.placeholder.com/220x280?text=Img+01 220w,
		https://via.placeholder.com/440x560?text=Img+01 440w
	"
	sizes="220px"
/>

Per assicurarti che i tuoi utenti vedano le immagini il prima possibile, ti consiglio di caricare immediatamente le immagini in cima alla pagina web, ovvero solo quelle che si troveranno sopra la piega (above the fold) nelle viewport più comuni, considerando smartphone, tablet e computer.

Ricorda sempre che il lazy loading è un'operazione gestita tramite JavaScript, quindi prima che il download di qualsiasi immagine lazy possa iniziare, il codice JavaScript deve essere scaricato, interpretato ed eseguito, le immagini lazy devono essere individuate nel DOM e la loro posizione valutata. E tutte queste operazioni richiedono del tempo.

Ed ecco il markup di cui avrai bisogno per caricare un'immagine responsive in modalità lazy.

<!-- Immagine responsive caricata in modalità lazy -->
<img
	alt="Image 03"
	class="lazy"
	data-src="https://via.placeholder.com/220x280?text=Img+03"
	data-srcset="https://via.placeholder.com/220x280?text=Img+03 220w,
        https://via.placeholder.com/440x560?text=Img+03 440w"
	data-sizes="220px"
/>

Se vuoi che le tue immagini lazy abbiano un'anteprima a bassa risoluzione durante il caricamento, puoi inserire una piccola immagine a bassa qualità nel tag src in questo modo:

<!-- Immagine responsive in modalità lazy con anteprima a bassa qualità -->
<img
	alt="Image 03"
	class="lazy"
	src="https://via.placeholder.com/11x14?text=Img+03"
	data-src="https://via.placeholder.com/220x280?text=Img+03"
	data-srcset="https://via.placeholder.com/220x280?text=Img+03 220w,
        https://via.placeholder.com/440x560?text=Img+03 440w"
	data-sizes="220px"
/>

Stiamo usando il tag HTML img e non il tag picture, poiché quest'ultimo non è necessario in questo caso. Approfondirò i casi d'uso del tag picture più in basso.

Ma aspetta, e per quanto riguarda Internet Explorer?

È vero, Internet Explorer non supporta le immagini responsive, ma dato che è rimasta in circolazione solo la sua ultima versione e sta lentamente scomparendo dai nostri radar (nei siti che gestiamo, la sua quota si aggira intorno al 4%), ti suggerisco di NON utilizzare un polyfill per le immagini responsive, affidandoti invece semplicemente all'immagine specificata nell'attributo src (o data-src).

Inclusione dello script #

Per caricare le immagini lazy quando entrano nella viewport, hai bisogno di uno script di lazy load come vanilla-lazyload, uno script leggero come l'aria (1,9 kb gzipped), configurabile ed SEO-friendly che sviluppo e miglioro dal 2014. È basato sull'API del browser IntersectionObserver, quindi è velocissimo e garantisce uno scorrimento fluido (jank-free) anche sui dispositivi meno potenti.

Ecco il modo più semplice per includere lo script nella tua pagina.

<script src="https://cdn.jsdelivr.net/npm/vanilla-lazyload@11.0.4/dist/lazyload.min.js"></script>

Altri modi per includere LazyLoad nelle tue pagine web, ad esempio utilizzando uno script async con auto-inizializzazione, usando RequireJS, Webpack o Rollup, sono documentati qui.

Inizializzazione di LazyLoad #

Devi fare in modo che LazyLoad gestisca e carichi tutte le immagini con la classe .lazy nella pagina. Puoi inizializzare LazyLoad in questo modo:

var lazyLoad = new LazyLoad({
	elements_selector: ".lazy",
	// Altre opzioni qui
});

Alcuni trucchi CSS #

Ci sono anche alcune funzionalità che puoi ottenere utilizzando esclusivamente i CSS. Devi:

Fare in modo che le immagini lazy non ancora caricate occupino dello spazio. Se non lo fai, tali immagini avranno altezza 0 e collasseranno una accanto all'altra. Di conseguenza, entreranno nella viewport tutte nello stesso momento, vanificando i nostri sforzi per caricarle man mano che compaiono sullo schermo.
Evitare che le immagini vuote appaiano come interrotte (broken images)
Risolvere un'anomalia di Firefox che mostra l'icona dell'immagine non trovata durante il caricamento delle immagini

Puoi fare tutto questo usando queste regole CSS:

/*
Fa in modo che il contenitore delle immagini occupi spazio
quando le immagini non sono ancora caricate.
Questo valore dipende dal tuo layout.
*/
.imageList li {
	min-height: 300px;
}

/*
Evita che le immagini vuote appaiano come interrotte
*/
img:not([src]):not([srcset]) {
	visibility: hidden;
}

/*
Risolve l'anomalia di Firefox durante il caricamento delle immagini
*/
@-moz-document url-prefix() {
	img:-moz-loading {
		visibility: hidden;
	}
}

Casi d'uso del tag picture #

Finora ho parlato del tag img con gli attributi srcset e sizes, che rappresenta la soluzione per la stragrande maggioranza delle immagini responsive di cui potresti aver bisogno su un sito o un'applicazione web. Ora, in quali casi dovresti usare invece il tag picture?

Proporzioni (width/height ratio) differenti #

Caso d'uso: devi mostrare immagini con proporzioni (aspect ratio) differenti a seconda di una media query. Ad esempio, vuoi mostrare immagini verticali (portrait) sui dispositivi mobili e immagini orizzontali (landscape) su viewport più ampie, come tablet e computer.

→ Dai un'occhiata ai risultati ←

Ecco il codice di cui avrai bisogno in questo caso. Per avere immagini caricate immediatamente, ti basterà usare gli attributi standard src e srcset senza il prefisso data-.

<picture>
	<source
		media="(min-width: 1024px)"
		data-srcset="https://via.placeholder.com/1024x576?text=Horizontal+Image 1x,
      https://via.placeholder.com/2048x1152?text=Horizontal+Image 2x"
	/>
	<source
		media="(max-width: 1023px)"
		data-srcset="https://via.placeholder.com/640x960?text=Vertical+Image 1x,
      https://via.placeholder.com/1280x1920?text=Vertical+Image 2x"
	/>
	<img
		class="lazy"
		alt="Stivaletti"
		data-src="https://via.placeholder.com/1024x576?text=Horizontal+Image"
	/>
</picture>

Passaggio automatico al formato WebP #

Caso d'uso: vuoi che le immagini passino automaticamente al formato WebP se il browser supporta tale formato.

→ Dai un'occhiata ai risultati ←

Ecco il codice! Anche in questo caso, per caricare le immagini immediatamente, usa semplicemente gli attributi standard src, srcset e sizes senza il prefisso data-.

<picture>
	<source
		type="image/webp"
		data-srcset="https://via.placeholder.com/1024x576?text=WebP+Image 1x,
      https://via.placeholder.com/2048x1152?text=WebP+Image 2x"
		data-sizes="220px"
	/>
	<img
		data-src="https://via.placeholder.com/256.jpg?text=1024x576+Jpg+Image"
		data-srcset="https://via.placeholder.com/1024x576?text=Jpg+Image 1x,
      https://via.placeholder.com/2048x1152?text=Jpg+Image 2x"
		data-sizes="220px"
		alt="An image"
		class="lazy"
	/>
</picture>

Un'ultima cosa #

Lo script vanilla LazyLoad sfrutta l'API IntersectionObserver, pertanto sui browser che non la supportano (come Internet Explorer e le vecchie versioni di Safari) caricherà tutte le immagini subito al momento dell'esecuzione, portando all'incirca allo stesso risultato che si otterrebbe senza usare alcun lazy loader.

Se vuoi caricare i tuoi contenuti in modalità lazy sul 100% dei browser in circolazione (io non lo farei, ma la scelta spetta a te), devi includere lo script IntersectionObserver Polyfill prima di LazyLoad.

Puoi inserire lo script nella pagina subito prima di quello di LazyLoad, in questo modo...

<script src="https://cdn.jsdelivr.net/npm/intersection-observer@0.5.1/intersection-observer.js"></script>
<script src="https://cdn.jsdelivr.net/npm/vanilla-lazyload@11.0.4/dist/lazyload.min.js"></script>

...oppure puoi caricare il polyfill come dipendenza di LazyLoad utilizzando RequireJS o un altro caricatore di moduli AMD. Maggiori informazioni qui.

Conclusioni #

Ecco un riassunto dei punti chiave:

Non caricare tutte le immagini in modalità lazy, ma solo quelle below the fold (sotto la piega)
Utilizza il tag img per le immagini responsive semplici
Utilizza il tag picture per servire in modo condizionale la versione WebP delle immagini o per modificarne le proporzioni (aspect ratio)
Utilizza vanilla-lazyload per caricare le immagini lazy
Utilizza opzionalmente il polyfill per IntersectionObserver se vuoi abilitare il lazy loading sul 100% dei browser

Se qualcosa non fosse chiaro o potesse essere migliorato, ti invito a contattarmi per farmelo sapere.

Se hai trovato utile questo post, non esitare a condividerlo!

Risorse utili #

Responsive images in practice @ A List Apart (in inglese)
Responsive images @ Mozilla Developer Network (in inglese)
Responsive images in CSS @ CSS Tricks (in inglese)
Sito web del Responsive images community group

Verificare se un elemento è ancora nella viewport dopo un certo tempo

2018-08-27T00:00:00Z

Cosa faresti se qualcuno ti chiedesse di caricare un elemento DOM solo se rimane all'interno della viewport per un determinato periodo di tempo? Utilizzeresti vanilla-lazyload, vero? 😉 Questa è esattamente la nuova funzionalità che la community di GitHub ha richiesto per LazyLoad, allo scopo di evitare il caricamento di elementi che gli utenti hanno saltato scorrendo via velocemente. In questo post vorrei condividere con te la soluzione.

Ci sono un paio di modi per farlo. Il primo consiste nel controllare la posizione dell'elemento nel tempo, il secondo sfrutta IntersectionObserver.

Il metodo (lento) senza IntersectionObserver #

Questo metodo è molto più lento rispetto all'utilizzo di IntersectionObserver perché comporta:

il monitoraggio degli eventi scroll e resize del browser per chiamare una callback (gestita con throttling)
all'interno della callback, un ciclo su tutti gli elementi osservati per chiamare una funzione isInsideViewport che verifichi se sono nella viewport
la funzione isInsideViewport a sua volta controlla una serie di parametri come getBoundingClientRect dell'elemento, innerHeight della finestra, pageYOffset, ecc., e restituisce un valore booleano

Tutto questo solo per sapere quando gli elementi entrano nella viewport.

Per sapere se un determinato elemento è rimasto nella viewport per un certo tempo, dovresti fare qualcosa del genere:

quando l'elemento entra nella viewport, avvii una funzione tramite setTimeout. Chiamiamola isStillInsideViewport.
all'interno di questa funzione, verifichi se l'elemento è ancora nella viewport chiamando isInsideViewport su quell'elemento, quindi:
- se lo è, lo carichi e lo rimuovi dagli elementi osservati
- se NON lo è, non lo carichi e continui a monitorarlo

Un concetto piuttosto lineare, ma non così rapido da eseguire.

Il metodo con IntersectionObserver #

Questo metodo è molto più veloce perché comporta unicamente quanto segue:

configuri un IntersectionObserver e lo usi per osservare tutti gli elementi da monitorare
questo chiama una funzione onIntersection ogni volta che un elemento si interseca con la viewport
puoi gestire tutta la logica di caricamento all'interno della funzione onIntersection

Non c'è alcun bisogno di monitorare gli eventi scroll o resize del browser.

Prima idea #

Il mio primo pensiero era di farlo senza IntersectionObserver, il che significava dover verificare lo stato "è all'interno della viewport" dopo un determinato timeout.

Si è scoperto però che non esiste un modo elegante per verificare se un elemento si trova all'interno della viewport usando IntersectionObserver. Tutto ciò che si ottiene sono delle callback quando un elemento si interseca con la viewport.

Scoprire i threshold (soglie) #

Ma aspetta, cos'è quell'opzione thresholds di IntersectionObserver menzionata nella documentazione? 😲

Dice MDN:

Un singolo numero o un array di numeri che indicano a quale percentuale di visibilità del target debba essere eseguita la callback dell'observer. Se desideri rilevare solo quando la visibilità supera il 50%, puoi usare il valore 0.5. Se vuoi che la callback venga eseguita ogni volta che la visibilità supera un altro 25%, specificherai l'array [0, 0.25, 0.5, 0.75, 1]. Il valore predefinito è 0 (ovvero, non appena anche un solo pixel è visibile, la callback viene eseguita). Un valore di 1.0 significa che la soglia non è considerata superata finché ogni singolo pixel non è visibile.

Dopo aver fatto qualche prova con questa opzione e aver testato il risultato in una specifica demo di caricamento ritardato (delay load), ho scoperto che passando 0 all'opzione thresholds (che è il valore predefinito), la funzione onIntersection viene chiamata anche quando l'elemento esce dalla viewport.

La soluzione definitiva #

Una volta capito come intercettare quando un elemento esce dalla viewport, risolvere il problema principale è diventato molto più semplice.

La soluzione finale consiste nel:

quando un elemento entra nella viewport, impostare un setTimeout per caricare l'elemento
memorizzare ciascun ID del timeout in un attributo data- dell'elemento correlato
lasciare che l'elemento si carichi allo scadere del timeout
se l'elemento esce dalla viewport prima che il timeout venga eseguito, annullare il timeout tramite clearTimeout

Semplice e lineare! 😊

Mostrami il codice! #

Puoi trovare il codice completo nel file lazyload.js di vanilla-lazyload e nei relativi import correlati. Se non ti va di saltare da un file all'altro, puoi anche aprire il file pacchettizzato lazyload.es2015.js nella cartella dist.

Di seguito è riportata una versione semplificata del codice per comodità.

Configurazione di IntersectionObserver #

const gObserver = new IntersectionObserver(onIntersection, {
  rootMargin: "0px",
  threshold: 0
});

L'opzione rootMargin impostata su 0px indica di osservare la dimensione effettiva della viewport. Puoi passare qualsiasi lunghezza CSS per espandere l'area osservata. Ad esempio, passare 300px la espanderà di tale misura sopra, a destra, sotto e a sinistra.

La funzione onIntersection #

Questa funzione viene chiamata ogni volta che si verifica un'intersezione e il parametro rappresenta l'insieme di elementi (entries) che si sono intersecati con la viewport.

Ipotizzando che watchedElements siano gli elementi monitorati dallo script (vedi sotto), dopo ogni intersezione essi dovrebbero essere rimossi dall'elenco degli elementi già gestiti (caricati).

La funzione purgeElements esula dagli scopi di questo post, ma si limita a restituire un sottoinsieme di watchedElements.

const onIntersection = entries => {
  entries.forEach(manageIntersection);
  watchedElements = purgeElements(watchedElements);
};

La funzione manageIntersection #

Questa funzione viene chiamata per ciascuna entry che si è intersecata con la viewport. Sia in entrata che in uscita.

In entrata avvia il caricamento ritardato dell'elemento. In uscita lo annulla.

const manageIntersection = entry => {
  var element = entry.target;
  if (isIntersecting(entry)) {
    delayLoad(element, delayTime);
  } else {
    cancelDelayLoad(element);
  }
};

Funzione di utilità isIntersecting #

Questa è una funzione di utilità per comprendere se un elemento si stia intersecando o meno con la viewport.

Nota che:

entry.isIntersecting necessita di un fallback perché è null in alcune versioni di Microsoft Edge
entry.intersectionRatio da solo non è sufficiente poiché potrebbe essere 0 su alcuni elementi in intersezione

const isIntersecting = (entry) =>
  entry.isIntersecting || entry.intersectionRatio > 0;

La funzione delayLoad #

Questa è la funzione che ritarda il caricamento dell'elemento di un tempo pari a delayTime.

getTimeoutData e setTimeoutData sono funzioni di utilità per leggere e scrivere l'ID del timeout da/in un attributo data- dell'elemento.

const delayLoad = (element, delayTime) => {
  var timeoutId = getTimeoutData(element);
  if (timeoutId) {
    return; // il timeout era già impostato, non fa nulla
  }
  timeoutId = setTimeout(function() {
    loadAndUnobserve(element);
    cancelDelayLoad(element);
  }, delayTime);
  setTimeoutData(element, timeoutId);
};

La funzione cancelDelayLoad #

Questa funzione ha il compito di annullare il timeout dell'elemento, si impostato.

const cancelDelayLoad = element => {
  var timeoutId = getTimeoutData(element);
  if (!timeoutId) {
    return; // non fa nulla se il timeout non esiste
  }
  clearTimeout(timeoutId);
  deleteTimeoutData(element);
};

La funzione loadAndUnobserve #

Questa funzione carica immediatamente l'elemento e lo rimuove dagli elementi monitorati dall'istanza di IntersectionObserver.

const loadAndUnobserve = (element) => {
  // Qui è dove fai effettivamente qualcosa con l'elemento
  revealElement(element);
  gObserver.unobserve(element);
};

Al mio segnale, scatenate l'inferno! #

Abbiamo fatto tutto nel migliore dei modi finora, ma non abbiamo ancora avviato nulla! Abbiamo bisogno di un insieme di elementi da monitorare (watchedElements) da passare al nostro IntersectionObserver, altrimenti non succederà nulla.

var watchedElements = document.querySelectorAll("img");
watchedElements.forEach(element => gObserver.observe(element));

Tutto insieme #

Puoi trovare una versione funzionante del codice sopra indicato su CodeSandbox per poterci sperimentare direttamente!

Conclusioni #

Hai visto com'è semplice verificare se un elemento è ancora nella viewport dopo un po' di tempo usando IntersectionObserver?

Per ulteriori informazioni su come realizzare un LazyLoad utilizzando IntersectionObserver, leggi Intersection Observer e caricamento lazy degli elementi.

C'è qualcosa che avresti fatto diversamente, o sei d'accordo con le mie scelte? Contattami e fammi sapere cosa ne pensi!

Se vuoi mostrare il tuo apprezzamento per LazyLoad, lascia una stella su GitHub! ⭐

Creare una libreria JavaScript con moduli ES2015, Gulp, Rollup e Jest

2017-09-09T00:00:00Z

Vediamo come scrivere una libreria JavaScript utilizzando ES2015 transpilato con Babel, sfruttando i moduli ES impacchettati con Rollup tramite Gulp e usando Jest per testare il codice.

In questo articolo condivido l'esperienza maturata durante lo sviluppo del mio script vanilla-lazyload, poiché all'epoca non riuscii a trovare nulla che spiegasse come utilizzare queste librerie insieme, in particolare Rollup e Jest.

Installare Gulp #

Gulp è un task runner simile a Grunt per automatizzare i compiti più noiosi o lunghi nel flusso di lavoro di sviluppo. Ho scelto di migrare da Grunt a Gulp perché quest'ultimo è incredibilmente veloce, essendo basato sugli stream (flussi di dati) di Node invece che sul file system.

Per utilizzare Gulp, devi installarlo localmente nel tuo progetto, eseguendo:

npm install --save-dev gulp

Una buona opzione per utilizzare Gulp è installare il suo eseguibile da riga di comando tramite:

npm install -g gulp-cli

Per maggiori informazioni, ti suggerisco di leggere l'articolo Gulp for beginners su CSS-Tricks (in inglese).

Configurare Gulp #

L'esecuzione di Gulp richiede un file di configurazione chiamato gulpfile.js. Per ora creane uno vuoto, ti mostrerò passo dopo passo cosa inserire al suo interno.

1. Analisi statica (linting) dei file sorgente #

Essendo JavaScript un linguaggio dinamico e a tipizzazione debole, è particolarmente incline agli errori di sviluppo. Strumenti di linting come ESLint consentono agli sviluppatori di individuare errori nel codice JavaScript senza doverlo effettivamente eseguire.

Per installare ESLint per Gulp, basta eseguire:

npm install --save-dev gulp-eslint

Quindi, nel tuo file gulpfile.js vuoto, aggiungi:

var gulp = require("gulp");
var eslint = require("gulp-eslint");

gulp.task("default", function () {
    process.env.NODE_ENV = "release";
    return gulp.src("./src/**/*.js")
        // ----------- linting --------------
        .pipe(eslint())
        .pipe(eslint.format())
        .pipe(eslint.failAfterError()) // --> si interrompe in caso di errori
        // --> concatena altre operazioni qui
});

NOTA: Impostare la variabile process.env.NODE_ENV è necessario per farla coincidere con il task che stiamo eseguendo nella configurazione di Babel. Lo spiegherò tra poco.

2. Impacchettare i moduli con Rollup #

Rollup è un module bundler per JavaScript che compila piccoli pezzi di codice in qualcosa di più grande, come una libreria. Utilizza il formato standard per i moduli di codice introdotto con la revisione ES2015 di JavaScript.

In parole povere, Rollup legge il tuo file JavaScript principale e genera automaticamente un unico file più grande contenente tutti i moduli inclusi.

Installa Rollup con:

npm install --save-dev gulp-rollup gulp-rename

Quindi nel tuo gulpfile, aggiungi semplicemente un comando .pipe():

// ----------- rollup --------------
.pipe(rollup({
    format: "umd",
    moduleName: "LazyLoad",
    entry: "./src/lazyload.js"
}))

Questo indica a Rollup che deve produrre un modulo di tipo umd, il cui nome sarà LazyLoad, e che il punto di ingresso (entry point) da cui iniziare a cercare le dipendenze è ./src/lazyload.js.

Poiché voglio distribuire una versione dello script che non sia transpilata in ES5, la salvo come lazyload.es2015.js concatenando i comandi rename e dest.

.pipe(rename("lazyload.es2015.js"))
.pipe(gulp.dest(destFolder)) // --> scrittura del bundle Rollup

destFolder è una variabile JavaScript ed è impostata su ./dist all'interno del nostro gulpfile.js.

NOTA: Webpack è uno strumento di bundling simile che potrebbe essere preferibile per applicazioni complesse, ma ho notato che il codice finale generato da Webpack è molto più pesante, perciò nel mio caso Rollup si è rivelato la scelta migliore.

3. Transpilazione in ES5 con Babel #

Fino a questo punto abbiamo unito tutti i nostri moduli in un unico file che funzionerà solo nei browser moderni. Naturalmente, vogliamo produrre anche un file leggibile da browser meno moderni.

Per installare Babel e il suo preset per ES2015, più un plugin per trasformare Object.assign() in ES5, esegui:

npm install --save-dev babel-core gulp-babel babel-preset-es2015 babel-plugin-transform-object-assign

Quindi, per elaborare con Babel il file precedentemente creato con Rollup e salvarlo come lazyload.js, richiediamo gulp-babel e aggiungiamo il seguente passaggio nel nostro gulpfile.js:

var babel = require("gulp-babel");

// ----------- babelizzazione --------------
.pipe(babel())
.pipe(rename("lazyload.js"))
.pipe(gulp.dest(destFolder)) // --> scrittura del file js es5 transpilato con Babel

La configurazione di Babel deve essere memorizzata in un file .babelrc esterno, che nel mio caso si presenta così:

{
    "ignore": [
        "node_modules/**"
    ],
    "env": {
        "test": {
            "presets": [
                "es2015"
            ],
            "plugins": ["transform-object-assign"]
        },
        "release": {
            "presets": [
                ["es2015", {
                    "modules": false
                }]
            ],
            "sourceMap": false,
            "plugins": ["transform-object-assign"]
        }
    }
}

Avrai notato che ho configurato i due ambienti (env) in modo diverso:

release è quello utilizzato da Rollup in Gulp. Ricordi? Lo abbiamo impostato nel gulpfile.js usando process.env.NODE_ENV = "release"
test è quello utilizzato da Jest (la spiegazione segue sotto)

4. Minificazione con Uglify #

Uglify JS è un set di strumenti per la compressione di JavaScript comunemente utilizzato per minificare la versione di distribuzione delle librerie JavaScript.

npm install --save-dev gulp-uglify

Quindi, aggiungi il require e il pipe seguenti al nostro gulpfile.js:

var uglify = require("gulp-uglify");

// ----------- minificazione --------------
.pipe(uglify())
.pipe(rename("lazyload.min.js"))
.pipe(gulp.dest(destFolder)); // --> scrittura del codice minificato

Tutto insieme #

Ecco come dovrebbe apparire il tuo file gulpfile.js completo:

var gulp = require("gulp");
var eslint = require("gulp-eslint");
var rollup = require("gulp-rollup");
var rename = require("gulp-rename");
var babel = require("gulp-babel");
var uglify = require("gulp-uglify");

var destFolder = "./dist";

gulp.task("default", function () {
    process.env.NODE_ENV = "release";
    return gulp.src("./src/**/*.js")
        // ----------- linting --------------
        .pipe(eslint())
        .pipe(eslint.format())
        .pipe(eslint.failAfterError()) // --> si interrompe in caso di errori
        // ----------- rollup --------------
        .pipe(rollup({
            format: "umd",
            moduleName: "LazyLoad",
            entry: "./src/lazyload.js"
        }))
        .pipe(rename("lazyload.es2015.js"))
        .pipe(gulp.dest(destFolder)) // --> scrittura del bundle Rollup
        // ----------- babelizzazione --------------
        .pipe(babel())
        .pipe(rename("lazyload.js"))
        .pipe(gulp.dest(destFolder)) // --> scrittura del file ES5 transpilato con Babel
        // ----------- minificazione --------------
        .pipe(uglify())
        .pipe(rename("lazyload.min.js"))
        .pipe(gulp.dest(destFolder)); // --> scrittura del codice minificato
});

gulp.task("watch", function () {
    gulp.watch("./src/**/*.js", ["default"]);
    // Altri watcher
});

La sezione "watch" fa sì che se eseguiamo il comando gulp watch, gulp monitora la cartella src in cerca di modifiche e ricrea automaticamente i file nella cartella dist. Comodo!

Eseguire Gulp #

Ora puoi compilare la tua libreria eseguendo Gulp in un'unica soluzione:

gulp

Oppure puoi fare in modo che monitori le modifiche ai file sorgente in src mentre stai sviluppando:

gulp watch

Far funzionare Jest insieme a Rollup #

Scriverò un altro post dettagliato su come ho usato Jest per testare moduli che diventano variabili e funzioni private minificate, ma il punto cruciale qui è come far convivere Jest e Rollup, dato che i due richiedono configurazioni di Babel differenti.

Come abbiamo visto, la configurazione di Babel è suddivisa in due ambienti (env) e quello impostato e utilizzato da Jest è test. Questo perché Jest ha solo bisogno che l'oggetto presets contenga ["es2015"], mentre Rollup richiede ["es2015", {"modules": false}].

Se hai seguito correttamente le spiegazioni, Jest dovrebbe funzionare fin da subito.

npm install --save-dev jest
npm install -g jest-cli

Quindi lancia Jest così:

jest

Trovi maggiori informazioni su Jest nella pagina di guida all'avvio.

Passaggi successivi #

Una configurazione più avanzata consisterebbe nel configurare npm come interfaccia a riga di comando per compilazione e test, in modo da poter eseguire npm run build e npm run test per lanciare la build o i test, o meglio ancora includere il processo di test nella build stessa in modo che se i test falliscono, fallisca anche la build. Questo sarà il mio prossimo passo.

Intersection Observer e il caricamento lazy degli elementi

2017-09-04T00:00:00Z

Ad agosto 2017 una nuova ed entusiasmante API del browser ha finalmente ottenuto un supporto piuttosto ampio: l'Intersection Observer API, che possiamo utilizzare per rilevare quando due elementi DOM si intersecano, o quando un determinato elemento DOM entra nella viewport del browser. Il caricamento lazy (pigro) delle immagini è proprio il caso d'uso ideale.

Circa 3 anni e 500 commit fa, ho dato vita a un nuovo script per il caricamento lazy in vanilla JavaScript, attualmente noto come vanilla-lazyload su npm e cdnjs, che ha ricevuto oltre 1.135 stelle su GitHub.

Il passaggio a Intersection Observer #

Con la crescita della community organizzata attorno al mio script, alcuni membri hanno richiesto il supporto all'API Intersection Observer, tra altri miglioramenti.

Così ho deciso di accontentare i fan dello script. Il codice sorgente risultante è più piccolo del 40% e vanilla-lazyload è ora molto più veloce rispetto alla versione precedente. (a proposito, se conosci un modo per misurare con precisione le prestazioni di uno script, lascia pure un commento!)

Come creare un Intersection Observer #

L'implementazione è piuttosto semplice: si crea una nuova istanza di IntersectionObserver specificando una funzione di callback da chiamare ogni volta che si verifica un evento di intersezione, e un paio di opzioni: root e rootMargin, ovvero:

root: l'elemento rispetto al quale si desidera verificare l'intersezione (null indica la viewport del browser)
rootMargin: utile nel caso in cui si voglia espandere o ridurre l'area sensibile dell'elemento root

var myObserver = new IntersectionObserver((entries) => {
    /* fai qualcosa */
}, {
    root: null,
    rootMargin: "300px 0"
});

Una volta creato l'intersection observer e assegnato a una variabile, puoi iniziare a osservare un elemento target in questo modo:

var elementToObserve = document.getElementById('observeMe');
myObserver.observe(elementToObserve);

Creare l'observer #

Dovendo verificare l'intersezione di un insieme di immagini/elementi rispetto al contenitore in scorrimento (la viewport o qualsiasi elemento con stile overflow: scroll), ho creato un nuovo IntersectionObserver memorizzandolo nella proprietà _observer di LazyLoad.

this._observer = new IntersectionObserver(onIntersection, {
    root: settings.container === document ? null : settings.container,
    rootMargin: settings.threshold + "px"
});

Note:

onIntersection è una funzione, illustrata di seguito
settings.container è il contenitore con lo scorrimento, il cui valore predefinito è document, passato dall'utente di LazyLoad nell'oggetto delle opzioni
settings.threshold è il numero di pixel oltre il contenitore di scorrimento da cui iniziare a caricare le immagini/elementi (default 300px)

La funzione onIntersection #

Il punto cardine è che ogni volta che un elemento DOM si interseca con il contenitore di scorrimento, viene chiamata la funzione onIntersection. Ecco come è definita:

const onIntersection = (entries) => {
    entries.forEach((entry) => {
        if (!entry.isIntersecting) {
            return;
        }
        let element = entry.target;
        revealElement(element, settings);
        this._observer.unobserve(element);
    });
};

Al parametro entries vengono passati tutti gli elementi osservati dall'observer che invoca la funzione. Dobbiamo quindi ciclare su ogni elemento (entry) e verificare se si sta intersecando o meno con l'elemento root. Fortunatamente, la proprietà isIntersecting fa proprio questo:

se l'elemento non si interseca, lo ignoriamo semplicemente eseguendo un return
se l'elemento si interseca, avviamo il caricamento della sorgente dell'elemento invocando revealElement, e poi smettiamo di osservare questa specifica entry (tramite unobserve), dato che il caricamento è già iniziato e non c'è più bisogno di tenerlo d'occhio

Osservare un elemento #

Non manca qualcosa? Certo! Il codice spiegato finora non produce alcun effetto se non diciamo al nostro observer di monitorare un elemento (o più di uno, nel nostro caso). Quello che dobbiamo fare è:

this._elements.forEach(element => {
    this._observer.observe(element);
});

Dove this._elements è l'insieme di elementi che LazyLoad ha individuato all'interno di this._container tramite un selettore specifico, al netto di quelli già commessi o elaborati (per gestire scenari come lo scroll infinito o altri casi di aggiornamento del DOM).

Fallback #

Poiché non tutti i browser sono creati uguali, dobbiamo verificare il supporto a IntersectionObserver prima di poterlo utilizzare. Il modo per farlo è semplice:

if (!("IntersectionObserver" in window)) {
    return;
}

Nel mio caso, sui browser in cui IntersectionObserver non è supportato, LazyLoad caricherà tutte le immagini contemporaneamente. Di conseguenza, se hai la necessità di caricare moltissime immagini e il tuo pubblico utilizza in percentuale significativa browser più datati, ti consiglio di utilizzare una versione di LazyLoad precedente alla 9. Consulta il changelog per maggiori dettagli.

Conclusione #

Tutto qui! Intersection Observer rende il codice molto più compatto, veloce e leggibile. Se non lo stai già usando, dovresti assolutamente iniziare a provarlo.

E non dimenticare: se hai una pagina molto lunga piena di immagini e altri contenuti, dovresti caricarli in modalità lazy utilizzando uno script dedicato, e la scelta migliore è sicuramente vanilla-lazyload!

Usare le variabili CSS come unità di spaziatura

2017-06-14T00:00:00Z

In questo articolo ti mostro come puoi utilizzare le variabili CSS, note popolarmente come proprietà personalizzate (CSS custom properties), per scalare gli spazi del tuo layout su diverse media query.

Il vantaggio: file CSS più corti, leggeri e facili da mantenere.

Per dimostrarlo, ho creato su CodePen l'esempio CSS vars based layout spacing. Lo trovi incorporato alla fine di questo post.

Cosa sono le variabili CSS #

Le variabili CSS sono una delle prossime grandi novità dei CSS. Non sono ancora supportate universalmente (spoiler: manca Internet Explorer) considerando le quote di mercato attuali dei browser, ma è giunto il momento di iniziare a sperimentarle, non trovi? Potrebbero rivelarsi utili nello sviluppo del tuo prossimo fantastico progetto!

La potenza delle variabili CSS risiede nel fatto che possiamo assegnare un valore a un nome e fare riferimento a quel valore usando il suo nome.

Come definire una variabile CSS #

Le variabili CSS possono essere definite in qualsiasi punto e vengono ereditate da tutti gli elementi figli dell'elemento DOM a cui vengono applicate.

html {
  --base-spacing: 15px;
}

Qui abbiamo definito una variabile CSS chiamata --base-spacing e le abbiamo assegnato il valore 15px. La variabile è definita sull'elemento html, quindi sarà disponibile in tutto il nostro documento.

(Sì, le variabili CSS devono iniziare con un doppio trattino (--), il che è un po' brutto, ma porta pazienza!)

Differenza con le variabili SASS #

Nel caso tu stia pensando: "E con ciò? Uso già SASS e il mio file _variables.scss è pieno zeppo di variabili!" - Beh, non è proprio la stessa cosa.

Le variabili SASS vengono pre-elaborate, quindi vengono trasformate in un valore CSS fisso e statico. Quando il CSS viene caricato, la variabile va perduta e rimane solo il suo valore, distribuito in tutti i punti in cui è stata utilizzata.

Una variabile SASS non può essere modificata dopo che il CSS è stato caricato. Le variabili CSS, invece, possono essere modificate tramite media query, JavaScript o tramite gli strumenti di sviluppo (developer tools) del tuo browser preferito.

Come utilizzare una variabile CSS #

Vogliamo che la variabile --base-spacing funga da unità di spaziatura da utilizzare per padding e margini in tutta la nostra pagina. Come procediamo?

.box {
  padding: var(--base-spacing);
  margin: var(--base-spacing);
}

h1 {
  margin-bottom: var(--base-spacing);
}

Fantastico! Ora stiamo usando la nostra variabile CSS come unità di spaziatura, proprio come faremmo con una variabile SASS, ma... ora possiamo modificarla!

Modificare il valore delle variabili CSS #

È qui che avviene la magia. I valori delle variabili CSS possono essere riassegnati come faresti con qualsiasi altra proprietà CSS, utilizzando:

le media query
JavaScript
i developer tools del tuo browser preferito

La prima cosa che puoi fare per comprendere la potenza delle variabili CSS è aprire i developer tools, individuare la variabile nel file CSS e cambiarne il valore. Prova qui.

Nel nostro caso, vogliamo ampliare gli spazi sugli schermi più grandi, quindi ci basta fare così:

@media (min-width: 500px) {
  html {
    --base-spacing: 30px;
  }
}

Tutto qui. Questa semplice riassegnazione della variabile farà scalare automaticamente tutti i nostri padding e margini, dato che abbiamo usato la variabile per definire i loro valori.

DEMO #

Ecco di cosa sto parlando:

Vedi la Pen CSS vars based layout spacing di Andrea Verlicchi (@verlok) su CodePen.

Possibilità infinite #

Ora che hai imparato a padroneggiare le variabili CSS, puoi spingerti ben oltre e lasciare che siano i tuoi utenti a decidere la spaziatura del layout, il colore principale o qualsiasi altra cosa.

Ti bastano solo alcuni campi di input e poche righe di JavaScript, come dimostrato da @wesbos in questo esempio.

Vedi la Pen Update CSS Variables with JS di Wes Bos (@wesbos) su CodePen.

Cambiare il colore del testo per contrasto in base alla luminosità dello sfondo

2017-06-02T00:00:00Z

Se dovessi cambiare il colore di un testo in posizione fissa (position: fixed) in base alla luminosità dello sfondo che scorre sotto di esso, come faresti? Filtri CSS, blend mode? E se dovessi supportare tutti i browser, incluso Internet Explorer? Ecco un paio di modi per farlo utilizzando le proprietà CSS clip e clip-path.

Ecco il risultato ottenuto con clip - ampio supporto dei browser

Vedi la Pen Text color change at background using clip di Andrea Verlicchi (@verlok) su CodePen.

Ed ecco il risultato ottenuto con clip-path - solo browser moderni

Vedi la Pen Text color change at background using clip-path di Andrea Verlicchi (@verlok) su CodePen.

Cosa succede qui in pratica:

il contenuto è avvolto da un box con classe clipper che ne ritaglia il contenuto
viene copiato all'interno di ogni contenitore :(
ha una posizione fissa tramite position: fixed

Dato che il contenuto ha una posizione fissa, rimane ancorato alla finestra del browser, ma viene ritagliato dagli elementi di ritaglio (clipping) che si muovono.

Questa soluzione presenta tuttavia due problemi:

c'è un bug in IE ed Edge che rende invisibili i figli di tipo blocco del contenuto. Funziona però con gli elementi inline, anche se si tratta di un trucco (hack)
dobbiamo copiare il contenuto all'interno di ciascun contenitore

Ti viene in mente una soluzione migliore? Se sì, scrivila nei commenti!

Immagini responsive, uno standard HTML 5.1

2017-04-10T00:00:00Z

È ufficiale. Le immagini responsive sono una raccomandazione W3C da novembre 2016, caratterizzate dal nuovissimo tag picture e dai nuovi attributi per il tag img: srcset e sizes.

Perché le immagini responsive? #

Nel 2010, Ethan Marcotte ha iniziato a parlare di responsive web design, un approccio al web design volto a consentire la visualizzazione delle pagine web in modo ottimale in base alle dimensioni della viewport del browser.

È stato qualcosa di rivoluzionario, ma all'improvviso noi sviluppatori ci siamo trovati di fronte a un nuovo problema: in un sito web responsive, quanto grandi dovrebbero essere i file delle immagini?

L'approccio iniziale consisteva nell'utilizzare un'unica immagine di grandi dimensioni per tutte le larghezze di viewport, in modo che le immagini apparissero eccellenti sugli schermi grandi anche se venivano rimpicciolite sui dispositivi più piccoli. Ben presto, però, questa si è rivelata una cattiva pratica: le connessioni più lente sui dispositivi mobili e le CPU meno performanti rallentavano il sito web, peggiorando l'esperienza dell'utente.

Gli sviluppatori hanno quindi iniziato a utilizzare JavaScript per scegliere la dimensione corretta dell'immagine in base alla viewport. È stato in quel periodo che sono nati script come picturefill.

Il fatto è che JavaScript è più lento del puro HTML: deve essere scaricato, interpretato (parsed) ed eseguito prima ancora che il browser possa iniziare a scaricare le immagini. Il web aveva bisogno di qualcosa di nativo per tornare a definire le immagini direttamente nel codice HTML, consentendo ai browser di avviarne il download il prima possibile.

Ecco perché un gruppo di designer e sviluppatori indipendenti, noto come Responsive Images Community Group, ha iniziato a proporre nuovi tag e attributi.

Cosa sono le immagini responsive? #

"Immagini responsive" è il nome dato alla tecnica che consiste nel definire più sorgenti per ogni singola immagine, facendo sì che i browser scarichino quella migliore in base ai seguenti fattori:

viewport del browser, o layout del tuo sito web
densità di pixel del dispositivo

Gli utenti hanno densità di pixel differenti a seconda dello schermo del loro dispositivo. I dispositivi standard hanno una densità di pixel pari a 1, il che significa che lo schermo ha 1 pixel fisico (device pixel) per ogni pixel CSS. I monitor HiDPI più recenti (inclusi i display "Retina") hanno invece una densità maggiore. Ad esempio, una densità di pixel pari a 2 significa che lo schermo ha 2x2 pixel fisici per ciascun pixel CSS, e così via.

I display HiDPI sono straordinari per il rendering di elementi vettoriali, come font o immagini SVG. Ma quando si tratta di renderizzare immagini bitmap, i browser si limitano a ingrandire l'immagine originale, rendendola sfuocata su dispositivi che dovrebbero invece offrire una qualità superiore.

Supportare i display HiDPI #

La cosa più semplice che puoi fare con il nuovo attributo srcset è supportare diverse densità di pixel. Ti basta specificare sorgenti diverse per la tua immagine, descrivendo ognuna con il descrittore x, che indica la densità di pixel della sorgente dell'immagine. In questo modo:

<img
	src="shirt_300w.jpg"
	srcset="shirt_300w.jpg 1x, shirt_600w.jpg 2x"
	alt="Una bella camicia"
	width="300"
	height="380"
/>

In questo esempio, vogliamo mostrare un'immagine di 300 x 380 pixel CSS. L'immagine a densità standard è shirt_300w.jpg ed è descritta dal descrittore 1x. L'immagine a doppia densità è shirt_600w.jpg, e deve essere di 600 x 760 pixel.

Nota: i browser che comprendono il nuovo attributo srcset ignoreranno l'attributo src, che è comunque richiesto come fallback.

Questo è già un ottimo risultato per offrire la migliore qualità d'immagine ai nostri utenti, ma cosa succede se nel nostro layout responsive la dimensione dell'immagine varia a seconda dello spazio disponibile?

Dimensioni dell'immagine differenti #

Supponiamo che la nostra immagine debba avere le seguenti larghezze:

300 pixel su viewport piccole (< 600)
600 pixel su viewport medie (>= 600)
1200 pixel su viewport grandi (>= 1200)

Come facciamo a garantire che i nostri utenti ottengano sempre la dimensione dell'immagine che meglio si adatta alla loro viewport e alla densità di pixel?

Possiamo definire immagini con queste dimensioni:

Densità / Larghezza viewport	< 600	>= 600	>= 1200
1x	300 x 380	600 x 760	1200 x 1520
2x	600 x 760	1200 x 1520	2400 x 3040

Come puoi vedere, stiamo usando 4 diverse dimensioni di immagine. Ti consiglio di includere la larghezza nel nome del file dell'immagine, poiché è molto più chiaro da comprendere.

300 x 380 - shirt_300w.jpg
600 x 760 - shirt_600w.jpg
1200 x 1520 - shirt_1200w.jpg
2400 x 3040 - shirt_2400w.jpg

Per scrivere il relativo markup nel nostro codice HTML, dobbiamo fare così:

<img
	src="shirt_300w.jpg"
	srcset="
		shirt_300w.jpg   300w,
		shirt_600w.jpg   600w,
		shirt_1200w.jpg 1200w,
		shirt_2400w.jpg 2400w
	"
	alt="Una bella camicia"
	sizes="(min-width: 1200px) 1200px,
         (min-width: 600px) 600px,
         300px"
/>

Con questo markup, the browser conosce lo spazio che l'immagine occuperà sullo schermo (tramite sizes) e tutte le sorgenti di immagini disponibili che abbiamo preparato per i nostri utenti (tramite srcset).

A questo punto, il browser sceglierà quale sorgente scaricare in base alle informazioni fornite e a quelle che conosce sull'utente, come la densità dello schermo, i file in cache, la velocità di connessione, ecc.

Supporto dei browser #

L'attributo srcset è supportato da tutti i browser tranne Internet Explorer. Fortunatamente, esiste un polyfill ufficiale che possiamo utilizzare per emulare il comportamento nativo sui browser legacy.

Immagini responsive? Il tag picture non serve

2015-12-21T00:00:00Z

Supponiamo di avere un layout di sito web responsive in cui le immagini sono dimensionate al 100% del loro contenitore, ma il contenitore non è sempre largo quanto la viewport. Dobbiamo per forza usare il tag picture o il tag img è sufficiente? Il tag img è in grado di farlo da solo, utilizzando i suoi attributi sizes e srcset. Ecco come.

Il layout delle immagini #

Le immagini nel layout hanno le seguenti larghezze:

Larghezza Viewport	Larghezza immagini	Larghezza contenitore
Da 0 a 767 px	1/2 del contenitore	100% senza padding
Da 768 px a 1023 px	1/3 del contenitore	100% con 30 px di padding
Da 1024 px a 1279 px	1/4 del contenitore	100% con 30 px di padding
Da 1280 px in su	1/4 del contenitore	1280 px con 30 px di padding

Unità utilizzabili nell'attributo `sizes` #

Quando usi il tag img, nell'attributo sizes puoi specificare quanto larghe mostrare le tue immagini in base alle diverse media query. E puoi farlo non solo usando l'unità di misura della larghezza della viewport (vw), come spesso si legge in giro, ma utilizzando qualsiasi valore di lunghezza e anche la funzione CSS calc(), utilissima quando si ha a che fare con padding o con la proprietà max-width del contenitore.

Larghezza Viewport	Larghezza immagini	Larghezza contenitore	Larghezza immagine in CSS
Da 0 a 767 px	1/2 del contenitore	100% senza padding	`50vw`
Da 768 px a 1023 px	1/3 del contenitore	100% con 30 px di padding	`calc(( 100vw - 60 px ) / 3)`
Da 1024 px a 1279 px	1/4 del contenitore	100% con 30 px di padding	`calc(( 100vw - 60 px ) / 4)`
Da 1280 px in su	1/4 del contenitore	1280 px con 30 px di padding	`305 px`

Vedi questa pen su CodePen che utilizza le media query e i CSS per specificare le larghezze di img, e quest'altra pen che specifica l'attributo sizes direttamente all'interno del tag img.

Ti senti confuso? Se hai bisogno di una spiegazione più approfondita, leggi l'articolo srcset and sizes di Eric Portis (in inglese), a mio parere il miglior articolo in assoluto sull'uso di img con srcset e sizes.

Calcolo delle dimensioni delle immagini ottimizzate in base a spaziatura, dispositivo e orientamento #

Se vogliamo che le nostre immagini siano ottimizzate per le risoluzioni più comuni, dobbiamo:

Definire quali sono le risoluzioni e le densità di schermo più diffuse
Decidere per quali risoluzioni/densità vogliamo ottimizzare
Calcolare quali saranno le dimensioni delle immagini a queste risoluzioni/densità
Ridimensionare le nostre immagini a quelle specifiche dimensioni
Scrivere il markup delle img nel codice HTML:
1. Elencare tutte le dimensioni delle immagini nell'attributo srcset, utilizzando il descrittore w
2. Elencare tutte le larghezze delle immagini nell'attributo sizes, come definito nella tabella precedente

Per individuare le risoluzioni dello schermo e decidere quali ottimizzare, puoi utilizzare qualsiasi strumento come Google Analytics per raccogliere informazioni sui tuoi utenti e sui dispositivi che utilizzano maggiormente.

Dopo alcuni calcoli, le dimensioni delle immagini ottenute sono state le seguenti:

Dispositivo e orientamento	Largh. schermo	Largh. img (css px)	Altez. img (css px)	Densità schermo	Largh. img (px)	Altez. img (px)
iPhone 4/5/5s	320	160	186	2	320	372
iPhone 6	375	187	217	2	374	435
iPhone 5/5s in orizzontale	568	284	330	2	568	660
iPhone 6 in orizzontale	667	333	387	2	666	774
iPad / mini	768	236	274	2	472	549
iPad / mini in orizzontale	1024	241	280	2	482	560
PC con larghezza da 1280px in su	1280	305	355	1	305	355
PC con larghezza 1280px e HiDPI	1280	305	355	2	610	709
PC con larghezza superiore a 1280px	1920	305	355	1	305	355

Passiamo al codice! #

Il codice del proof of concept (POC) che ho creato si trova su GitHub in questo repository, mentre la demo live è disponibile qui.

Markup con il tag picture #

<picture>
	<source media="(max-width: 320px)" srcset="http://placehold.it/320x372 2x" />
	<source media="(max-width: 375px)" srcset="http://placehold.it/374x435 2x" />
	<source media="(max-width: 568px)" srcset="http://placehold.it/568x660 2x" />
	<source media="(max-width: 667px)" srcset="http://placehold.it/666x774 2x" />
	<source media="(max-width: 768px)" srcset="http://placehold.it/472x549 2x" />
	<source
		media="(max-width: 1024px)"
		srcset="http://placehold.it/241x280 1x, http://placehold.it/482x560 2x"
	/>
	<source
		media="(min-width: 1280px)"
		srcset="http://placehold.it/305x355 1x, http://placehold.it/610x709 2x"
	/>
	<img src="http://placehold.it/305x355" alt="Immagine di un prodotto" />
</picture>

Markup con il tag img #

<img
	src="http://placehold.it/305x355"
	srcset="
		http://placehold.it/241x280 241w,
		http://placehold.it/305x355 305w,
		http://placehold.it/320x372 320w,
		http://placehold.it/374x435 374w,
		http://placehold.it/472x549 472w,
		http://placehold.it/482x560 482w,
		http://placehold.it/568x660 578w,
		http://placehold.it/610x709 610w,
		http://placehold.it/666x774 666w
	"
	sizes="(min-width: 1280px) 305px,
            (min-width: 1024px) calc((100vw - 60px) / 4),
            (min-width: 768px) calc((100vw - 60px) / 3),
            50vw"
	alt="Immagine di un prodotto"
/>

Conclusione #

Il markup con picture risulta essere molto più verboso, e non stiamo ancora supportando i display a densità singola sotto i 768px.
Il markup con img è più breve, meno ripetitivo e lascia che sia il browser a calcolare quale sia l'immagine migliore da caricare in base alla risoluzione E alla densità di pixel.

Non hai bisogno del tag picture.

Il motivo è che utilizzando il tag img dovrai scrivere molto meno codice per supportare molti più dispositivi e densità di schermo. Grazie alla possibilità di utilizzare la funzione CSS calc() all'interno dell'attributo sizes, possiamo effettuare calcoli complessi per stabilire l'immagine corretta da caricare anche in layout elaborati.

Nota bene: i tag picture e img sono paragonabili solo quando tutte le immagini mantengono le stesse proporzioni (aspect ratio) su tutte le media query. Se le proporzioni dell'immagine devono cambiare per adattarsi a quelle del dispositivo, il tag picture rimane l'unica strada percorribile.

Ciao!

Caricamento lazy di immagini responsive con srcset e LazyLoad

2015-04-20T00:00:00Z

Ora è possibile (sì, oggi stesso!) implementare il lazy loading (caricamento pigro) sulle immagini responsive, così da far sì che si adattino agli schermi degli utenti e mantenere veloce il nostro sito web. Evviva! \o/ In questo articolo vedremo quale markup dobbiamo scrivere e quali librerie JavaScript saranno necessarie per farlo.

Articolo obsoleto! 👀 #

Un momento! Stai leggendo una vecchia versione di questo articolo.

👉 Leggi l'aggiornamento del 2020

Lazy responsive... cosa? #

Le immagini responsive sono una tecnica che permette alle immagini del tuo sito web di adattarsi alla larghezza della viewport e alla densità dello schermo (1x, 2x - display retina, ecc.). Per capire come fare, puoi leggere Responsive images in practice (in inglese) e puoi trovare ulteriori informazioni sul sito web del responsive images community group.

Il lazy loading delle immagini è una tecnica per velocizzare il sito web evitando di caricare le immagini che l'utente potrebbe non vedere mai nella sua viewport, per poi caricarle solo quando vi fanno ingresso. Oltre alle prestazioni, questo ti permette anche di risparmiare larghezza di banda (e denaro, se utilizzi un servizio CDN a consumo per le tue immagini).

Implementazione #

Dai un'occhiata ai risultati che otterremo combinando queste tecniche.

Se apri il pannello Network dell'inspector del browser, noterai che le prime immagini vengono caricate "normalmente" dal browser al caricamento della pagina, mentre le altre vengono caricate via via che scorri verso il basso del documento.

Il markup #

Ecco il markup di cui avrai bisogno per caricare in modalità lazy un'immagine responsive.

<!-- Immagine caricata normalmente dal browser -->
<img
	srcset="
		img/41494516WM_10r_n_f.jpg 668w,
		img/41494516WM_10_n_f.jpg  334w,
		img/41494516WM_9r_n_f.jpg  446w,
		img/41494516WM_9_n_f.jpg   223w
	"
	sizes="(min-width: 361px) 50vw,
        (min-width: 481px) 33.333vw,
        (min-width: 769px) 25vw,
        (min-width: 1025px) 20vw,
        100vw"
/>

<!-- Immagine caricata in modalità lazy tramite JavaScript -->
<img
	data-srcset="img/41494516WM_10r_n_f.jpg 668w,
        img/41494516WM_10_n_f.jpg 334w,
        img/41494516WM_9r_n_f.jpg 446w,
        img/41494516WM_9_n_f.jpg 223w"
	sizes="(min-width: 361px) 50vw,
        (min-width: 481px) 33.333vw,
        (min-width: 769px) 25vw,
        (min-width: 1025px) 20vw,
        100vw"
/>

Nota che stiamo usando il tag HTML img e non picture. Quest'ultimo non è necessario perché in questo caso non stiamo modificando le proporzioni (ratio) dell'immagine.

Inclusione degli script #

Prima di tutto, abbiamo bisogno di una libreria per caricare le immagini lazy quando entrano nella viewport. Esistono diverse librerie per il caricamento lazy delle immagini, ma per avere il lazy loading di immagini responsive avrai bisogno di quella che ho scritto io: LazyLoad (leggi tutti i suoi vantaggi qui).

Inoltre, poiché non tutti i browser supportano le immagini responsive, dobbiamo includere la libreria picturefill di Filament Group, un polyfill che ci permette di colmare questa lacuna e far funzionare le immagini responsive su tutti i browser. Nota che questa libreria non sarà più necessaria quando tutti i browser che devi supportare offriranno il supporto nativo alle immagini responsive.

Quindi includeremo questi 2 script:

<script src="js/vendor/lazyload.min.js"></script>
<script src="js/vendor/picturefill.min.js"></script>

Inizializzazione dello script #

Quello che dobbiamo fare è creare una nuova istanza di LazyLoad per trasformare l'attributo data-srcset in un vero e proprio attributo srcset. Questo sarebbe sufficiente per i browser che supportano nativamente le immagini responsive ma, per gli altri, dobbiamo chiamare picturefill subito dopo che LazyLoad ha modificato il DOM.

Possiamo fare tutto ciò con questo comando:

/*var myLazyLoad = */ new LazyLoad({
	data_src: "src",
	data_srcset: "srcset",
	show_while_loading: true, // ideale per JPEG progressivi
	callback_set: function (img) {
		picturefill({
			elements: [img],
		});
	},
});

Per ulteriori riferimenti su ciò che abbiamo fatto qui, consulta la documentazione di LazyLoad.

Il foglio di stile #

Ci sono anche alcune funzionalità che possono essere ottenute solo tramite CSS. Dobbiamo:

Fare in modo che le immagini vuote occupino un certo spazio. Se non lo facciamo, tutte le immagini vuote collasseranno una sull'altra ed entreranno nella viewport contemporaneamente, vanificando i nostri sforzi di caricarle in modo lazy.
Evitare che le immagini vuote appaiano come immagini non trovate (broken)
(se abbiamo usato l'opzione show_while_loading, come nel nostro caso) Risolvere un'anomalia di Firefox che mostra l'icona dell'immagine interrotta durante il caricamento delle immagini

Possiamo fare tutto questo usando queste regole CSS:

/*
Fa in modo che il contenitore delle immagini occupi spazio
quando le immagini non sono ancora caricate.
Questo valore dipende dal tuo layout.
*/
.imageList li {
	min-height: 300px;
}
/*
Evita che le immagini vuote appaiano come interrotte (broken)
*/
img:not([src]):not([srcset]) {
	visibility: hidden;
}
/*
Risolve l'anomalia di Firefox durante il caricamento delle immagini
*/
@-moz-document url-prefix() {
	img:-moz-loading {
		visibility: hidden;
	}
}

Tutto qui! #

È stato molto facile, vero? Se non l'hai ancora fatto, dai un'occhiata alla demo di ciò che abbiamo realizzato.

Generazione avanzata di sprite con Compass (SASS)

2015-03-06T00:00:00Z

La creazione di sprite (spriting) è un modo per migliorare le prestazioni del tuo sito web posizionando molte immagini (o icone) all'interno di un'unica immagine più grande, in modo da effettuare una sola richiesta HTTP anziché molte. Ecco come puoi creare gli sprite utilizzando Compass.

Il metodo semplice #

Il modo più semplice per creare uno sprite con Compass richiede di importare una cartella di immagini nel progetto e poi generare una classe per ciascuno sprite. Puoi farlo utilizzando il seguente codice:

// Importazione dello strumento Compass richiesto
@import "compass/utilities/sprites";
// Importazione di tutte le immagini png all'interno della cartella flags
@import "flags/*.png";
// Genera una classe CSS per ogni sprite
@include all-flags-sprites

Esempio di output CSS:

.flags-it,
.flags-de,
.flags-fr {
  background: url('/images/flags-s34fe0604ab.png') no-repeat; }

.flags-it { background-position: 0 0; }
.flags-de { background-position: 0 -32px; }
.flags-fr { background-position: 0 -64px; }

Questo potrebbe essere sufficiente per le tue esigenze... ma tu vuoi di più, vero?

Il metodo avanzato #

Tralasciando tutti gli altri modi in cui è possibile generare gli sprite con Compass, ho scoperto che se devi fare quanto segue:

Generare dimensioni del box uguali a quelle dello sprite
Usare un offset all'interno del box
Spaziare gli sprite all'interno della mappa degli sprite (sprite map)
Gestire display con densità 1x, 2x, 3x
Ottimizzare il tempo di generazione degli sprite

L'unico modo per fare spriting con Compass è creare i tuoi mixin personali che utilizzino sotto il cofano i mixin di base di Compass.

Struttura delle immagini e delle cartelle #

Per avere le immagini a densità singola, doppia e magari tripla, dobbiamo fornire le immagini in dimensioni 1x, 2x e magari 3x.

Quindi, supponendo di voler creare una mappa di sprite contenente delle bandiere (flags), puoi avere le seguenti cartelle nella cartella delle immagini:

flagsSprite1x - immagini delle bandiere a densità singola
flagsSprite2x - immagini delle bandiere a densità doppia
flagsSprite3x - ...densità tripla

E se volessimo creare anche una mappa di sprite per delle icone (icons), dovremmo creare le cartelle:

iconsSprite1x
- ...
iconsSprite2x
- ...
iconsSprite3x
- ...

Ora diamo un'occhiata ai partial SASS da creare.

Partial SASS #

Per garantire la massima flessibilità e il minor tempo di compilazione (build), ti suggerisco di utilizzare la seguente struttura:

_variables.scss - tutte le tue variabili
_mixins.scss - tutti i tuoi mixin
un file partial per ogni set di immagini:
- _flagsSprite.scss - bandiere
- _iconsSprite.scss - icone
- ...

Vediamo cosa inserire nei nostri partial, uno per uno.

_mixins.scss #

Ecco alcuni mixin che potresti voler includere nel tuo file dei mixin. Trovi la spiegazione del loro funzionamento direttamente nei commenti del codice.

/*
Rende possibile l'utilizzo di uno sprite a densità n-pla
Adatta automaticamente background-size e offset quando $multiplier è maggiore di 1
Consente di utilizzare la generazione automatica delle dimensioni, che viene adattata automaticamente quando $multiplier è maggiore di 1

Parametri richiesti:
- $sprite - il nome dello sprite
- $spriteMap - la variabile spriteMap
- $spriteUrl - l'url della mappa degli sprite dello sprite

Parametri opzionali:
- $multiplier (1) - la densità dello sprite (1 per densità singola, 2 per retina, 3, ecc.)
- $renderSize (false) - indica al mixin di impostare width e height del box contenente lo sprite
- $offsetX (0) - l'offset orizzontale (px) per l'immagine nel box
- $offsetY (0) - l'offset verticale (px) per l'immagine nel box
*/
@mixin useNxSprite($sprite, $spriteMap, $spriteUrl, $multiplier: 1, $renderSize: false, $offsetX: 0, $offsetY: 0) {
  $spritePosition: sprite-position($spriteMap, $sprite, $offsetX * $multiplier, $offsetY * $multiplier);
  background: transparent $spriteUrl no-repeat nth($spritePosition, 1) / $multiplier nth($spritePosition, 2) / $multiplier;
  @if ($multiplier > 1) {
    background-size: (image-width(sprite-path($spriteMap)) / $multiplier) (image-height(sprite-path($spriteMap)) / $multiplier);
  }
  @if ($renderSize) {
    height: image-height(sprite-file($spriteMap, $sprite)) / $multiplier;
    width: image-width(sprite-file($spriteMap, $sprite)) / $multiplier;
  }
}

/*
Mixin di utilità per utilizzare sprite a singola e doppia densità, con media query per la doppia densità inclusa

Parametri richiesti:
- $sprite - il nome dello sprite
- $sprite1xMap - la variabile spriteMap per gli sprite 1x
- $sprite2xMap - la variabile spriteMap per gli sprite 2x
- $sprite1xUrl - l'url della mappa degli sprite per gli sprite 1x
- $sprite2xUrl - l'url della mappa degli sprite per gli sprite 2x

Parametri opzionali:
- $renderSize (false) - indica al mixin di impostare width e height del box contenente lo sprite
- $offsetX (0) - l'offset orizzontale (px) per l'immagine nel box
- $offsetY (0) - l'offset verticale (px) per l'immagine nel box
*/
@mixin use1x2xSprite($sprite, $sprite1xMap, $sprite2xMap, $sprite1xUrl, $sprite2xUrl, $renderSize: false, $offsetX: 0, $offsetY: 0) {
  @include useNxSprite($sprite, $sprite1xMap, $sprite1xUrl, 1, $renderSize, $offsetX, $offsetY);
  @media (-webkit-min-device-pixel-ratio: 1.5), (min-resolution: 144dpi) {
    @include useNxSprite($sprite, $sprite2xMap, $sprite2xUrl, 2, $renderSize, $offsetX, $offsetY);
  }
}

_variables.scss #

Questo è il file in cui definisci tutte le variabili del tuo sito, che utilizzerai in tutti i tuoi file scss.

Qui dovresti definire la spaziatura tra gli sprite nelle immagini della mappa degli sprite.

// Spaziatura generica (a 1x) per gli sprite
$spacing-sprites-generic: 10px;

_flagsSprite.scss #

Questo è il file in cui definisci le variabili e i mixin per gli sprite delle bandiere.

Ti suggerisco di importare (@import) il file _flagsSprite.scss solo nei file che richiedono effettivamente gli sprite delle bandiere. Questo velocizza molto il tempo di build, evitando frequenti controlli delle immagini sul file system.

// MAPPE e URL per flagsSprite
$flagsSprite1xMap: sprite-map("flagsSprite1x/*.png", $spacing: $spacing-sprites-generic);
$flagsSprite2xMap: sprite-map("flagsSprite2x/*.png", $spacing: $spacing-sprites-generic * 2);
$flagsSprite1xUrl: sprite-url($flagsSprite1xMap);
$flagsSprite2xUrl: sprite-url($flagsSprite2xMap);

// mixin flagsSprite
@mixin flagsSprite($spriteName, $renderSize: false, $offsetX: 0, $offsetY: 0) {
    @include use1x2xSprite($spriteName, $flagsSprite1xMap, $flagsSprite2xMap, $flagsSprite1xUrl, $flagsSprite2xUrl, $renderSize, $offsetX, $offsetY);
}

style.scss - uso standard #

Se non hai bisogno di spazio attorno allo sprite e non vuoi che Compass generi le dimensioni del box per te, puoi semplicemente fare così.

@import "compass/utilities/sprites";
@import "_variables";
@import "_flagsSprite";

// Uso semplice
.exampleSimple {
    @include flagsSprite(italy);
}

Questo produrrà quanto segue:

.exampleSimple {
  background: transparent url('../img/flagsSprite1x-s479625030c.png') no-repeat 0 -882px;
}
@media (-webkit-min-device-pixel-ratio: 1.5), (min-resolution: 144dpi) {
  .exampleSimple {
    background: transparent url('../img/flagsSprite2x-s9a855cf705.png') no-repeat 0 -882px;
    background-size: 32px 2048px;
  }
}

style.scss - con generazione delle dimensioni del box #

Se vuoi che Compass generi le dimensioni del box per te, devi fare come segue.

@import "compass/utilities/sprites";
@import "_variables";
@import "_flagsSprite";

.exampleWithDimensions {
    @include flagsSprite(italy, true);
}

Questo produrrà quanto segue:

.exampleWithDimensions {
  background: transparent url('../img/flagsSprite1x-s479625030c.png') no-repeat 0 -882px;
  height: 32px;
  width: 32px;
}
@media (-webkit-min-device-pixel-ratio: 1.5), (min-resolution: 144dpi) {
  .exampleWithDimensions {
    background: transparent url('../img/flagsSprite2x-s9a855cf705.png') no-repeat 0 -882px;
    background-size: 32px 2048px;
    height: 32px;
    width: 32px;
  }
}

style.scss - con gestione dell'offset #

Se non vuoi che Compass generi le dimensioni del box per te, ma desideri utilizzare un offset all'interno del box, devi fare come segue.

@import "compass/utilities/sprites";
@import "_variables";
@import "_flagsSprite";

.exampleWithPadding {
    @include flagsSprite(italy, false, 10, 10);
    width: 52px; height: 52px;
}

Questo produrrà quanto segue:

.exampleWithPadding {
  background: transparent url('../img/flagsSprite1x-s479625030c.png') no-repeat 10px -872px;
  width: 52px;
  height: 52px;
}
@media (-webkit-min-device-pixel-ratio: 1.5), (min-resolution: 144dpi) {
  .exampleWithPadding {
    background: transparent url('../img/flagsSprite2x-s9a855cf705.png') no-repeat 10px -872px;
    background-size: 32px 2048px;
  }
}

Tutto qui #

La generazione automatica di sprite tramite Compass considerando tutti i fattori può essere piuttosto complessa, ma seguendo questa guida sarà semplice e anche più facile da mantenere.

Se hai riscontrato problemi con questo post, per favore mandami un tweet e provvederò a risolverli.

Un nuovo LazyLoad per migliorare le prestazioni del tuo sito web

2014-11-20T00:00:00Z

Negli ultimi giorni ho lavorato all'ottimizzazione delle prestazioni dei siti web e mi sono reso conto che non c'è modo di sfruttare il formato di immagine JPEG progressivo sui siti web se si utilizza jQuery_lazyload. Quindi, dopo aver inviato una pull request al suo autore, ho deciso di scrivere il mio lazy load personale, che si è rivelato migliore perché:

è 6 volte più veloce
consente di caricare in modalità lazy le immagini responsive
non dipende da jQuery
supporta al meglio il formato JPEG progressivo

Maggiori informazioni sul repository GitHub.

Animazione di caricamento "loading" rotante in solo CSS 3

2012-10-03T00:00:00Z

Abbiamo usato immagini GIF per creare animazioni per anni, ma non sono adatte ad essere utilizzate sopra sfumature o immagini (niente canale alfa, niente anti-aliasing) di cui i siti web moderni sono pieni. Esistono molte soluzioni alternative per animare invece immagini PNG, ma...

Voglio mostrarti una soluzione che ho trovato per creare un'animazione di caricamento ("loading") da zero, utilizzando solo CSS 3, senza immagini.

Prima i risultati #

Vedi la Pen CSS 3 only spinning circle quarter - loading animation di Andrea Verlicchi (@verlok) su CodePen.

Cosa succede qui #

Il fulcro di questo metodo consiste nel disegnare un quarto di cerchio e animarlo. Continua a leggere per scoprire i passaggi passo-passo per farlo.

1. Creare un cerchio #

<!-- Cerchio interno mascherato -->
<div class="maskedCircle"></div>

/* Cerchio rotante (cerchio interno) */
.loading .maskedCircle {
	width: 20px;
	height: 20px;
	border-radius: 12px;
	border: 3px solid white;
}

2. Mascherare un quarto del cerchio #

<!-- Maschera del quarto di cerchio -->
<div class="mask">
    <!-- Cerchio interno mascherato -->
    <div class="maskedCircle"></div>
</div>

/* Maschera del cerchio rotante */
.loading .mask {
	width: 12px;
	height: 12px;
	overflow: hidden;
}

3. Far ruotare entrambi #

<!-- Facciamo ruotare questo div -->
<div class="spinner">
	<!-- Maschera del quarto di cerchio -->
	<div class="mask">
		<!-- Cerchio interno mascherato -->
		<div class="maskedCircle"></div>
	</div>
</div>

/* Keyframe dell'animazione */
@keyframes spin {
	from { transform: rotate(0deg); }
	to { transform: rotate(360deg); }
}

/* Spinner */
.loading .spinner {
	position: absolute;
	left: 1px;
	top: 1px;
	width: 26px;
	height: 26px;
	animation: spin 1s infinite linear;
}

4. Avvolgere tutto in un contenitore "loading", che sarà centrato rispetto al suo genitore #

<!-- Contenitore dell'animazione di caricamento -->
<div class="loading">
	<!-- Facciamo ruotare questo div -->
	<div class="spinner">
		<!-- Maschera del quarto di cerchio -->
		<div class="mask">
			<!-- Cerchio interno mascherato -->
			<div class="maskedCircle"></div>
		</div>
	</div>
</div>

/* Contenitore dell'animazione di caricamento */
.loading {
	position: absolute;
	top: 50%;
	left: 50%;
	width: 28px;
	height: 28px;
	margin: -14px 0 0 -14px;
}

Codice HTML e CSS risultante: #

<!-- Contenitore dell'animazione di caricamento -->
<div class="loading">
	<!-- Facciamo ruotare questo div -->
	<div class="spinner">
		<!-- Maschera del quarto di cerchio -->
		<div class="mask">
			<!-- Cerchio interno mascherato -->
			<div class="maskedCircle"></div>
		</div>
	</div>
</div>

/* Keyframe dell'animazione - devi aggiungere i prefissi */
@keyframes spin {
	from { transform: rotate(0deg); }
	to { transform: rotate(360deg); }
}

/* Contenitore dell'animazione di caricamento */
.loading {
	position: absolute;
	top: 50%;
	left: 50%;
	width: 28px;
	height: 28px;
	margin: -14px 0 0 -14px;
}

/* Cerchio rotante (cerchio interno) */
.loading .maskedCircle {
	width: 20px;
	height: 20px;
	border-radius: 12px;
	border: 3px solid white;
}

/* Maschera del cerchio rotante */
.loading .mask {
	width: 12px;
	height: 12px;
	overflow: hidden;
}

/* Spinner */
.loading .spinner {
	position: absolute;
	left: 1px;
	top: 1px;
	width: 26px;
	height: 26px;
	animation: spin 1s infinite linear;
}

Non è fantastico?

Funziona perfettamente su tutti i browser desktop come:

Internet Explorer 10+
Edge
Chrome
Firefox
Safari
Opera

e anche per tutti i principali browser mobile:

Safari Mobile
Chrome Mobile
Firefox Mobile
Opera Mobile
Internet Explorer Mobile (solo Windows Phone 8)

Al momento, Internet Explorer su Windows Phone 7 non animerà la figura.

I fallback? #

Hai bisogno di un fallback per vedere l'animazione nei browser più vecchi? Se hai letto fin qui, probabilmente sì.

Sebbene il fallback non sia lo scopo di questo articolo, diciamo che la soluzione migliore sarebbe preparare uno sprite con tutti i fotogrammi (frame) dell'animazione a una distanza costante l'uno dall'altro, usare lo sprite come sfondo di un elemento DOM e animare lo sfondo con Javascript.

Andrea Verlicchi

Claude vs Gemini, i miei casi d'uso

Claude in Claude Desktop #

Claude in Claude Code #

Gemini in Antigravity / Antigravity IDE #

Gemini (web / desktop) – Account Personale #

Gemini (web / desktop) – Account Aziendale #

Gemini (web / desktop) – Entrambi gli account #

Dovremmo smettere di usare la parola "Responsive" per il design?

La definizione mobile di "adaptive" (Android e iOS) #

La definizione di "responsiveness" nelle performance web #

La collisione terminologica #

Una proposta: dividere la terminologia #

Talk: "Ehi Gemini, sistema il CSS!" al CSS Day Bologna

Guarda il video #

Slide #

Google Antigravity 2 & Gemini 3.5 Flash: questa accoppiata IA ha cambiato il mio flusso di sviluppo... di nuovo

Flussi di lavoro multi-progetto senza interruzioni #

Sotto il cofano: Gemini 3.5 Flash è una bomba #

Cosa stai aspettando? #

Il mio sogno di un formato d'immagine contenitore: un appello alla web community

Il TL;DR di Andy #

Ho un sogno #

Un appello alla community #

Talk: Migliorare la reattività del web al Web Day 2026, Milano

Rifattorizziamo i bias di genere, un commit alla volta

Bologna Front-end 🇮🇹 #

DevRomagna 🇮🇹 #

GitBar Podcast: Non toccate quel tag!

Guarda / Ascolta #

Talk: Gemini + Chrome: Oltre la Chat, Bologna JS Meetup

Video del talk: "Ehi Gemini, sistema il CSS!", Bologna Front-end #58

Guarda il video #

Google Antigravity: il nuovo IDE che abbraccia l'IA agentica

Imparare le basi di Google Antigravity #

Google Antigravity: il nuovo miglior editor di IA? #

Migliorare la reattività del web - Ottimizzazioni dell'interattività da casi reali

Il gestore degli appunti di macOS che stavi aspettando, ora nativo in macOS 26 Tahoe

Abilitare la cronologia degli appunti #

Usare la cronologia degli appunti #

Alcune cose da notare #

Video del talk: "Debugging and Optimizing Interaction to Next Paint (INP) for a Smoother Web", Meetup Performance Observer

Presentazione di yieldy-for-loop: un pacchetto npm per mantenere i loop non bloccanti (e la UI fluida)

Contesto #

Cosa fa #

Installazione #

Esempio di utilizzo #

Come funziona #

Perché ne avete bisogno #

Prossimi passi #

Ringraziamenti #

Conclusione #

Ottimizzare l'uso degli SVG per le prestazioni web: una guida completa

1. SVG inline #

2. Il tag <img> #

3. Immagini di sfondo CSS #

4. Sprite SVG e tag <use> #

Scegliere il metodo in base al caso d'uso #

Considerazioni sulle prestazioni #

Stile e interattività #

Accessibilità e semantica #

Evitare tecniche superate: #

Conclusione #

Approfondimenti #

Video del talk: "How I made the web more responsive — real-world case studies of INP optimizations", conferenza We Love Speed 2024

Il web è morto, lunga vita al web (repost)

La mia esperienza a performance.now() 2024: la principale conferenza sulla web performance in Europa

Contenuti e speaker eccezionali #

Connettersi con professionisti affini #

Contribuire all'help desk sponsorizzato da Google #

Partecipare all'intervista live di Henri Helvetica su YouTube #

Pre-evento: Performance.Sync di Mozilla #

Spunti raccolti e approfondimenti #

Riflessioni sull'esperienza #

Come usare Google Meet con due schermi: separare i contenuti condivisi e i volti dei partecipanti

Guida passo-passo all'uso della modalità Companion #

Perché questa configurazione funziona #

Considerazioni finali #

Modalità a schermo intero reale per i contenuti condivisi su Google Meet

Il dibattito sul lavoro da remoto: la mia visione per trovare un equilibrio

2. Il tag `<img>` #

4. Sprite SVG e tag `<use>` #

Un ciclo infinito con `while(true)` #

Un ciclo infinito con `setTimeout()` #

`requestAnimationFrame` #

Un ciclo infinito con `Promise.resolve()` #