Andrea Verlicchi

Claude vs Gemini: My Use Cases

2026-07-27T00:00:00Z

There's a lot of hype and noise out there regarding Claude and Anthropic, especially after the announcement of Fable 5 and lately Opus 5. I definitely use Claude, I'm not saying I don't! But for many things, I still prefer Gemini 3.6 Flash.

The reason is simple: although my company has fully adopted Claude and strongly encourages its use, being in close contact with Google and other Google developers through the GDE (Google Developer Experts) program means I hear enthusiastic feedback about Gemini as well. So I want to keep testing and using both.

I'm not saying they are completely equivalent for me, but there are specific use cases where I prefer one over the other. Here is how I split them in my daily workflow:

Claude or Gemini? The speech bubbles represent my daily AI choices.

Claude in Claude Desktop #

Complex multi-tool tasks: Long tasks that involve reading and writing across multiple workplace tools, including company Slack, Hex, or other integrations.

Claude in Claude Code #

Complex code development: For heavy coding tasks (the ones requiring a good amount of reasoning, like major release refactoring), I rely on Fable 5, Opus 4.8, or Sonnet 5. Often these tasks involve direct integrations via CLI with GitLab (glab), Google Cloud (gcloud), or our internal MCP servers.
Git troubleshooting (with Haiku): Getting out of tricky git situations (like moving recent commits mistakenly pushed to main over to a feature branch, or force-pushing the current feature branch to staging overriding what was already there — don't judge me: I almost never use git from the command line, I'm lazy!).

Gemini in Antigravity / Antigravity IDE #

Medium-complexity coding tasks: For medium-to-large feature implementations, I use Gemini 3.6 Flash (high).
DevTools & Performance Analysis: For tasks involving DevTools for Agents and deep web performance profiling, I use Gemini 3.6 Flash (medium).
Blog Maintenance & Enhancements: For various work on this blog (e.g., recently translating it entirely into Italian, creating custom skills to write new posts, etc.), I use Gemini 3.6 Flash (medium/high). Spoiler: this very blog post, including its cover image, was generated right here using Antigravity and Gemini 3.6 Flash (Medium)!

Gemini (web / desktop) – Personal Account #

For questions about life, the universe, and everything (the answer to which is always 42):

Kitten care: How to welcome two kitten puppies when you've never had pets before (a long chat still active after a month!).
Diet & Nutrition: Advice on diet and meal planning (monthly chats generated using Gems as blueprint, for over a year).
Home projects: Correctly sizing a photovoltaic solar system (a pinned chat I'll need very soon).

Gemini (web / desktop) – Work Account #

For strictly work-related queries:

Code analysis: Analyzing minified JS libraries.
SQL optimization: Comparing complexity and execution cost of SQL queries.
Error debugging: Analyzing unclear Python or JavaScript stack traces and errors.
Slack workflows: Advanced Slack automation, app setup, and workflows.

Gemini (web / desktop) – Both Accounts #

Cross-cutting use cases where Gemini is my go-to choice across both personal and work profiles:

Persistent web searches: Web searches whose results I want saved in an accessible history, rather than lost forever like tears in rain.
Document & File analysis: Uploading files to extract structured information.
Tech questions & setup: Resolving technical doubts, configuring tools, making services talk to each other, or understanding AI model internals.
Brainstorming & Presentations: Generating ideas and structuring content for presentations.

In conclusion: there is no single absolute "winner" for every need. Experimenting with both lets me leverage the best of both ecosystems and choose the right tool for each specific task!

Should we stop using the word "Responsive" for design?

2026-07-07T00:00:00Z

Back in 2010, Ethan Marcotte coined the term Responsive Web Design. Since then, we've used "responsive" to describe a website that adapts its layout to the viewport size. Fluid grids, flexible images, media queries.

Should we use "adaptive" for layouts and "responsive" for performance?

For a while, we tried to separate it from "adaptive" design. Back then, "adaptive" websites had a bit of a bad reputation because they usually relied on server-side device detection and user-agent sniffing to serve completely different HTML and CSS to the browser (remember Aaron Gustafson's book?). Because UA sniffing was brittle and prone to breaking, the web community wanted to distance itself from it. Ethan's responsive model served the exact same code to everyone, letting the browser do the work. "Responsive" won the vocabulary war, and "adaptive" became a word associated with outdated, server-detected layouts.

But fast-forward to today, and these terms have split in ways that are causing real confusion.

The mobile definition of "adaptive" (Android and iOS) #

If you look at modern mobile app development — both Android and iOS — the word "adaptive" is the standard.

Google heavily uses it for Android app design. With the rise of foldable phones and tablets, apps can't just stretch to fit. They need to completely restructure. In their guide on adaptive layouts, the focus is entirely on "adaptive" layouts (changing layout structures based on breakpoints and fold states), while "responsive" concepts (like fluid sizing) are just seen as a foundation.

Apple follows a similar logic. In their Human Interface Guidelines for Layout, they frame layout adjustments around the concept of "Adaptability" rather than "Responsiveness." They guide developers to build interfaces that adapt seamlessly to different devices, screen sizes, and orientations using size classes and adaptive structures.

So, in the mobile app world, adapting to screen sizes is consistently called adaptive design.

The web performance definition of "responsiveness" #

At the same time, in the web performance space — where I spend a lot of time — the word "responsive" has taken on a completely different meaning.

When performance engineers say they want to make a page "responsive," they aren’t talking about viewports or media queries at all. They are talking about interactivity. Specifically, how fast the browser reacts to user inputs.

With Google's Interaction to Next Paint (INP) metric, "responsiveness" is measured in milliseconds. If a user taps a button and the page freezes for 300ms, the website has poor responsiveness.

The terminology collision #

This has created a confusing mess.

If a product manager says: "We need to make this website more responsive." What do they mean?

Do we need to adjust our CSS media queries for foldables and tablets?
Or do we need to break up long JavaScript tasks to improve our INP?

We are using the exact same word to mean "adapts to screen size" and "reacts fast to user input."

And this confusion is only going to grow. If you talk to developers who just entered the industry, or if you ask an AI coding agent to "make this UI more responsive", what will they actually do? Will they start writing @media rules in CSS, or will they fire up Chrome DevTools to profile main thread blocking times? Honestly, either path is a valid interpretation of the word.

A proposal: Split the terminology #

Maybe it's time to let the word "responsive" go, at least when we talk about screen sizes.

What if we started using "adaptive" for everything related to layout adjustment (both on the web and in native apps), and reserved "responsive" purely for web performance?

Under this model:

An adaptive website or app is one that adjusts its layout to the viewport (mobile, desktop, foldable).
A responsive website or app is one that is fast to respond to user interactions (low INP, no frozen main thread).

To put it in simple terms, if I had to explain this concept to my mother, I would say that a layout adapts to screen sizes, not that it "responds" to them. It is just a much more natural way to describe it.

It feels cleaner, more logical, and it solves the vocabulary overlap. But is the web community ready to drop Ethan Marcotte's 2010 definition? Or is "responsive design" too deeply engraved in our brains?

I'm curious to hear what you think. Does this distinction make sense, or is it too late to change? Feel free to reach out and let me know!

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

2026-06-11T00:00:00Z

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

On Thursday, June 11th, 2026, I had the pleasure of presenting at the CSS Day conference in Bologna.

Have you ever wondered how much time we waste every day right-clicking to "Inspect", changing the viewport size 50 times, or hunting down that one CSS rule overriding our styles? Traditional AI programming assistants are outstanding, but they are "blind" to the live browser environment: they cannot see the in-memory DOM, network traffic, or console errors.

In this talk from CSS Day, we explore Chrome DevTools for Agents (also known as DTA), a tool released in version 1.0 in May during Google I/O. Thanks to the Model Context Protocol (MCP), this tool exposes the native capabilities of DevTools directly to AI agents (such as Gemini, Claude Code, Cursor, or Antigravity).

The result? The AI can navigate, inspect stylesheets, fill out forms, and perform real debugging on our behalf.

Watch the video #

Slides #

You can download or view the presentation slides here: 🔗 Download presentation slides (PDF)

Google Antigravity 2 & Gemini 3.5 Flash: this AI duo changed my dev workflow... again

2026-05-22T00:00:00Z

It has only been a few days since I started using it, but I’m already incredibly enthusiastic. The speed, the precision, the planning process, and the final results obtained are simply outstanding.

Google Antigravity 2 is here, and it's a complete game-changer.

Let me take a step back. Antigravity 1 was essentially a VS Code shell with a built-in chat. It felt quite similar to the VS Code + Copilot setup, but with a highly interesting twist: Planning Mode. Before executing any changes, the chat would pause, reflect back what it understood, show you a detailed step-by-step implementation plan, and ask for explicit confirmation. It was very similar to Claude's planning mode but packaged in a much cleaner, easier-to-read, and commentable user interface.

With Antigravity 2, they’ve taken a bold step. They’ve completely removed the code editor mode (or they’ve hidden it so well that I haven't found it yet!). Instead, it is a pure, distraction-free chat interface focused entirely on the agentic workflow, while keeping that wonderfully convenient Planning Mode from version 1 completely intact.

Seamless Multi-Project Workflows #

What makes Antigravity 2 so powerful is how it operates in the background:

Multi-Project Support: It runs seamlessly across your active workspace projects.
Parallel Chats: Each project can have multiple concurrent chats running in parallel.
Git Worktrees: Each independent chat can run directly on your local branch or inside its own dedicated Git worktree, allowing the agent to write code and run builds in isolation without locking up your main working tree.

I recommend using it side-by-side with your favorite traditional IDE. In my day-to-day work, I constantly jump between Antigravity 2 and JetBrains PyCharm. I use Antigravity to run agent tasks, plan refactoring, and modify code, and then I switch over to PyCharm to run, test, and handle everything else just like I did before. It’s the perfect hybrid workspace.

Under the Hood: Gemini 3.5 Flash is Fire #

Antigravity 2 supports both Gemini 3.5 and Claude. If you have a Google account, you get a generous free tier of Gemini 3.5 included right out of the box, which I highly recommend trying. If you prefer Claude, you can simply connect your Anthropic account and go.

I’ve personally tested almost every major model out there—from OpenAI's o3, to Gemini 2.5 Pro, to Claude Sonnet 3.7 and Opus 4.6. Over time, I’ve consistently found myself appreciating the quality and relevance of Gemini's answers the most.

And Gemini 3.5 Flash? It is absolute fire (or as we say in Italy, una bomba). It is blisteringly fast, incredibly accurate, and highly intelligent. You really have to try it yourself to understand the speed difference.

What Are You Waiting For? #

By the time you've finished reading this paragraph, you could have already downloaded it. And in the time it would take you to write a reply to this post, you could write your first prompt and experience it firsthand.

If you are a developer looking to supercharge your productivity, give the Antigravity 2 and Gemini 3.5 Flash duo a spin. I think you won't look back. 😊

My dream of a container image format: a call to the web community

2026-04-29T00:00:00Z

A few days ago, Mat Marquis wrote a great article on the end of responsive images, explaining how the now widely-supported sizes="auto" attribute lets browsers figure out the rendered size of lazy-loaded images on their own, removing the need to hand-craft the sizes attribute for most images.

Reading it revived a dream I've been carrying for years: an image format that would let us write a radically simpler <img> tag — simpler than even sizes="auto" allows. I'll get to it below. But first, a quick recap of Andy's piece for context.

A dream image format: one file, all the sizes you need.

Andy's TL;DR #

For lazy-loaded images (most images on a page), we can drop the hand-crafted sizes and let the browser do the work:

<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"
/>

For "hero" images — the ones above the fold, candidates to become the page's LCP — we still need to be meticulous with upfront sizing via 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"
/>

So sizes can mostly go away. But we're still left with that long srcset listing every variant. And that's where my old dream comes back in.

I have a dream #

For years I've been dreaming about a container image format — a single file containing every resolution of an image inside it. Think of it as a bundled folder of images, packaged as one.

With a format like that, the <img> tag, at least for lazy images, could be drastically simplified. Something like this:

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

No more complex srcset with a comma-separated list of widths. The browser would open the file, see which resolutions are available inside, and download only the bytes it needs for the size it has to render.

The <img> tag, finally simple again.

A call to the community #

Andy's article shows that the platform can absorb a lot of the complexity we've been carrying around in our markup. I'd love to see us go even further.

To the web standards folks, image format authors, and browser engineers reading this: is a container image format something we could actually build? HTTP range requests already allow browsers to fetch segments of files. Container formats already exist in other domains. The building blocks are all there.

I've been holding this dream for a long time. Could we finally make it real?

Talk: Enhancing Web Responsiveness at Web Day 2026, Milan

2026-04-01T00:00:00Z

Andrea Verlicchi on stage at Web Day 2026, Milan

I had the chance to speak at Web Day 2026, the 9th edition of the conference organized by Improove in Milan, held on March 30th, 2026 at Talent Garden Calabiana.

My talk was "Enhancing Web Responsiveness — A practical guide to debugging and avoiding slow interactions", and it was all about Interaction to Next Paint (INP), the Core Web Vital metric that measures how responsive a page is to user interactions.

Andrea Verlicchi on stage at Web Day 2026, Milan

I shared real-world case studies showing how to identify and fix poor INP, and practical techniques you can apply right away to make your websites feel snappier. If you've ever wondered why a button click feels sluggish or a form takes forever to respond, this one was for you.

🔗 Talk page on the Web Day website

Refactoring Gender Bias, One Commit at a Time

2026-03-27T00:00:00Z

I recently had the pleasure of co-presenting with Giulia Naponiello, Senior Software Engineer at Red Hat, about gender bias in technology at two local meetups. The talk, titled "Rifattorizziamo i bias di genere, un commit alla volta" (Refactoring Gender Bias, One Commit at a Time), explored how unconscious biases subtly manifest in tech workplaces.

We shared personal stories and examined how bias shows up in everyday situations—from code review language to hiring assessments, and from the recognition of technical authority to team dynamics. The goal wasn't to point fingers, but to shine a light on the "cultural bugs" we all carry and suggest ways to fix them. Think of it as refactoring: same codebase, better outcomes. 🐛➡️✅

Bologna Front-end 🇮🇹 #

The cover slide of our talk.

On Tuesday, March 10th, 2026, we presented at the 61st episode of Bologna Front-end at the Granata venue in Bologna.

🔗 Event page

DevRomagna 🇮🇹 #

On Tuesday, March 17th, 2026, we brought the same talk to DevRomagna at Gellify in Imola.

🔗 Event page

GitBar Podcast: Non toccate quel tag!

2026-03-19T00:00:00Z

GitBar Podcast - Episode 228

I recently had the pleasure of being a guest on GitBar, the Italian podcast by Mauro "Brainrepo" Murru. In episode 228, titled "Non toccate quel tag!" (Don't Touch That Tag!), we had a long and fun conversation about web performance — from Core Web Vitals to image optimization, from the infamous Interaction to Next Paint to the silent damage of Google Tag Manager.

We also touched on some nostalgic topics like Flash, Dreamweaver, and MySpace, and talked about how AI tools like Claude are starting to help with performance analysis. It was a blast!

Watch / Listen #

You can also find the episode on the GitBar website.

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

2026-02-25T00:00:00Z

Bologna JS Meetup

On Wednesday, February 25th, 2026, I presented at the Bologna JS Meetup at Spazio01 Coworking in Bologna.

The talk, titled "Gemini + Chrome: Oltre la Chat. Usare l'AI per controllare il browser" (Gemini + Chrome: Beyond the Chat. Using AI to control the browser), was a demo of the Chrome DevTools MCP Server — showing how to connect AI with Chrome DevTools through the Model Context Protocol.

I showed practical examples of how to:

Read the DOM in real-time and manipulate web pages
Run visual smoke tests across different viewports
Simulate complex user interactions for end-to-end testing
Intercept network requests and analyze performance metrics
Identify performance bottlenecks

🔗 Event page

Talk video: "Ehi Gemini, sistema il CSS!", Bologna Front-end #58

2025-12-09T00:00:00Z

Bologna Front-end #58

On Tuesday, December 9th, 2025, I presented at the 58th episode of Bologna Front-end at Granata venue in Bologna.

The talk, titled "Ehi Gemini, sistema il CSS!" (Hey Gemini, fix the CSS!), was a live demo of the Chrome DevTools MCP Server — a tool that lets you control Chrome DevTools through the Model Context Protocol (MCP), using natural language commands from your terminal.

I showed how to leverage it to:

Run accessibility audits
Debug complex CSS layouts
Simulate different network conditions
Test custom viewports for responsive design

All through natural language, without leaving the terminal. Pretty neat stuff!

Watch #

🔗 Event page

Google Antigravity: The New IDE That Embraces Agentic AI

2025-11-24T00:00:00Z

There’s a new IDE from Google that embraces agentic AI and leverages Gemini 3: Google Antigravity.

With Gemini 3's advanced reasoning, tooling, and autonomous programming capabilities, Google Antigravity transforms AI assistance from a tool in a developer's toolkit to an active partner. While the core of Google Antigravity is a familiar AI IDE experience, its agents have been elevated to a dedicated interface and gained direct access to the editor, terminal, and browser. Now agents can autonomously plan and execute complex, end-to-end software tasks on your behalf, while validating their own code.

On Friday, my workmate Brian and I put it to work on some complex task in the development of the project we're working on, with the Gemini 3 model, and we were quite impressed by it.

What I love about Antigravity is that it handles planning by producing two text artifacts, just like a Tech Lead would: a Walkthrough and Tasks. You can provide feedback on these — whether it made a mistake or if the prompt wasn't specific enough — by selecting text and commenting on it, similar to how you would in Google Docs or Notion. You can also give feedback on the entire approach, much like in a Pull Request. I almost always write "LGTM" (Looks Good To Me) there. Then it starts working. Actually, lately, it starts even before your feedback to get a head start, confident in its plan, and can correct course later if needed.

I tried working without Antigravity, using only OpenSpec with Gemini 3 via the gemini-cli, but it felt more cumbersome and frustrating. The CLI isn't asynchronous like Antigravity, so you lose a lot of time waiting for the AI to think. Antigravity breaks everything down into smaller tasks that are easier and faster for the AI to handle, so it effectively starts working sooner and finishes faster.

Then there's the Agent Manager. If you feel like being an AI-powered superhero coder, you can ask it to do several things in parallel, even on different repos (or different clones of the same repo if you need to work on two different branches).

I wanted to know more on how to use it best, so this weekend I took some time to watch a couple of videos that I highly recommend.

Learn the basics of Google Antigravity #

The first one is "Learn the basics of Google Antigravity" from the Antigravity team.

This video provides an official introduction and walkthrough of Anti-gravity's core components:

Three Main Surfaces: The tool combines an Agent Manager (to create and manage agents), an Editor (a full IDE experience), and a Browser (incorporating an agent directly inside Chrome for autonomous testing).
Agent Assisted Development: The LLM is set up to automatically make decisions and implement easy tasks. For complex issues, it can pause and prompt the user for clarification.
Artifacts for Transparency: The agent generates markdown files like Implementation Plans and Walkthroughs to document its progress and changes.
Parallel Task Execution: Developers can kick off a task for the agent and start another complex task themselves.
Autonomous Testing: The agent can launch the integrated browser to verify its own code changes.

Google Antigravity: The New Best AI Editor? #

If you want a more in-depth view, check out "Google Antigravity: The New Best AI Editor?" from "AI with Brandon".

This review highlights:

Agent Manager Inbox: The main interface is designed like an email inbox for managing multiple projects.
Free Gemini 3 Pro Access: Includes free access to Gemini 3 Pro within the editor.
Complex Task Handling: The reviewer demonstrates the agent successfully implementing a full-stack feature involving multiple external services (trigger.dev, OpenAI TTS, blob store, database, and UI updates).

It looks like it's gonna change the way we develop, by turning us into... orchestrators of agents?

Improving Web Responsiveness - Interactivity improvements from real-world cases

2025-11-01T00:00:00Z

On Wednesday, October 29th, 2025, I had the pleasure of speaking at the performance.sync() event in Amsterdam. It was a pre-conference meetup for the performance.now() conference, and a great opportunity to meet and learn from other web performance experts.

My talk, "Improving Web Responsiveness - Interactivity improvements from real-world cases", was a 15-minute session where I shared practical techniques for debugging and optimizing slow interactions on websites.

Interaction speed is a key aspect of a site’s responsiveness to user interactions. This talk demonstrates practical techniques for improving slow interactions through real-world case studies of debugging and optimizing poor interaction speed.

Watch the video of the talk if you want to understand how to identify, troubleshoot, and fix slow interactions, ensuring a consistently responsive user experience.

The slides are available at the following link.

📽️ Slides

And here's just a picture of me on stage, just to provide eleventy with an image for the posts list. 😉

On stage at performance.sync() 2025.

The macOS clipboard manager you've been waiting for, now native in MacOS 26 Tahoe

2025-09-16T00:00:00Z

A screenshot of the Spotlight overlay showing the (searchable) clipboard history.

You know when you copy a piece of code, then you copy another one and you lose the previous one? Or you know you have something in your clipboard, you'd like to copy something else, but you have to paste what's in your clipboard first, otherwise you'll lose it? No more clipboard stress. Finally, multiple clipboard landed on macOS 26 Tahoe.

With the release of macOS Tahoe, you no longer have to rely on third-party apps to access items you've copied in the past. It's a game-changer for anyone who regularly copies and pastes multiple pieces of text (including code blocks), links, or images.

Here’s a quick guide on how to start using this long-awaited feature and supercharge your workflow.

Enabling Clipboard History #

The clipboard history is built right into Spotlight, but it's not immediately visible. The first time you use it, you'll need to enable it. Here's how:

Press Command (⌘) + Space to open Spotlight.
Now, you have two options to access the new clipboard features:
- Press the Tab key to reveal the new Spotlight menus.
- Press Command (⌘) + 4 to go directly to the Clipboard tab.
The first time you do this, a prompt will appear asking you to enable the feature. Just click "Enable" and you're good to go!

Using the Clipboard History #

Once enabled, using the clipboard history is super simple. Whenever you want to access a previously copied item:

Press Command (⌘) + Space to open Spotlight.
Press Command (⌘) + 4 to bring up the Clipboard tab in Spotlight.
You'll see a list of the text, links, and images you've copied.
Use your arrow keys or the mouse to select the item you want.
Press Enter or click on the item to re-copy it to your clipboard.

From there, you can paste it anywhere using the standard Command (⌘) + V shortcut.

A Few Things to Note #

While this is a huge step forward for macOS, it's worth noting a few of its current limitations. For example, it only saves your copied items for about eight hours, and there's no way to pin or save items permanently. If you need a more advanced solution with features like custom shortcuts, unlimited history, or smart filters, a third-party app might still be the way to go.

But for the average user, this new built-in feature is a major productivity boost and a very welcome addition to macOS. No more frantic re-copying!

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

2025-04-16T00:00:00Z

On 16 April 2025, I had the pleasure of speaking at one of the excellent Performance Observer meetups. The Performance Observer community focuses on sharing knowledge and practical insights into web performance monitoring and optimization. You can check out their past and future events here.

My talk was titled "Debugging and Optimizing Interaction to Next Paint (INP) for a Smoother Web". Here is the video recording of the session:

In this talk, I delved into the practical aspects of identifying and fixing Interaction to Next Paint (INP) issues. I covered common causes of poor responsiveness that I've encountered and demonstrated techniques using browser developer tools and performance monitoring data to pinpoint bottlenecks. The goal was to provide actionable strategies to improve user interaction speed and achieve better INP scores, keeping experiences snappy for users.

The Performance Observer meetups are a fantastic series dedicated to all things web performance, regularly featuring talks from industry experts on monitoring, optimization, and the latest performance metrics. It was great to contribute to this knowledgeable community.

Presenting during the Performance Observer meetup session.

📽️ Slides

Introducing yieldy-for-loop: an npm package to keep your loops non-blocking (and your UI smooth)

2025-01-14T00:00:00Z

If you’ve ever had to process thousands (or millions) of items in JavaScript, you’ve likely experienced that dreaded lag or UI freeze. It can happen when you perform intensive loops on the main thread, blocking updates to the interface. To tackle this, I’ve created an NPM package called yieldy-for-loop. This tiny utility helps you break large loops into chunks, periodically yielding control to the browser so your application remains responsive.

yieldy-for-loop in npm's website

Background #

Long tasks are a common performance bottleneck in front-end applications. When the main thread is busy running large loops, browsers can’t update the UI, and users may notice unresponsiveness or janky scrolling. Inspired by the article “Breaking up with long tasks, or how I learned to group loops and wield the yield” (PerfPlanet 2024), I wanted a simple, reusable function that would:

Break large loops into smaller batches.
Yield to the browser after each batch, giving the rendering engine a chance to paint and the user a chance to interact.
Adapt to whether the document is visible or hidden, since work behind a hidden tab can be deprioritized or even paused in many browsers.

Hence, yieldy-for-loop was born.

What it does #

Non-blocking iteration: Processes your items in batches, aiming to stay within a target time slice (e.g., 33ms for ~30 FPS).
Auto-yield logic:
- If the page is hidden, yields less frequently (e.g., every 500ms) to save resources.
- If the page is visible, yields more frequently to keep animations and user interactions smooth.
Browser compatibility: Uses a race between a short setTimeout and requestAnimationFrame, and optionally calls the Scheduler API if available.

Installation #

npm install yieldy-for-loop

Usage example #

import yieldyForLoop from 'yieldy-for-loop';

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

function processItem(item) {
  // Your heavy processing logic
  console.log('Processing item:', item);
}

(async function main() {
  console.log('Starting yieldy loop...');
  
  await yieldyForLoop(items, processItem, {
    fps: 30,              // Aim for ~30 frames per second
    hiddenThreshold: 500, // Yield threshold (in ms) when tab is hidden
  });
  
  console.log('All items processed without blocking the UI!');
})();

How it works #

Time Slice Calculation:
- The default frames per second (FPS) is set to 30, so it calculates a batch duration of ~33ms.
shouldYield() Check:
- Before processing each item, the function checks how much time has passed since the last yield.
- If it exceeds the threshold (e.g., ~33ms or 500ms if the document is hidden), it yields control back to the browser.
Yielding Mechanisms:
- Page Hidden: Uses setTimeout(resolve, 1)—just enough to let other tasks slip in.
- Page Visible: Uses a combination of requestAnimationFrame and a short timeout. If the experimental scheduler.yield() is available, it calls that as well.

By splitting your loop into batches, the browser has breathing room to render, respond to user input, and run other scripts, thereby avoiding the dreaded “page unresponsive” problem.

Why you need this #

Better user experience: Smooth scrolling, responsive buttons, and no random freezing.
Easy to use: Just wrap your normal loop logic with yieldyForLoop.
Micro-optimized: The code is minimal and straightforward, so it’s easy to maintain or customize.

Next steps #

Try it out: Install the package, import it, and integrate it into any heavy loop you have.
Contributions: Issues and pull requests are welcome! Check out the GitHub repo to file bugs, request features, or open PRs.
Spread the word: If you find this helpful, let others know.

Shout-out #

A special thanks to Rick Viscomi for writing the PerfPlanet article that inspired me to build this. Breaking up large tasks into smaller chunks has become a key performance strategy, and yieldy-for-loop aims to make it even easier to adopt.

Conclusion #

Long loops don’t have to mean unresponsive UIs. By periodically yielding to the browser, you can maintain a slick experience for your users. yieldy-for-loop takes care of the heavy lifting with minimal code, letting you focus on what you do best—building amazing web apps.

If you have questions, reach out or open an issue on GitHub. Now, go forth and keep those loops running smoothly.

Optimizing SVG Usage for Web Performance: A Comprehensive Discussion

2024-12-05T00:00:00Z

In a recent conversation among web performance enthusiasts, the topic of efficiently loading SVGs (Scalable Vector Graphics) on websites was explored in depth. The discussion centered around the best methods for incorporating SVGs, particularly icons, with performance in mind. Various techniques were compared, including inline SVGs, the <img> tag, CSS backgrounds, and SVG sprites. Here's a summary of the key insights and recommendations from that conversation.

SVG images are widely used to make icons on the web

Let's consider the following methods for loading SVGs.

1. Inline SVGs #

Usage: Ideal for above-the-fold icons like logos or menu buttons, especially when you need to style or animate individual elements within the SVG using CSS or JavaScript.

Advantages:

Styling Flexibility: Allows for direct manipulation of SVG elements.
Immediate Rendering: No additional HTTP requests since the SVG is part of the HTML.

Disadvantages:

Increased DOM Size: Each inline SVG adds to the DOM, which can impact performance.
Performance Overhead: Selectable and styleable elements may affect rendering performance.

Best Practices:

URL-Encoding over Base64: When embedding SVGs inline using data URLs, URL-encode them instead of base64-encoding to achieve better compression.
Limit Use: Reserve inline SVGs for essential, above-the-fold graphics that require interactivity.

2. `<img>` tag #

Usage: Suitable for general icons and images where styling or interaction isn't necessary.

Advantages:

Lazy Loading: Supports the loading="lazy" attribute to defer loading images until they are needed.
Simpler DOM: Keeps the DOM cleaner compared to inline SVGs.

Disadvantages:

Limited Styling: Cannot manipulate internal SVG elements directly through CSS or JavaScript.
Static Content: Not ideal for icons that need to change color or shape on hover.

Best Practices:

Dimension Attributes: Always include width and height to prevent layout shifts.
Avoid Lazy Loading for Immediate Assets: Do not lazy-load images that are crucial to the initial rendering or immediate interactions like hover states.

3. CSS background images #

Usage: Best for decorative graphics or background patterns that don't require interactivity.

Advantages:

Separation of Concerns: Keeps background images within CSS, maintaining a clean HTML structure.
Conditional Loading: Can be combined with media queries or JavaScript for responsive designs.

Disadvantages:

Limited Control: Harder to manipulate or animate compared to inline SVGs.
Accessibility Issues: Background images are not read by screen readers.

Best Practices:

Lazy Loading: Use JavaScript libraries like vanilla-lazyload to defer loading of background images if they are not immediately visible.
Appropriate Usage: Reserve for non-critical, decorative elements.

4. SVG sprites and `<use>` tag #

Usage: Effective when you need multiple instances of icons that can be styled or animated, and when serving SVGs from the same domain.

Advantages:

Reusable Symbols: Define SVG symbols once and reference them multiple times.
Styling Capabilities: Allows CSS styling of SVG elements as if they were inline.
Reduced HTTP Requests: Consolidates icons into a single file.

Disadvantages:

Initial Setup Complexity: Requires creating and managing an external sprite file.
Same-Origin Policy: The external SVG sprite must be on the same domain due to browser security restrictions.

Best practices:

Efficient Organization: Group commonly used icons into a single sprite file.
Fallbacks: Implement fallbacks for browsers that might not support external SVG sprites.

Match method to your use case #

Choose the SVG loading method based on the specific needs of your project. Inline SVGs for interactive elements, <img> tags for static icons, CSS backgrounds for decorative images, and SVG sprites for reusable, stylable icons.

Performance considerations #

DOM Size Matters: Excessive inline SVGs can bloat the DOM and degrade performance.
Lazy Loading Wisely: Use lazy loading for images not immediately needed, but avoid it for assets required for initial interactions or hover effects.
Compression Techniques: Prefer URL-encoding over base64 when embedding SVGs in data URLs to maintain better compression ratios.

Styling and interactivity #

Interactive Icons: Use inline SVGs or SVG sprites with the <use> tag when icons need to respond to user interactions.
Static Icons: Use <img> tags for icons that don't require interactivity to keep the DOM lean.

Accessibility and semantics #

Proper Attributes: Include alt attributes for <img> tags and aria-label or role="img" for inline SVGs to enhance accessibility.
Avoid Background Images for Essential Content: Since CSS background images are ignored by assistive technologies, don't use them for important content.

Avoid outdated techniques: #

Image Sprites: Traditional image sprites are largely considered outdated due to the complexity and diminishing returns in the era of HTTP/2 and HTTP/3.
Font Icons: Consider migrating away from icon fonts to SVGs for better scalability and styling flexibility, as detailed in Erwin Hofman's article.

Conclusion #

Optimizing SVG usage on websites involves balancing performance, maintainability, and functionality. By selecting the appropriate method for loading SVGs based on their purpose—whether for static display, styling, or interactivity—you can enhance both the user experience and site performance. Remember to consider factors like DOM size, lazy loading, and accessibility when implementing SVGs in your projects.

Talk video: "How I made the web more responsive — real-world case studies of INP optimizations", We Love Speed 2024 conference

2024-11-26T00:00:00Z

On 17 September 2024, I spoke at the We Love Speed 2024 conference about enhancing web responsiveness. Specifically, I discussed how to debug and avoid slow interactions based on my experience on auditing Interaction to Next Paint (INP) on clients' websites.

The title of the talk was "How I made the web more responsive - real-world case studies of INP optimizations", in French "Comment j’ai rendu le web plus réactif — études de cas concrets d’optimisations d’INP", and this is the video of my talk.

After providing an initial explanation of INP, I demonstrate how to debug slow interactions using both Chrome DevTools and Real User Monitoring (RUM) data. I then illustrate three common mistakes I encountered while auditing INP on dozens of websites and explain how to avoid them to ensure snappy user interactions and keep your INP below 200 milliseconds.

On stage at We Love Speed 2024.

📽️ Slides

The web is dead, long live the web (repost in English)

2024-11-22T00:00:00Z

👀 The author of this article is Antonio Moro aka Itomi.
🇮🇹 Original article | Itomi Studio | About | Shop

The closure of Badtaste.it is just the latest closing on a coffin that has already been closed for years: online publishing as we have known it for the past twenty years is now dead and buried.

Yesterday, news broke that Badtaste.it is shutting down after 20 years of activity. It’s not a surprise, at least not to me. It’s just the latest signal among many over the last five years. And anyone blaming the pandemic has understood very little about what’s really happened.

I’m one of those who has been part of “online publishing,” as it’s been fashionably called for years, in Italy since its inception—back when it was simply called “posting on a blog.” The party lasted 20 years, then it ended. And even if some are lingering at the exit, there’s not much to be done. The music has stopped.

Thankfully, I had the clarity to get out before it completely imploded. Three years ago, I stepped down from the leadership of the site I founded and directed for 12 years and started a publishing house based on a completely different project—one that returns to the physical object and abandons the "all digital" concept so cherished by this industry over the last two decades.

The web is dead, and it largely killed itself. It killed itself when it let a single company and a single search engine dictate the rules upon which it relied.

It killed itself when it handed over the communities it painstakingly built over the years to a few social networks.

For years, Google dictated how online articles had to be written, published, and formatted. What keywords and how many needed to be included in every piece for it to even make sense to publish. We stopped writing for our audience and, without even realizing it, started writing for Google’s algorithm—to get more traffic, more people onto our content. We became addicted to a substance that never nourished us: blind, useless traffic made up of people who didn’t even know what they were reading or where they were reading it. We erased the identities of our sites and blogs, turning them into sterile containers of personality-free content.

Facebook, the only other strong source of traffic, finished the job. It took away our communities, our loyal readers. It took away interactions, devouring what we had built. The moment we started seeing “Comments: Zero” as normal under our articles, our sites began dying irreversibly.

We abandoned a small, loyal, and engaged audience for a large, disinterested, and unaware one.

Blogs and editorial sites were born because a few enthusiasts wanted to share their ideas, opinions, and content. We did it for free, in our spare time. And those who read us did so for free. And we were happy with that.

Then it became a job, and figuring out how to make money from it became crucial. Once we’d given away the fruits of our labor—our content—the only option left was to monetize through banners and ad campaigns.

On Lega Nerd, I resisted for years, doing only “native” campaigns with advertisers aligned to my niche, keeping banner ads to a minimum because they killed readability and the overall user experience. Over time, the Internet economy and online advertising shifted more and more toward new players—today we call them “influencers,” but they’re just content creators like we were, only doing it differently and on other platforms, reaching massive audiences.

It took advertisers a few years to grasp the power of influencers, but eventually, the money moved to creators. Running a campaign for your site was already difficult five years ago, let alone today.

Now, the gods of websites are banners. They exploded at the end of the 2010s, thanks to the rise of “Real-Time Bidding” platforms that boosted their profitability, and we dove into this new opportunity, filling our sites with crap. Crap in every paragraph. Crap popping up over content. Crap autoplaying and staying fixed as you scroll to read. Crap everywhere.

We needed more traffic, and we chased it by any means necessary. More traffic equaled more page views, more page views equaled more banners shown, and more banners equaled more money to keep the ship afloat.

We needed more traffic from Google, so we wrote what it wanted, rebuilt our sites from scratch to its specifications, optimized everything as it dictated.

We needed more traffic from social media, so we started publishing hundreds, thousands of news stories. Current events. Just a few lines, little substance, but enough for people scrolling through Facebook mindlessly. Thousands of news pieces per day. Then we went for clickbait—to make people click and land on our sites. And fake news—hundreds, thousands of sites created solely to generate traffic and monetize banners.

Crap, covered in more crap.

And those who genuinely believed in it, who wanted to publish interesting, independent, educational, informative content? They’re screwed.

Screwed because they can’t compete with those who play by those rules without turning their site into crap too. Do you want to make a living, or do you want to write for a handful of people and earn nothing?

The pandemic years further inflated the web artificially. Traffic grew, banners multiplied even more, and users’ patience ran out. It was only a couple of years of good news for publishers before plunging back into reality.

Now banners pay almost nothing. Campaigns are gone. Monetizing an editorial site is harder than ever. We’ve made the web ugly, and now no one wants to look at it. People get their information elsewhere, without having to endure the crap that covers internet sites.

We gave away our content for 20 years, and now no one wants to pay for it—especially after we published crap for years. No subscriptions. No “premium” areas. Nothing works anymore, and we don’t know where to turn.

It’s time to close. To do something else.

The young will figure out something new, something innovative and suited to the times. Fast times. Brutal times.

I see a faint return to the past. Small communities of people tired of the bulimia of social media are emerging. Small editorial projects are being born that use the web but don’t rely solely on it. The web will never truly die.

The web is dead. Long live the web.

My experience at performance.now() 2024: Europe's premier web performance conference

2024-11-16T00:00:00Z

From November 14 to 15, I attended performance.now in Amsterdam, the most esteemed conference in the realm of web performance in Europe. As someone deeply embedded in this niche of web development, meeting other like-minded people at the event was both inspiring and invaluable.

My performance.now 2024 badge, plus some swag and stickers

Exceptional Content and Speakers #

The schedule for the two conference days.

From the moment the conference commenced, it was evident that performance.now() stands out for its high-caliber content and speakers. Each session was meticulously curated, featuring industry leaders who covered a wide array of topics surrounding modern web performance challenges and solutions.

Keynotes explored the evolving landscape of web speed, emphasizing the critical need for responsiveness and user-centric metrics. Talks addressed diverse subjects, from accessibility's impact on performance to practical strategies for improving Core Web Vitals, particularly INP (Interaction to Next Paint). Other presentations focused on advanced tooling, font optimization, and minimizing third-party script impacts.

With in-depth case studies and future-focused discussions, the event showcased cutting-edge techniques and encouraged a holistic view of web performance.

Connecting with like-minded professionals #

One of the highlights of the conference for me was the opportunity to connect with fellow professionals who share the same passion for web performance. The numerous breaks and the lively after-party facilitated meaningful conversations and networking. It was refreshing to exchange ideas, discuss challenges, and explore potential collaborations with peers who truly understand the intricacies of our field.

In addition to attending, I had the honor of contributing to the conference in two significant ways.

Contributing in the help desk sponsored by Google #

Morten Sorth and Ismail Gunsaya from Skyscanner asking me about INP optimization

One of the key highlights for me was participating in the Google-sponsored Help Desk, where I engaged with attendees for about half an hour, answering their questions and offering solutions to their web performance challenges. This experience not only allowed me to give back to the community but also to learn from the diverse array of problems and perspectives presented by other professionals.

Participating in Henri Helvetica's live interview on YouTube #

Henri Helvetica and me during the live streaming

One of the key highlights for me was participating in Henri Helvetica's live interview on YouTube. Being interviewed by Henri provided an opportunity to share my experience and background with a broader audience. The interview delved into my personal background and personal challenges, and I loved that.

Check out Henri Helvetica's Youtube channel.

Pre-event: Performance.Sync by Mozilla #

On November 13, the day before Performance.now, I also had the pleasure of taking part in Performance.Sync, an event organized by Mozilla. During this session, my good colleague Brian Louis Ramirez presented on the topic of "Finding the needle in the haystack", which focused on identifying anomalies in Real User Monitoring (RUM) data.

Brian's insights into effectively sifting through vast amounts of performance data to pinpoint critical issues were both enlightening and highly practical. Participating in Performance.Sync provided a deeper understanding of advanced data analysis techniques and reinforced the importance of meticulous monitoring in optimizing web performance.

Madames et messieurs, Brian Louis Ramirez on stage

Captured insights and follow-ups #

Throughout the conference, I took some notes that I will carefully review at a second time, as some of them inspired actions on my side.

SpeedCurve wrote a comprehensive web performance guide
Good idea to correlate conversion rate and INP
Only alert on the KPI changes, not when enablers changed
Bucket type of regressions in moderate, acceptable and critical, based on the % of regression
When a regression happened, triage who, wht, when, where and why it happened
~Lazy loaded images can be decoded asynchronously, but eagerly loaded images should not.~ Contested, see what decode=async actually does.
The new annotations functionality on Chrome Dev Tools will be very useful to me and other professionals
We can use crbug.com/new to report bugs to the Chromium project and eventually request new features
Chrome developer is moving the insights from the Performance Insights panel to the Performance panel -- there is one for CSS performance too, if you trace with the "Selector stats (slow)" option active
Variable fonts are lighter only if you use 2 or more variations of the font, otherwise just load the single variation (e.g. the bold version for titles)
The CSS overview tab in developer tools gives you the idea of how many instances of the page are using which fonts
There's a new working group for incremental font transfer, to download only the portion of the font users currently need
size-adjust (at box size) and font-size-adjust (at font level) are useful to try and render the fallback font like the web font. I noted there is a css-size-adjust-tester tool, which I can't find at the moment, whereas I found Brian Louis Ramirez's fallback font generator.
Google Publisher Tag (GPT) has a feature to yield to the main thread to optimize INP
When there are gaps in commit events in dev tools, look in other tracks or load the trace in Perfetto to find out why

These notes have been instrumental in formulating follow-up actions and integrating new techniques into my workflow, and also for my pet projects. Sharing these insights will undoubtedly benefit others who are passionate about advancing their web performance skills.

Reflecting on the Experience #

I like to be in the front rows to visually engage with the speakers

Attending Performance.now was a rewarding experience that reinforced my commitment to excellence in web performance. The blend of high-level content, expert speakers, and a vibrant community makes it an unmissable event for anyone in this niche. I look forward to applying the knowledge gained and contributing further to the ongoing dialogue in our field.

If you’re passionate about web performance and looking to elevate your skills, I highly recommend attending Performance.now. It’s not just a conference; it’s a gathering of the brightest minds dedicated to pushing the boundaries of what’s possible on the web.

Feel free to reach out if you have any questions about the conference or web performance in general!

How to use Google Meet with two screens: separating shared content and attendees' faces

2024-11-06T00:00:00Z

The welcome screen of Google Meet.

In Google Meet, if you're working with two screens, you might want to keep the shared content on one screen while keeping the faces of attendees on another. This setup allows for better engagement in the meeting by making it easier to focus on the faces of attendees, chat, and other meeting interactions, while still keeping an eye on the presentation or shared content. Here’s how you can do it with Google Meet's Companion mode and a few manual steps.

👀 The wait is over!!! This is not required from March 2026 anymore, because Google released the feature to bring the shared content to a new window! 🥳 I'm leaving the article here because it's a nice example of how to use Companion mode and it might be useful for some people.

Step-by-step guide to using Companion mode #

Using Companion mode lets you join a Google Meet meeting again from a second tab or window without duplicating audio, allowing you to configure each window individually. Here’s how I set it up:

Set layout for attendee faces
In your main meeting window, click on the ... (more options) menu, and go to Change layout. Choose Tiled to make sure attendees’ faces are visible in a grid.

Google Meet layer to change the layut
Minimize the presentation in the main window
If the presentation is pinned, unpin it by hovering over it and clicking the pin icon. This will make the presentation smaller and attendees’ faces larger, ensuring your main focus in this window remains on the people, not the content.

This is the icon to unpin the presented content.
Duplicate the Google Meet tab
Right-click on your Google Meet tab and select Duplicate. This new tab will be used exclusively for viewing the shared content.

Here's the dropdown menu to duplicate a Chrome tab
Enable Companion mode in the duplicated tab
In the duplicated tab, choose Use Companion mode. Companion mode will join the meeting again without sound, so you won’t have any distracting audio echo or feedback. This secondary window will serve as your content-only view.

Companion mode is right there, highlighted in blue.
Move the Companion mode tab to a new window and position it on your main screen
Drag the Companion mode tab into a separate window, and move it to your main screen where you want to view the shared content. Now, you’ll have the main meeting with attendees’ faces on one screen and the content in Companion mode on another.
Enhance the Companion mode window with my Google Meet true full screen bookmarklet In the Companion mode window, you can use my Google Meet true full screen bookmarklet to enable a true full-screen mode. This way, the shared content fills the screen without any extra UI elements, making it easier to focus on the presentation.
Bonus step If you bring the main Google Meet's picture-in-picture (PIP) in the main Google Meet window, it's even possible to bring participants faces in front of someone else's presented content, like you can do with Zoom.

Why this setup works #

This setup keeps attendees’ faces, chat, and controls accessible in the main window, while reserving a second screen exclusively for content. It’s a more immersive experience and a workaround for Google Meet’s current UI limitations.

Final thoughts #

Yes, it’s a bit of a manual process, but until Google improves its dual-screen functionality, these steps are the most effective way to manage meeting visuals across multiple screens. This setup is especially useful for virtual conferences or meetings with high levels of interaction, as it keeps both the presentation and the people engaging with it fully visible.

Give it a try, and let me know how it works for you! If you have any suggestions to streamline the process, feel free to share them.

True full-screen mode for Google Meet shared content

2024-11-05T00:00:00Z

Google Meet in true full screen, finally!

As someone who spends a lot of time on Google Meet, I’ve often been frustrated by the inability to view shared content in true full-screen mode. There’s a lot to be said for maximizing screen space, especially when diving into complex code or detailed design presentations. But for whatever reason, Meet limits full-screen options, leaving borders and UI elements visible, which can be distracting.

👀 The wait is over!!! This is not required from March 2026 anymore, because Google released the feature to bring the shared content to a new window! 🥳 I'm leaving the article here because it's a nice example of how to create a bookmarklet and it might be useful for some people.

I got tired of waiting for Google to provide a solution, so I decided to make one myself. I created a bookmarklet that lets you view shared content in true full-screen mode on Google Meet, removing the extraneous elements and maximizing usable screen space.

Check it out and add it to your browser here:

👉 Google Meet True Full-Screen Bookmarklet on GitHub

There you will find the procedure to add the bookmarklet to your browser, and once added, you can activate true full-screen mode with a single click.

This simple script aims to improve your meeting experience by keeping the focus on the content that matters. Let me know if you find it useful, or if there are any tweaks or features you'd like to see added.

Happy full-screening!

The remote work debate: my view on finding balance

2024-10-20T00:00:00Z

After nearly three years of working fully remotely, six years of "smart-working" (two remotely, three in the office), and more than 15 years working in offices, I’ve gained a lot of perspective on the remote work debate. While I support many of the benefits of working from home, I also recognize the drawbacks, and I think there’s a middle ground that works best.

The Benefits of Remote Work #

Remote work offers clear advantages. First and foremost, it’s effective—allowing for increased productivity, fewer distractions, and better focus when you have the right setup, whether an isolated space at home or a desk in a coworking space. For employees, there’s also the benefit of flexibility. You have the freedom to arrange your schedule more easily around personal commitments and preferences. Financially, it’s a win, too—no commuting costs, no need to buy lunch out every day.

The Human Element: What We Miss #

But remote work isn’t all upside. One of the biggest downsides is the isolation it can bring. It’s easy to compensate for this by staying active, going to the gym, or catching up with friends. Yet, there’s no replacement for the spontaneous exchanges that happen with colleagues when you share a workspace. These informal interactions can spark new ideas and help foster team spirit.

A personal example: just last Thursday, I was in Hamburg for an event at the company office. During a break, I had a casual conversation with one of my colleagues, a working student, and discovered she was preparing her thesis on a topic directly related to a project I’m working on. That valuable connection wouldn’t have happened without the in-person interaction.

There is something unique about the bonds formed through working side-by-side for long hours. In many cases, you spend more time with your colleagues than with your family when working full-time in an office. This is especially true for small teams, where these connections can be strong enough to last years—bonds* that can remain strong even as you move on to new jobs.

*Marco, Giorgio, Alberto, David, and Tommy, if you're reading this, I'm thinking of you.

Finding Balance: A Mixed Approach #

In my experience, the ideal setup is a hybrid approach. Work from home most of the time, but with the flexibility to go to the office when needed—for example, for brainstorming sessions, collaborative projects, or important meetings.

I also believe companies should organize regular in-person events—whether workshops or team-building activities—at least four times a year to maintain a sense of connection and shared purpose.

This model strikes the right balance between autonomy and collaboration, ensuring that while we enjoy the flexibility of remote work, we don’t lose the valuable interpersonal connections that fuel innovation and camaraderie in a team.

Talk: How I made the web more responsive — real-world case studies of INP optimizations

2024-09-17T00:00:00Z

In May 2024, I started speaking at conferences and meetups about improving web responsiveness. My talks focus on debugging and preventing slow interactions, drawing from my experience auditing Interaction to Next Paint (INP) on dozens of clients' websites.

📽️ Slides

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

On stage at We Love Speed 2024, Nantes

📺 Video - Event page

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

On the Coding Front-end stage of WMF 2024: how to debug INP, the hard way.

The title of the talk, in Italian, was "Migliorare la reattività del web — Guida pratica per debug e prevenzione delle interazioni lente".

📺 Video - Event page

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

Presenting at GDG Madrid, showing the first of the INP subparts: Input Delay.

The title of the talk in Spanish was: "Hagamos que la web sea mas responsive en 2024".

GDG Madrid event

Bologna JS, Bologna 🇮🇹 - 22 May 2024 #

At the Bologna JS Meetup. This is the only picture I've got 🤷‍♂️. It's pretty final.

📺 Video · Meetup event page

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

Me speaking on "stage" at Phygital Hub (Gellify)

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

Event page

DevRomagna, Faenza 🇮🇹 - 26 September 2024 #

Me speaking on "stage" on stage at DevRomagna, Faenza

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

Event page

My Favorite Features of iOS 18: A Game-Changer for Multilingual Users and More

2024-09-13T00:00:00Z

With each new iOS release, I always look forward to exploring the latest features Apple has to offer. iOS 18 has introduced several changes, some small and subtle, others more profound, that have significantly enhanced my user experience. Here are my favorite new features in iOS 18 and why I think they’re a game-changer.

The iOS 18 keyboard switcher showing different keyboards sets: Italian and English, Portuguese and French, Spanish and German

1. Bilingual Keyboards: A Seamless Multilingual Experience #

One of my absolute favorite updates is the new keyboard functionality that allows me to type in multiple languages without changing the input language manually. It's much better this way! Essentially, iOS 18 offers bilingual keyboards, so I can write messages like:

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

And the best part? I don’t need to switch the keyboard layout every time I change languages. This is a massive improvement, especially for people who frequently switch between languages like I do. It’s a small feature that adds so much fluidity to multilingual conversations.

2. Enhanced Dictation: Faster and Smarter #

“Hi, I’m trying out the new dictation feature on iPhone 18. It seems to have automatic punctuation also in Italian now. What time did you say we’re leaving today?”

Yes, automatic punctuation is here! It’s a simple yet highly useful upgrade, and it saves me a ton of editing time. But here's a tip: to dictate in English, make sure you have English dictation enabled, as the default Italian setting will only pick up basic English words. It's a small hurdle, but the overall improvement in dictation is undeniable.

3. Improved Home Screen, Control Center, and Backgrounds #

iOS 18 also made some great strides in customization. Now, managing your home screen and control center is much more flexible. You can freely position app icons on the home screen without the rigid grid system of old. Plus, the background management has become more intuitive, making it easier to switch and organize wallpapers.

4. Upgrades to Notes, Reminders, and Calendar #

For those of us who use the built-in productivity apps daily, iOS 18 has delivered some helpful tweaks. In Notes, you now have collapsible sections, while in Reminders, the smart lists feature makes managing tasks a breeze. The Calendar app has introduced a new month view that makes scheduling even more efficient. These are small, incremental updates, but they’re invaluable for staying organized.

5. Internet Pages Read Aloud (The Real Game-Changer) #

This might just be the killer feature of iOS 18. You can now have entire web pages or articles read aloud to you, even with the screen turned off. Siri now gives you controls for play, pause, and reading speed, making it incredibly convenient. Before, I relied on Microsoft Edge for this, but now Siri can handle it, at least for Italian content (as I use Siri in Italian). For English articles, I’ll probably stick with Edge for now, but this feature is a fantastic addition for hands-free browsing.

6. A New Password App for Secure Management #

iOS 18 also introduces a new password app, which lets you manage passwords, passkeys, and two-factor authentication codes all in one place. It's a handy tool for anyone who doesn’t already use a third-party password manager. Personally, I will still use KeePass and KeePassX because I need to share some passwords with non-Apple devices, and I don't want to get locked out of everything if I lose access to my Apple ID by any chance.

Conclusion #

These are my favourite features that have made iOS 18 such a joy to use. With smoother multilingual typing, smarter dictation, and enhanced customization, Apple has really upped the game. And let’s not forget the convenience of having Siri read web pages aloud or the new built-in password manager. iOS 18 feels like a solid evolution that improves daily tasks, making life just that little bit easier.

Mitigating CLS Caused by Promotional Banners: A Practical Solution

2024-08-26T00:00:00Z

A website with a top promotional banner pushing down the content below it

Cumulative Layout Shift (CLS) is a core web vital metric that measures visual stability. It occurs when content on a web page moves unexpectedly, often causing user frustration.

One common cause of CLS is a promotional banner being injected at the top of the page after the main content has already loaded. This would push down other elements on the page, leading to a poor user experience. Unluckily, this is a very common problem occurring in the websites I've been working on or consulting for.

In this blog post, we'll explore a method to mitigate CLS by reserving space for a promotional banner using session storage. This approach ensures that the banner doesn't cause layout shifts on subsequent page loads, leading to a more stable and user-friendly experience.

The Problem #

In the scenario described before, the logic to determine whether to show this banner is executed via JavaScript, often after the page's content is already visible. This results in a layout shift, where all content below the banner is suddenly pushed down, causing a jarring user experience.

The Solution #

To solve this problem, we can use sessionStorage to remember the banner's content and state during the user's session. By doing this, we can inject the banner's content immediately when the page loads, preventing any layout shift. If the user has closed the banner, we ensure it remains hidden for the rest of the session, so it isn't shown on the next page load.

Here's how we can implement this:

Check if the banner was previously closed:
We first check if the user has closed the banner in their current session. If they have, we don’t display it again.
Inject the banner's content:
If the banner was not closed and there is saved content in session storage, we inject it into the page as soon as possible. This prevents the layout from shifting when the banner is eventually loaded.
Save the banner's content:
When the promotional content is fetched for the first time, we save it to session storage. This allows us to reuse it on subsequent page loads without causing a layout shift.
Handle banner closure:
If the user closes the banner, we set a flag in session storage to ensure it doesn’t reappear during the same session.

Implementation #

Find here the GitHub repository with the code and the live demo on GitHub Pages.

For your convenience, here's the code copy-pasted from the demo page.

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

  // Function to check if the banner was closed by the user
  const isBannerClosed = () =>
    sessionStorage.getItem(bannerClosedKey) === "true";

  // Check if the banner was previously closed by the user. If yes, do nothing.
  if (isBannerClosed()) return;

  // Function to inject the banner into the page
  const injectBanner = (bannerContent) => {
    const bannerContainer = document.getElementById(bannerContainerId);
    if (bannerContainer) {
      bannerContainer.innerHTML = bannerContent;
      bannerContainer.style.display = "block";
    }
  };

  // 👀 Check if banner content exists in sessionStorage, and eventually inject it
  const savedBannerContent = sessionStorage.getItem(bannerSessionKey);
  if (savedBannerContent) {
    injectBanner(savedBannerContent);
  }

  // Function to simulate the fetch of the promotion.
  const loadPromotion = () => {
    setTimeout(() => {
      const bannerContent = "<div>Your promotion content here</div>";

      // Inject the banner content
      injectBanner(bannerContent);

      // 👀 Save the banner content to sessionStorage for the next time
      sessionStorage.setItem(bannerSessionKey, bannerContent);
    }, 600);
  };

  // Function to handle banner close action
  const closeBanner = () => {
    sessionStorage.setItem(bannerClosedKey, "true");
    const bannerContainer = document.getElementById(bannerContainerId);
    if (bannerContainer) {
      bannerContainer.style.display = "none";
    }
  };

  // Simulate fetching the promotion
  loadPromotion();

  // Example event listener for closing the banner
  document
    .getElementById("close-banner")
    .addEventListener("click", closeBanner);
});
</script>

How It Works #

Session Storage: This is used to store the promotional content and the closed state of the banner. The data persists across page loads within the same session, ensuring the user experience is consistent.
Immediate Injection: By immediately injecting saved content into the page, we prevent any layout shift that would occur if the banner were loaded after the page was fully rendered.
User Control: If the user closes the banner, it won't reappear during the same session, ensuring the user’s preference is respected.

Conclusion #

By leveraging session storage to manage the display of promotional banners, you can significantly reduce CLS on your website. This approach not only enhances the user experience but also improves your site’s performance metrics, contributing to better SEO and higher engagement rates.

This method is particularly useful for websites with dynamic content, where the decision to show certain elements is made after the page has loaded. By planning for these elements ahead of time, you can create a smoother, more stable experience for your users.

This approach is a simple yet effective way to address one of the common causes of CLS, and can be implemented with minimal changes to your existing codebase.

Impressions on the Google I/O Connect 2024 + GDE Forum in Berlin

2024-08-01T00:00:00Z

Google I/O is the annual Google event for developers which takes place in their offices in California, USA. Google I/O Connect is a series of hands-on, in-person developer events held around the world, to help developers apply the technology and announcements from Google I/O through live sessions, demos, codelabs, office hours, and more. As well as last year, I was invited to Google I/O Connect EMEA 2024. And as a Google Developer Expert (GDE), on the next day I also took part to the GDE Forum in Berlin Google offices. Keep reading to find out what these events were like and what I liked most of them.

Me, comfortably leaning on the slash between the I and the O of the Google I/O Connect logo

The community dinner #

On the day before the conference, Google holds a dinner event to mix Google Developer Experts (GDE), Women Tech Makers (WTM), Google Developer Groups (GDG) organizers and people who work at Google (aka Googlers) in the GDE program or as developer relationship (devrel).

People chatting at the community dinner

The aim of the event is to socialize, getting to know more people, networking with the ones you already know, strengthen the personal and professional connection, all of that while eating, drinking and discussing of the latest news about the industry.

From the left: Ines Akrap, me, Barry Pollard, Fabian Krumbholz, Medhat Dawoud, Jad Joubran, Erwin Hofman, Joan León, Anna Migas.

I enjoyed the event, spent most of the time chatting with other web performance GDEs and googlers - particularly Barry Pollard (web performance developer advocate for Google Chrome) and Jocelyn -, hung out briefly with the Italian GDG community, ended up singing karaoke with my former workmate Ines, and when the event was over I took a long walk to the hotel with Paolo Galeone, a Machine Learning GDE who flew in with me from Bologna.

Main Google I/O event #

The main stage was taken from Googlers for the initial keynote, and there was I, sitting in the front row as I like (mostly because I'm short-sighted).

Me, Aleksander Denisov and Rowdy Rabouw sitting in the front row

However Google I/O is NOT a replica of Google I/O, so Google require you to watch the videos of what was presented at the main I/O event beforehand. Then, at Google I/O connect, you have the chance to ask questions to Googlers, who sit on stage, about the topics presented.

The event is divided in many stages (Web, AI, Android, Flutter, etc.) so you can attend the ones you're most interested in. For example, I spent most of the time in the Web stage, at events about the new web UI features, about the latest Angular release, etc.

Una Kravetz, Bramus, and Barry Pollard from Google, on stage at The Latest in Web UI

There, I also had the luck to meet Nishu Goel, who did a very nice job in exploring Interaction to Next Paint (INP) last year and gave a talk about it at the Performance Now confernce, so she's a rockstar to me but I never had the chance to meet her in person. So, more networking.

More networking! From the left: me, Jeremy Wagner, Fabian Krumbholz, and Nishu Goel

This event was open to all the people invited to the community dinner, plus other people who occasionally joined the event by purchasing a ticket.

GDE Forum #

The GDE forum was restricted to Google Developer Experts, and had a limited number of seats (150), so only the ones who registered first were able to access it. I was amongst the lucky ones, but I know many who just were in the waiting list and still didn't make it.

Me at the entrance of the GDE forum Belin at Google Offices

Here I had the chance to see a preview and give feedback on some of the feature the Google Chrome Developer Tools team are working on, which I can't reveal as they're covered by NDA, and take part to a live INP debugging session with Barry Pollard (the most appreciated event as it resulted from the final poll).

Initial keynote for the GDE forum

And of course, more networking!

More networking with Nishu Goel and Barry Pollard

To conclude, it was a very lovely and useful event to take part to, and I hope I will have the chance to take part to it next year.

Jake Archibald's talk "In the loop", transposed

2024-02-17T00:00:00Z

Jake Archibald's talk "In the loop" (JS Conf Asia) is still one of the best sources of information on how browsers process tasks and are able to respond to user input. As I didn't find anything as comprehensible as that in text format, I transposed his talk into this blog post. Find the video at the end.

Main thread and deterministic order #

Take the following code snippets:

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

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

Would you say they behave in the same way for the user experience? Will users see a blink because of the element was added to the DOM, then hidden right away?

The answer is the two code snippets behave exactly in the same way, and that's because of how the main thread works.

The main thread #

We call it the main thread because loads of stuff happen here. It's where JavaScript happens. It's where rendering happens. It's where the DOM lives.

This means stuff on the web has a deterministic order. We don't get multiple bits of code running at the same time, like trying to edit the same DOM resulting in a world of horrible race conditions.

But it does mean that if something on the main thread takes a long time (e.g. 200 milliseconds, which is a long time in terms of user interaction) then it becomes really noticeable because it has blocked loads of other things, like rendering, interaction.

Think about a block in the main thread like when we sneeze. Everything else becomes blocked until the sneeze is over. Needless to say, we don't want to write code that is like a sneeze.

So, although we have this main thread thing, we tend to spawn a whole series of threads like for networking stuff, encoding and decoding, crypto, monitoring input devices, but once these threads have done something that the page needs to hear about, they need to sort of come back to the main thread to give it that information and it's the event loop that orchestrates all of this.

Task queues #

Take setTimeout, for instance. Have you thought about how it actually works? When invoked, must run the following steps:

wait ms milliseconds
invoke callback

Done.

We run the steps in parallel — which is a way to say get off the main thread and run this stuff at the same time as other stuff — but we create a new problem here, because now we're invoking a callback from something other than the main thread, and there's no way this can really work. You would end up with lots of JavaScript running in parallel, still editing the same DOM and you'd end up with all of these race conditions.

So, what we do is this: we queue a task. We queue a task to get back on to the main thread at some point, and now we're calling JavaScript on the thread where JavaScript lives, so it all works.

Meet the event loop #

This is how Jake depicted the event loop. It's a circle, the execution goes round and round, until a task is queued in the "task detour" on the left.

Now what if we do this:

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

Well, according to the spec, these two algorithms go parallel, each waits for a thousand milliseconds, and then they need to come back on to the main thread. And they do that by queuing a task.

So, the browser says to the event loop "Hey, I've got something here that wants to do main thread work. In fact, I have two things", and it adds each one as a separate to-do item in the task queue.

Now two tasks are scheduled for execution in the task queue

The event loop's like: "Sure, that's fine, I'll get around to it". So, it runs the first callback, it goes around the event loop, and runs the second callback.

And that's tasks. It would be pretty simple if that's all it was, but it gets more complicated when we think about the render steps.

The render steps #

This is what the browser uses to update what's actually on the screen.

On the right side of the event loop, the render steps: style, layout, painting

The render steps are another detour and that involves style calculation.

Style (S): this is looking at all of the CSS that's going on and working out what applies to each element.
Layout (L): this is creating a render tree, figuring out where everything is on the page and where it's positioned.
Paint (P): creating the actual pixel data, doing the actual painting.

So, at some point the browser will say to the event loop: "Hey, you know, we need to update what's on the screen" and the event loop's like "No problem, I'll get around to that next time I go around the event loop."

An infinite loop with `while(true)` #

Here's a page with a gif and some text and a big button that runs an infinite JavaScript loop.

A simple page with a gif of a cat, some text, and an infinite loop button

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

So, if I click that button, everything stops. The gif has stopped. I can no longer select text. The whole tab comes to a standstill.

Visualization of the event loop executing an infinite loop

The user clicks the button, so, the browser says: "Hey, event loop, I've got a task for you", and event loop's like "Yep, no problem, I'm on it." But this task never ends. It's running JavaScript forever.

A couple of milliseconds later the browser says: "Hey, event loop, we need to update that gif that was on the page. So, if you could just render at your next earliest convenience that would be fantastic". The event loop's like, "Yeah, okay, I'll get around to that right after I finish this infinite loop that I'm busy doing right now."

Then the user tries to highlight text and that involves like hit testing, involves looking at the DOM to see what the text actually is. So, the browser says: "Hey, I've got a couple of more items for your to-do list there". And the event loop's like: "Are you having a laugh? Do you know how long it takes to perform an infinite loop? It's a long time, you know. There is a clue in the name."

So, that is why a while loop blocks rendering and other page interaction. But this is a good thing in practice. Let's look again at the code that we started with.

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

I used to worry that this would result in a flash of content, but it can't, right? Because this script runs as part of a task, and that must run to completion before the browser can get back around to the render steps.

The event loop guarantees your task will complete before next rendering happens.

An infinite loop with `setTimeout()` #

So, a while loop blocks rendering, but what about this?

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

This is a loop, but each time we go round the loop we're using setTimeout to queue the next call.

If we execute that setTimeout loop in the demo page, it looks nothing has changed, but here's what's happening in the background.

The execution of a setTimeout loop executes a single task, than queue another one

We queue a task, go around the event loop, pick up that task, and we queue another task as a result.

That just keeps happening and happening until the end of time, but as we've already seen like only one task can be processed at a time. So, when it's processing a task, it's having to go all the way around the event loop to pick up the next task.

So, that means at some point the browser can say "huh, we should update the display for that gif", because at that point it can go around and update the display.

After the execution of that setTimeout callback, the loop is able to render

And that's why a setTimeout loop is not render blocking.

`requestAnimationFrame` #

Now if you want to run code that has anything to do with rendering, a task is really the wrong place to do it, because a task is on the opposite side of the world to all of the rendering stuff, as far as the event loop is concerned. What we want to do is we want to run code in the render steps.

We want to run code here:

requestAnimationFrame is the yellow box labeled "rAF" which appeared before the style (S) block in the render detour

And the browser lets us do that and it lets us do that using requestAnimationFrame.

"rAF" callbacks, they happen as part of the render steps, and to show why this is useful, I'm going to animate a box, just a box, using this code.

The box which is about to be animated

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

So, I'm going to move that box forward one pixel, and then use requestAnimationFrame to create a loop around this. And that's it. That's all it does.

But what if we switched requestAnimationFrame for setTimeout?

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

It looks like this.

The two boxes being animated. The one labeled setTimeout is moving faster than the one labeled requestAnimationFrame

The new box animated with setTimeout is moving about 3.5 times faster, and that means this callback is being called more often, and that is not a good thing. That's not a good thing at all.

We saw earlier that rendering can happen in between tasks. But just because it can happen doesn't mean it must.

We can take a task, "Should we render?", "No, it can't be bothered yet."

Should we render? Not yet.

Go around the event loop, pick up another task. "Shall we render now?", "No, it doesn't feel like the right time". Many tasks can happen and before the browser goes, "Yeah, actually next time we will update the display".

Should we render? Now it's time.

And the browser gets to decide when to do this, and it tries to be as efficient as possible. The render steps only happen if there's something actually worth updating. If nothing's changed, it won't bother.

Like if the browser tab is in the background, if it isn't visible, it will never run the render steps because there's no point, but also the majority of screens update at a set frequency. In most cases that's 60 times a second. Some screens go faster, some screens go slower, but 60 Hertz is the most common.

So, if we changed page styles like a thousand times a second, it's not going to run the render steps a thousand times a second, it will synchronize itself with the display, and only render up to a frequency the display is capable of. Usually, 60 times a second.

Otherwise, it would be a waste of time, like there's no point rendering stuff the user will never see. But that's what setTimeout is doing here. It's moving faster because it's updating the position of that box more times than the user can see, more times than this display is capable of showing us.

Other ways of queuing a task #

So far, we've been using setTimeout as a shorthand for "queuing a task", and it isn't really, because even though we've put 0 milliseconds for the callback, it's more like 4.7 milliseconds that the browser will use as a default (the specs the browser can pick any number to use, but Jake has tested and measured it).

The three boxes being animated. The one labeled queueTask is moving so fast that it appears randomly positioned on its lane

There isn't a single method that just queues a task, but we can kind of fake it using message channels. Jake ran a test with that.

The result is there are so many tasks happening that it kind of just looks like the box is getting a random position. We're getting a task every two-hundredths (2/100) of a millisecond. So rendering can happen between tasks, but you can have many, even tens of thousands of tasks between renderings.

Tasks and frames in time #

Let's imagine each of these is a frame that is displayed to the user.

So, our rendering steps they happen at the start of each frame and that includes like style calculation, layout and paint, not necessarily all three every time.

Three frames, each one containing a style task (purple) and a render tasks (green)

Depends what actually needs updating, but I like this. I like this. This is very neat and tidy. This is a beautiful picture.

Tasks are executed everythere during a single frame

Tasks on the other hand, they couldn't give a stuff. They just kind of appear anywhere they fancy. The event loop ensures that they happen in the right order, they happen in the order they were queued, but in terms of timing within a frame there is no kind of ordering here at all.

And we saw this with our setTimeout. We were getting four per frame, three or four per frame, and that means that three-quarters of those callbacks were wasted effort in terms of rendering.

3 out of 4 tasks highlghted as wasted effort in terms of rendering

Old animation libraries used to do something like this, where they were trying to use a millisecond value that's going to give them roughly 60 callbacks per second...

setTimeout (animFrame, 1000 / 60);

...and they're assuming a lot about the screen there. They're assuming a screen is 60 Hertz, but that was the common case.

Tasks are scheduled in every frame using setTimeout

So, it kind of worked, it eliminated some of the duplicate effort. Unfortunately, it was a massive hack because setTimeout was not designed for animation and it really shows like due to inaccuracies you can end up with drift.

One task was supposed to be in the second frame, but was executed during the third frame

So, what's happened here is we're doing nothing in one frame, and then in the next frame we're doing twice the amount of work, and that is a visual jank to user, it doesn't look great.

Also, if one of your tasks runs long, you can end up moving the render steps around because it's all running on the same thread and you're sort of disturbing that lovely routine that they have.

Frames are starting inside each frame, the first one of them being executed over to the next frame

If we use requestAnimationFrame rather than setTimeout, it would look a lot more like this. All neat and tidy. All nice and ordered. Everything is within the timing of the frame, even this longer task here.

Tasks are grouped together at the beginning of every frame, using requestAnimationFrame instead of setTimeout

Jake says when he sees performance traces like this, it makes him happy, as this is showing a good user experience.

You can't avoid tasks completely of course because things like click events they're going to be delivered to you in a task, and generally you want to respond to those as soon as possible. But if you have things like timers or you have stuff coming from the network, Jake recommends using requestAnimationFrame to batch that work together, especially if you already have animations running because you can save yourself a lot of duplicate work.

Tasks and render timing #

There's one more detail I want to get to and this is something that catches a lot of developers out, it caught me out. requestAnimationFrame it comes before processing CSS and before painting.

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";
});

So, code like this might seem expensive, like we're showing and hiding a box many many times, but this is actually really cheap, like JavaScript will always run to completion before rendering happens.

So, while you're doing this the browser just sits back, and it lets you have your fun changing a value and it doesn't really think about it in terms of CSS at all. And then at the end when it actually comes around to the render steps it goes, right, what did you actually change in the end? And the only bit that matters is the final line. And the only bit that matters is the final line.

So the code above, in terms of rendering, is equivalent to the following code.

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

Animate a box? #

I'm omitting the part where Jake explained how to queue some Javascript to animate a box from 1000 to 500 pixels using a double requestAnimationFrame callback, as it's irrelevant at the time of writing: the Web Animation API, which was only available in Chrome at the time of Jake's talk, is now cross-browser.

Microtasks #

Back in the 1990s, browsers wanted to give developers a way to monitor DOM changes and the W3C gave us mutation events.

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

So, this is where I could say, okay, I want to know when a node is inserted into the body element. And you get a series of other events as well.

But, in practice this was pretty problematic. We take this bit of code here, what I'm doing is I'm adding a hundred spans into the body element.

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

How many events would you expect to receive as a result of this? One event? One event for the whole operation? Nope. 100 events? One for each span. Yes.

But also, another hundred for span.textContent = 'Hello'; when the text node is going into the span. And because these events bubble, this simple piece of code is going to land you with 200 events.

And because of this like relatively simple DOM modifications ended up triggering thousands of events and if you were doing like a tiny bit of work in these listeners that quickly became a big bit of work, and it was a performance disaster.

What we really wanted was a way to sort of hear about a batch of this work. And similar to what we saw with styles before. We want the browser to kind of sit back, let us do some stuff and then at a convenient point, say, some stuff changed. Here is a kind of an event or something to represent all of those changes.

We want to hear about it once, not 200 times. And the answer became mutation observers. And they created a new queue called microtasks.

A lot of documentation I read about microtasks suggests that it happens like, I don't know, every turn of the event loop or it happens after a task or something like that and it is kind of true. There is a single place on the event loop where microtasks happen, but that is not where you'll generally encounter it. They also happen whenever JavaScript finishes executing.

That means that the JavaScript stack has gone from having stuff in it to having no stuff in it and that's where we run microtasks.

So, you can end up with microtasks happening halfway through a task, you can have microtasks in the render steps as part of requestAnimationFrames, kind of anywhere, anywhere JavaScript can run.

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

So, that means this JavaScript will run to completion adding a hundred spans and their contents. JavaScript finishes executing and we get our mutation observer callback.

Promises made use of them as well.

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

So, here we queue a microtask and then log ‘Yo!’. JavaScript has finished executing. Then, we go for the microtasks, and we log ‘Hey!’.

And that means when the Promise callback is executing you were guaranteed that no other JavaScript is midway through at the time, the Promise callback is right at the bottom of the stack, and that's why Promises use microtasks.

An infinite loop with `Promise.resolve()` #

But what happens if we create a loop using microtasks? In terms of code, a bit like we did with setTimeout before.

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

Same demo again: a cat gif, a bunch of text, and a button labeled "Microtask Loop"

Click the button and... it blocks rendering, it blocks the tab in the same way a plain while loop did, but very different from setTimeout before.

So, Promise callbacks are async, fine, but what does async actually mean? All it means is that they happen after synchronously executing code, so that's why we get ‘Yo!’ before ‘Hey!’. But just being async doesn't mean it must yield to rendering, doesn't mean it must yield to any particular part of the event loop.

Three types of queues: Tasks, Animation Callbacks, Microtasks

We've looked at three different queues so far. We’ve looked at task queues, animation callback queues which is where requestAnimationFrame callbacks happen and now we're looking at microtasks. And just to make your lives a little bit easier they all are processed very subtly differently.

Like we've seen with task queues, we take one item and we take one item only. And if another item is queued it just goes to the end of the queue. Fine.

Additional item added to the task queue is not immediately processed

Animation callbacks they happen until completion, except ones that were queued while we were processing animation callbacks. They are deferred to the next frame.

All tasks of the requestAnimationFrame queue are processed, but not the newly added ones

Microtasks on the other hand they are processed to completion including any additionally queued items.

New microtasks keep being processed until the queue is empty

So, if you were adding items to the queue as quickly as you're processing them you are processing microtasks forever. The event loop cannot continue until that queue has completely emptied. And that is why it blocks rendering.

Conclusion #

I hope you found useful this transposition of Jake's talk into text! It really helped me to understand how browsers work under the hood.

It took me a while to write this, please consider buying me a coffee.

Web performance snippets to debug INP in Chrome dev tools

2024-02-14T00:00:00Z

A screenshot of an interaction debug in the performance trace. Credits: web.dev

After keeping them on my computer for some days, I decided to publish on GitHub this set of web performance snippets to debug INP in Chrome developer tools, or to report data to your analytics

👉 Find them here

Enjoy web performance debugging!

How to use scheduler.yield to improve web pages responsiveness

2023-08-31T00:00:00Z

Just a random yield image

In August 2023, Google introduced the scheduler.yield, which is available as an origin trial in Chrome 115 and later.

What is it #

scheduler.yield is a new feature in Chrome that allows web developers to explicitly tell the browser to yield control back to the main thread. This can be useful for tasks that are known to take a long time, as this allows other tasks to get time on the main thread sooner (than if they had to wait for long tasks to finish).

When you explicitly yield, you're telling the browser "Hey, I understand that the work I'm about to do could take a while, and I don't want you to have to do all of that work before responding to user input or other tasks that might be important, too".

This can help to improve the overall responsiveness of the web page, as the browser will be able to focus on other tasks while the long-running task is in progress.

And of course, this will come in handy when working on improving the Interaction to Next Paint (INP) web vital, which will become a Core Web Vital starting March 2024.

How to use it #

This is how you use it:

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

  // Yield!
  await scheduler.yield();

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

But wait, can you use it only in Chrome? Yes, but you could fall back to using the good old setTimeout and do something similar.

The only difference is browsers that don't support scheduler.yield will yield without "front of queue" behavior, as setTimeout sends the remaining work to the back of the task queue.

// 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:
  // ...
}

Want to try it? #

You can try scheduler.yield on your browser by enabling the "experimental web platform features" flag, as shown in the following image:

How to enable experimental web platform features in Chrome browser

And then, you will be able to use it:

How `scheduler.yield` looks when invoked in the developer tools console

Want to try it in production? #

You can! The scheduler.yield is - at the time of writing (September 2023) - in origin trial in Chrome 115 and later. You can learn more about origin trials and how to participate in the trial on the Chrome Developers website: Get started with origin trials.

Read the full article with a detailed explanation on the Chrome Developers blog: Introducing the scheduler.yield origin trial

Preparing for Interaction to Next Paint (INP), a new Core Web Vital starting March 2024

2023-07-12T00:00:00Z

Michelangelo's "Creation of Adam" painting

As a web performance consultant, I'm always on the lookout for new developments that impact the user experience of websites. One such upcoming change is the introduction of a new metric called Interaction to Next Paint (INP) by Google. Set to become a Core Web Vital in March 2024, INP is designed to measure the time it takes for a website to respond to user interactions. In this blog post, we will delve into what INP is, why it matters, and how companies can prepare themselves to ensure their websites meet this crucial web performance metric.

Understanding Interaction to Next Paint (INP) #

INP is an important addition to the Core Web Vitals, a set of metrics that Google uses to assess and rank websites based on their user experience.

Unlike other metrics such as Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS), which measure loading and visual stability, INP focuses on interactivity, meaning how quickly a website responds to user input after it has loaded. It quantifies the time it takes for the website to be ready to paint something after users interacted with them, and it aims to bring users an experience without any noticeable delays.

Why INP Matters #

In today's digital landscape, user expectations are higher than ever. People demand fast and seamless interactions when browsing the web, and any delays or unresponsive elements can result in frustration and abandonment. INP addresses this issue directly by measuring the time it takes for a website to respond to user inputs, which is a critical factor in delivering an exceptional user experience.

Moreover, Google has emphasized the importance of Core Web Vitals as a ranking factor for search engine optimization (SEO). Websites that provide better user experiences, as measured by these metrics, are more likely to rank higher in search results. With INP set to become a Core Web Vital, companies that prioritize website interactivity will not only enhance their user experience but also gain an advantage in search engine visibility.

Preparing for INP #

As the March 2024 deadline approaches, companies need to prepare for the inclusion of INP as a Core Web Vital. Here are some steps to ensure your website is ready:

Evaluate Current INP Performance: Start by assessing your website's current INP performance. The easiest way to check your website's INP values is via Google Search Console. Alternatively, you can try Chrome User Experience Report (CrUX) or PageSpeed Insights. Benchmark your current INP scores and set goals for improvement.
Improve INP: See next chapter to find out what to do to improve INP on your website.
Continuously monitoring and iterate: Web performance is an ongoing process, and it's crucial to monitor and measure INP regularly. Continuously analyze your website's performance, implement optimizations, and retest to ensure your INP scores meet the desired targets. Regularly review Google's developer documentation and community forums for updated best practices.

How to improve INP #

Let's get a little bit technical now. There are 3 types of actions you can take to improve INP on your website. Avoid or break up long tasks, avoid unnecessary JavaScript, and avoid large rendering updates.

Avoid or break up long tasks #

Tasks are any piece of discrete work that the browser does. Tasks include rendering, layout, parsing, and compiling and executing scripts. When tasks become long tasks—that is, 50 milliseconds or longer—they block the main thread from being able to respond quickly to user inputs.

Another option is to consider using APIs such as isInputPending and the Scheduler API. isInputPending is a function that returns a boolean value that indicates whether user input is pending. If it returns true, you can yield to the main thread so it can handle the pending user input. Check out isInputPending to yield only when necessary.

The Scheduler API is a more advanced approach, which allows you to schedule work based on a system of priorities that take into account whether the work being done is user-visible or backgrounded. Check out the Scheduler API.

By breaking up long tasks, you're giving the browser more opportunities to fit in critical user-visible work, such as dealing with interactions and any resulting rendering updates.

Avoid unnecessary JavaScript #

There's no doubt about it: websites are shipping more JavaScript than ever before, and the trend doesn't look like it's changing any time soon. When you ship too much JavaScript, you're creating an environment where tasks are competing for the main thread's attention. This can definitely affect your website's responsiveness, especially during that crucial startup period.

This is not an unsolvable problem, however. You do have some options:

Use the coverage tool in Chrome DevTools to find unused code in your website's resources. By reducing the size of the resources you need during startup, you can ensure your website spends less time parsing and compiling code, which leads to a smoother initial user experience. Check out the Coverage Tool.
Sometimes the unused code you find using the coverage tool is marked "unused" because it wasn't executed during startup, but is still necessary for some functionality in the future. This is code that you can move to a separate bundle via code splitting. Find out more about code splitting.
If you're using a tag manager, be sure to periodically check your tags to make sure they are optimized, or even if they're still being used. Older tags with unused code can be cleared out to make your tag manager's JavaScript smaller and more efficient. More best practices for tag managers.

Avoid large rendering updates #

JavaScript isn't the only thing that can affect your website's responsiveness. Rendering can be a type of expensive work in its own right—and when large rendering updates happen, they can interfere with your website's ability to respond to user inputs.

Optimizing rendering work isn't a straightforward process, and it often depends on what you're trying to achieve. Even so, there are some things you can do to ensure that your rendering updates are reasonable and don't sprawl into long tasks:

Avoid using requestAnimationFrame() for doing any non-visual work. requestAnimationFrame() calls are handled during the rendering phase of the event loop, and when too much work is done during this step, rendering updates can be delayed. It's essential that any work you're doing with requestAnimationFrame() is reserved strictly for tasks that involve rendering updates.
Keep your DOM size small. DOM size and the intensity of layout work are correlated. When the renderer has to update the layout for a very large DOM, the work required to recalculate its layout can increase significantly. Avoiding excessive DOM size.
Use CSS containment. CSS containment relies on the CSS contain property, which gives instructions to the browser about how to do layout work for the container the contain property is set on, including even isolating the scope of layout and rendering to a specific root in the DOM. It's not always an easy process, but by isolating areas containing complex layouts, you can avoid doing layout and rendering work for them that isn't necessary. More about CSS Containment.

Conclusion #

With Interaction to Next Paint (INP) set to become a Core Web Vital in March 2024, companies should start to prioritize website interactivity to deliver an exceptional user experience and improve search engine rankings.

By evaluating current INP performance, optimizing for interactivity, and continuously monitoring and iterating, businesses can prepare themselves for the upcoming change.

Embracing INP as a vital performance metric will not only benefit users but also contribute to the long-term success of their online presence.

Need a hand? #

If you want to know more about INP, how to optimize it, or you need web performance consultancy, feel free to reach out to me.

Talk: How and Why ($) to optimize web performance in 2023

2023-06-16T00:00:00Z

In 2023 I've been speaking about web performance at conferences, Google Developer Groups (GDG) and local meetups all over Europe. The title of this talk is "How and Why ($) to improve web performance, practical tips for 2023".

The first part of the talk is about the reasons why you should optimize web performance, and the second part is about how to do it, with practical tips coming from Google and based on data collected during the web performance chapter of the web almanac 2022.

Find below the slides of my talk, both in English and Italian language.

Slides in English 🇬🇧 · Slide in Italiano 🇮🇹

WaysConf, Kraków 🇵🇱 – 4 September 2023 #

Me explaining the difference between lab and RUM tools at WaysConf 2023

📺 Video · Conference talk page

Dev BCN Conference, Barcelona 🇪🇸 – 4 July 2023 #

Me presenting a slide about Core Web Vitals on stage at the Dev BCN conference

Conference talk page

DevFest, Vienna 🇦🇹 – 14 October 2023 #

Me on stage explaining what is Interaction to Next Paint

DevFest schedule

Google Developer Group, Munich 🇩🇪 – 7 June 2023 #

Me speaking in front of the audience in Google Munich

Event page

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

Me speaking in front of the audience at Nana Bianca, Firenze

Italian title: Come e perché ($) migliorare le Prestazioni Web: consigli pratici per il 2023".

Event page

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

Me on stage at the Bologna event

Italian title: "Come e perché ($) migliorare le Prestazioni Web: consigli pratici per il 2023".

📺 Video · Bologna JS event page · GDG event page

Dev Romagna, Imola 🇮🇹 – 22 March 2023 #

The location and the audience during the presentation of the Dev Romagna group

Italian title: "Come e perché ($) migliorare le Prestazioni Web: consigli pratici per il 2023".

Dev Romagna event page

Google Developer Group, Turin 🇮🇹 – 23 February 2023 #

1 second loading time improvement can improve the website conversion rate and reduce the bounce rate

The beautiful audience in Turin

Italian title: "Web Talks: from Design to Performance".

Event page

Bologna front-end, Bologna 🇮🇹 – 15 February 2023 #

Me on stage at the Bologna Front-end event

Italian title: "Web performance per tutti".

📺 Video · Event page

I'm a Google Developer Expert for Web Performance

2022-12-06T00:00:00Z

In December 2023 I became a Google Developer Expert (GDE) for Web Performance. Google Developer Experts is a Google program to create a global network of professionals, influencers, and thought leaders, and enable them to share their knowledge with the developer community, like speaking at events, sharing best practices, and mentoring others.

The Google Develoeper Experts logo

By joining the GDE program, I joined a community of passionate technologists from around the world, allowing me to network with them and Google teams.

In addition to getting featured in the Google Developer Experts directory, I will get early access to products and web-performance-related news.

Feel free to reach out if you want to talk about the program or web performance.

aspect-ratio: A modern way to reserve space for images and async content in responsive design

2022-11-19T00:00:00Z

To avoid layout shifting and optimize for the Cumulative Layout Shift web vital in you web pages, you need to reserve space for any content that might be rendered later in time. This is the case for images, videos and any asynchonously loaded content (e.g with AJAX calls). Here's a new way to do it.

The good old way #

The traditional way to reserve space for images is to use the vertical padding trick.

<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;
}

The modern way 1 - mapped `aspect-ratio` #

The modern and simpler way is to define a width / height aspect ratio implicitly by defining the width and height attributes on images and videos. This is called "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);
}

The good news is that either Chromium browsers (Chrome, Microsoft Egde, and Opera), Firefox and Safari (starting version 14) now support mapped aspect-ratio! So the vast majority of browsers is covered, and Internet Explorer is slowly dying, while Microsoft Edge is ramping up.

But there are some caveats when using JavaScript-powered lazy loading.

Demos #

I've created a set of demos on Codepen to test mapped aspect-ratio in different cases.

Use case	Works?	Demo
Native lazy loading (no placeholders required)	🟢 Yes	Demo
Javascript lazy loading (no placeholders, no `display` fix)	🔴 No	Demo
Javascript lazy loading (no placeholders, with `display` fix)	🟢 Yes	Demo
Javascript lazy loading (SVG placeholders, no `display` fix)	🟢 Yes	Demo

With display fix I mean I needed to set the images display property to block, because leaving its value to the default one (inline-block) didn't work out for Javascript lazy-loaded images.

With "Works?" I mean if the browser reserved space for the images before they were loaded. To check if it works yourself, use your browser's developer tools to disable the cache and emulate a "slow 3G" network speed. You should see some space is reserved before the images start loading, so the paragraph is rendered way below the images.

The modern way 2 - explicit `aspect-ratio` #

In the future, you will also be able to explicitly set the aspect ratio in your CSS code using the aspect-ratio CSS rule.

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

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

~~Unfortunately, this has currently (April 2021) supported only by Chromium browsers. We still don't know if and when this will be supported in future versions of Safari.~~

November 2021 update: this is now supported by all latest versions of all browsers (except for Internet Explorer, but... well).

Conclusion #

Yay! It is possible to use mapped aspect-ratio to reserve space for your lazily loaded content like images and videos today!

Just set the width and height attributes to images and pick one of the following three ways:

Use native lazy loading with loading=lazy
Use JavaScript lazy loading with no placeholders, but applying display: block to the images
Use JavaScript lazy loading with placeholders

I can't wait to know how you reduced your pages' CLS using these techniques. Please reach out and let me know!

Against online streaming of local meetups.

2022-11-19T00:00:00Z

I like to take part to local meetup events. They are informative, fun, and socially engaging at the same time. Sometimes, the meetup organizers get asked to stream events online. It would be a cool feature, I guess, but if you ask me, it would do more harm than good the community. Let me explain why.

Listening to the meetup topic in person, together with other people who share your interests, focused on the speaker and her/his slides, it's a type of experience. Watching to such an event at home, in front of a screen, alone, with distractions calling for your attention, far from where the event is happening, is a much weaker type of experience.

You could easily find some blog posts or online tutorial about the same topic of the meetup event, most likely of a better quality. The real value of in-person meetup lies in socialising, networking, in the exchange of ideas that happens before and after the talk, and if you want, at the pizza place afterwards.

Furthermore, the fact that an event would also be streamed online, weakens the event in person. One might think “Hey, who is making me go to the city, I can see it in live streaming. Then when it's time "Hey, who is making me watch it live, I'll see the recording later". Then "Ah, why would I watch the recording, I'll watch an online tutorial". Maybe.

If we talk about conferences, however, there are some differences. Conferences can be online, but I think they have to be online or offline, not both. Online conferences may have a larger audience, even worldwide, and may reduce costs for attendees, they are more accessible to those with mobility impairments, but in my opinion in-person conferences are the best, for the same reasons: being together with people sharing your interests, exchanging ideas, etc.

And you, what do you think? Feel free to reach out and let me know!

Do we still need lazy loading libraries and `data-src`?

2022-11-13T00:00:00Z

Back in the day, when browser support for native lazy loading wasn’t widespread, the best practice was to use data-src attributes and a JavaScript library like my vanilla-lazyload to load images as they entered the viewport. Is this still best practice today?

What is lazy loading? #

Lazy loading images is a technique to defer the loading of below-the-fold images until they are about to enter the viewport (the visible portion of the page). This technique saves bandwidth, reduces CDN costs, lowers the website's carbon footprint, and improves page rendering time, particularly the Largest Contentful Paint.

JavaScript-driven image lazy loading #

Traditionally, lazy loading images involved replacing the src attribute with a data-src attribute and using JavaScript to detect when the images are nearing the viewport, then copy the data attributes into the proper ones, triggering their deferred loading.

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

Native lazy loading #

With native lazy loading, AKA browser-level lazy loading, simply add the loading="lazy" attribute to the <img> tag.

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

This works on all modern browsers.

Do we still need JavaScript-driven lazy loading? #

No, unless you want greater control over the lazy loading process.

Let's see what are the cases for using JavaScript-driven lazy loading, instead of just using loading="lazy".

1. Supporting users on slow or faulty connections #

JavaScript libraries like vanilla-lazyload can cancel the download of images that leave the viewport and retry downloads if interrupted, enhancing the user experience on slow connections.

A use case for that is:

pages with many images +
users on slow connections +
fast scroll down

Native lazy loading makes browsers download lazy images from top to bottom, resulting in a delay to show the bottom images.

Javascript libraries like vanilla-lazyload will cancel the download of images that exit the viewport, keeping users' bandwidth focused on the images currently in the viewport.

Another use case is:

images downloading
network connection interrupted

vanilla-lazyload will retry downloading those images when the network connection is restored.

You can try these features on any of the vanilla-lazyload demos, like the basic case demo, and throttling or disabling your connection speed in the developer tools of your browser.

2. Advanced callbacks or CSS classes #

JavaScript-driven lazy loading provides callbacks and CSS classes for various events (start loading, finish loading, error, enter viewport, exit viewport, etc.), allowing for enhanced visual effects and monitoring.

Those callbacks and CSS classes can be very helpful to create visual effects on your page.

Find more about callbacks and classes in vanilla-lazyload API / options.

3. Optimizing web performance, specifically Largest Contentful Paint #

JavaScript-driven lazy loading offers more control over which images are downloaded, helping to optimize the Largest Contentful Paint (LCP).

With native lazy loading, you don't have control over what images get downloaded from the browser.

The use case:

some images are below-the-fold but not far off
some images barely appear in the visible portion of the page

Native lazy loading would start downloading those images, which will share the bandwidth with the download of your LCP image, while you want to download the latter with the highest priority.

JavaScript-driven lazy load like vanilla-lazyload provide APIs and options to fine-grain control how far off-the-viewport images should be to start downloading.

4. Lazy loading other assets #

For lazy loading background images, videos, animated SVGs, and more, a JavaScript library like vanilla-lazyload is still required.

Find out more #

Check the vanilla-lazyload documentation or my blog post lazy load responsive images in 2020.

Talk: Get speedy with responsive images - LazyLoad Conference 2022

2022-06-24T00:00:00Z

This is a frame of the video, before I dove into the technical parts

On June 24th 2022, I spoke about responsive images optimisation 4.0 at the LazyLoad conference 2022.

The talk was about how to improve performance on your website by automating responsive images, with a data-driven approach. Here's the video of my talk.

The tool mentioned in the the talk is responsive-images-automator.

Talk: Images optimisation 4.0, automate your work with a user-centric approach - CSS Day 2022

2022-04-01T00:00:00Z

Me on stage at CSS Day 2022, Faenza

On April 1st 2022 I spoke about responsive images optimisation 4.0 at the CSS Day 2022 Conference in Faenza, Italy. This talk – in Italian language – is on how to become more productive by automating responsive images. Here's the video of my talk. It's in Italian language only.

The tool the talk was about is responsive-images-automator.

The talk was rated very positively! Read feedback on joind.in.

Find below the slides of this talk.

How to integrate git in Mac OS Terminal (shell)

2022-03-11T00:00:00Z

Now that zsh is the default shell on Mac OS terminal, you might want to setup you new Mac or VS Code terminal to have a smart integration with git, something similar to git bash for 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">

Mac OS Terminal with git integration

After searching around for a while and finding tools to integrate with bash, I finally found this article that offers an explanation on how to integrate git with zsh in Mac OS Terminal (or shell).

Since zsh ships with a framework for getting information from version control systems, called vcs_info, you can include the branch name in the prompt on the right side, add these lines to your ~/.zshrc file:

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 is powerful enough that there are entire frameworks dedicated to making it better. One of them is called oh-my-zsh. oh-my-zsh’s plugin system comes with powerful git tab-completion, and it has a variety of prompt "themes", many of which display version-control data.

You can install oh-my-zsh running fhe following command:

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

Enjoy your new zsh terminal integrated with git commands!

An elegant technique to lazyload images in Swiper, and lazily create Swiper instances

2021-10-27T00:00:00Z

Say you have multiple carousels in a page, each one containing multiple images, and you want to download only the images that are inside the visible portion of the page, and maybe save some CPU time by lazily create the carousel instances. I think I’ve found a valuable and elegant technique to do so.

The following technique is about lazy loading images inside an instance of Swiper JS, and also lazily creating the Swiper instances below-the-fold, using Swiper with vanilla-lazyload.

The HTML code of the first carousel sets a couple of images as eagerly loaded so browsers will prioritize their downloading, and it leaves all the rest to lazy loading.

<div class="swiper swiper--eager">
	<div class="swiper-wrapper">
		<!-- Eagerly loaded images -->
		<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>
		<!-- Lazy loaded images -->
		<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>

From the second carousel on, all the images are to be lazily loaded.

<div class="swiper swiper--lazy" id="swiperLazy1">
	<div class="swiper-wrapper">
		<!-- All lazy loaded images -->
		<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>

Here goes the JavaScript code that makes the magic.

const swiperOptions = {
	loop: true,
	slidesPerView: "auto",
	navigation: {
		nextEl: ".swiper-button-next",
		prevEl: ".swiper-button-prev",
	},
	on: {
		// LazyLoad swiper images after swiper initialization
		afterInit: (swiper) => {
			new LazyLoad({
				container: swiper.el,
				cancel_on_exit: false,
			});
		},
	},
};

// Initialize the first swiper right away
const eagerSwiper = new Swiper(".swiper--eager", swiperOptions);

// Initialize all other swipers as they enter the viewport
new LazyLoad({
	elements_selector: ".swiper--lazy",
	unobserve_entered: true,
	callback_enter: function (swiperElement) {
		new Swiper("#" + swiperElement.id, swiperOptions);
	},
});

I tested it by emulating a "slow 3G" connection, and I like the waterfall of network calls and the optimal value of the Largest Contentful Paint.

Try it live here.

vanilla-lazyload vs lazysizes

2021-09-26T00:00:00Z

As the author of vanilla-lazyload, it's not the first time I get asked the question: What are the differences between vanilla-lazyload and lazysizes? This blog post is the answer to that question.

What are vanilla-lazyload and lazy sizes? #

vanilla-lazyload and lazysizes are two popular Javascript libraries to lazyload images and other DOM elements, meaning load them only when they enter the visible portion of the web page (the browser viewport), or a little bit earlier than they do.

Using one of them is very important to improve the rendering time of your website by delaying the loading of all non-critical content to later, in order to get better Core Web Vitals and particularly to reduce the Largest Contentful Paint.

So what are the differences between vanilla-lazyload and lazysizes? What follows is a detailed comparison of the two.

vanilla-lazyload and lazysizes compared #

Find the main features of vanilla-lazyload compared to lazysizes' in the table below.

It	vanilla-lazyload	lazysizes
Is lightweight (source: bundlephobia)	✔ (2.8 kB)	✔ (3.4 kB)
Is extendable	✔ (via API)	✔ (via plugins)
Is SEO friendly	✔	✔
Optimizes performance by cancelling downloads of images that already exited the viewport	✔
Retries loading after network connection went off and on again	✔
Supports conditional usage of native lazyloading	✔
Works with your DOM, your own classes, and data-attributes	✔
Can lazyload responsive images	✔	✔
...and automatically calculate the value of the `sizes` attribute		✔
Can lazyload iframes	✔	✔
Can lazyload videos	✔
Can lazyload background images	✔
Can lazily execute code when given elements enter the viewport	✔
Can restore DOM to its original state	✔

Table rows explained #

Is extendable #

Both vanilla-lazyload and lazysizes are extendable, see vanilla-lazyload API and lazysizes plugins.

Is SEO friendly #

Both scripts don't hide images/assets from search engines. No matter what markup pattern you use. Search engines don't scroll/interact with your website. These scripts detect whether or not the user agent is capable to scroll and if not, they reveal all images instantly.

Optimizes performance by cancelling downloads of images that already exited the viewport #

If your mobile users are on slow connections and they scroll down fast, vanilla-lazyload cancels the download of images that are still loading but already exited the viewport. Although if for some reason you don't want this to happen, this feature can be turned off.

Retries loading after network connection went off and on #

If your mobile users are on flaky connections and go offline and back online, vanilla-lazyload retries downloading the images that errored.

Supports conditional usage of native lazyloading #

If your users are on a browser supporting native lazyloading and you want to use it, with vanilla-lazyload you can conditionally activate it by setting the use_native option to true. Find here more information and the conditional native lazyload demo.

Works with your DOM, your own classes and data-attributes #

Both scripts work by default with the data-src attribute and the lazy class in your DOM, but on vanilla-lazyload you can change it, e.g. to data-origin, if you want to migrate from other lazy loading scripts to vanilla-lazyload without changing your HTML markup.

Can lazyload responsive images #

Both vanilla-lazyload and lazysizes can lazyload responsive images by all kinds, the simple img tag and the picture tag with multiple source tags.

For more information, check out lazy load responsive images in 2020 by yours truly.

...and automatically calculate the value of the `sizes` attribute #

The lazysizes script has a function that can spare you the "fatigue" of writing the value of the sizes attribute in your HTML markup. By placing a data-sizes="auto" in your images markup, it can derive its value via Javascript from your CSS.

This is a missing feature vanilla-lazyload for a reason. To make browsers display your website's content as fast as possible, you will have to mix lazy loading and eager loading (eager being the opposite of lazy). The best practice here is to eagerly load images above-the-fold and lazy loading the ones below-the-fold. In the eagerly loaded images you will have to put a sensible value of the sizes attribute. This means that you will have to calculate that value anyway and, once you did that, what is the use of calculating its value using JavaScript? You can use the value you calculated both for your eager images and your lazy ones.

Can lazyload iframes #

Both vanilla-lazyload and lazysizes can lazyload the iframe tag.

Can lazyload videos #

Only vanilla-lazyload can lazyload the video tag, even with multiple sources.

See lazy video in vanilla-lazyload documentation for more.

Can lazyload background images #

Only vanilla-lazyload can lazyload background images, even multiple background images. It also has a way of supporting HiDPI displays such as Retina and Super Retina displays.

Check lazy background images in vanilla-lazyload documentation for more.

Can lazily execute code when given elements enter the viewport #

Only on vanilla-lazyload you can execute code when given elements enter the visible portion of the page.

Check out the lazy functions section in vanilla-lazyload documentation for more.

Can restore the DOM to its original state #

Sometimes you need to clean up your DOM before unloading it and soft-navigating to another page, e.g. when using TurboLinks.

vanilla-lazyload allows you to restore all DOM it manipulated to its original state by calling the restoreAll() method.

Conclusion #

vanilla-lazyload has more features you can use to lazyload images, background images, videos and iframes, it's optimised for slow connections, it automatically retries loading images after a network down, supports conditional native lazy loading, can execute code lazily, and restore your DOM to its original state.

On the other hand, lazysizes is extendable and it has the ability to automatically calculate your images sizes attribute if you don't want to.

Links:

Quicklink case study: faster pages, increased page views

2021-06-18T00:00:00Z

QuickLink is a lightweight library created by Addy Osmani (Google) that prefetches pages linked to the current page, as the links to those pages enter the visible portion of the page (viewport).

We used Quicklink on some of our ecommerce websites to improve the rendering time of our product detail pages (PDPs), with good results both on performance and business KPIs.

Continue reading on Medium

A clever way to serve WebP images to modern browsers and JPG to IE

2020-11-29T00:00:00Z

Before the day Safari started to support WebP images, we were forced to use the picture tag to serve WebP images to browsers supporting it. Today all modern browsers support WebP, so there's probably a clever way to do that using a single tag: img.

How we did it before #

The old way to do that was using a picture tag containing the regular img tag with both src and srcset attributes for browsers not supporting WebP, and a sibling source tag - marked with the type="image/webp" - containing the srcset for browsers accepting the WebP image format.

Long story short, this:

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

But Safari is more modern now #

Now that all modern browsers support WebP, we can assume that all browsers that support the srcset attribute also support WebP. So we can get rid of the picture tag and use a single img tag.

Like this:

<img
    alt="New, clever way"
    src="{url-standard}.jpg"
    srcset="
        {url-standard}.webp 1x,
        {url-retina}.webp   2x
    "
/>

Legacy browsers fallback to the src attribute, and they get the Jpg image. Simple as that.

Advantages #

The first, more obvious advantage is you need to write and maintain less HTML markup.

A second advantage you could have is if you were using an image CDN to automatically serve the correct image format depending on the browser requesting it. If you were, you can probably get rid of that and save some time and money.

Compatibility #

If you're supporting versions of iOS older than 14, you probably want to continue using the picture tag to to so. This depends on the audience you're targeting. Find more about your audience using Google Analytics data.

How to cap image fidelity to 2x and save 45% image weight on high-end mobile phones

2020-11-11T00:00:00Z

With the rise of very high density “super retina” displays in the newest high-end devices, capping image fidelity to 2x leads to a big improvement in terms of rendering speed, and no perceivable quality loss for your users. Here’s a new best practice on how to do that.

Images x screen densities #

In June 2010, Apple introduced the first Retina display on the iPhone 4. “Retina” is just a fancy name to describe a HiDPI display, which has 2x the pixels horizontally and 2x vertically.

HiDPI displays are perfect when having to render vectors like fonts and SVG images, but when it comes to images, if we don’t provide a specific image for HiDPI displays, our regular image gets stretched to cover all the additional pixels. And stretched images don’t look good.

So the first thing we started doing was to provide both a standard image and an image optimized for Retina displays, using the srcset attribute and the x descriptor. Like this:

<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"
/>

That x descriptor in the srcset attribute is to match sources to screen densities. 1x means “this is the image for regular screens”, 2x means “this is the image for HiDPI / Retina displays”. Depending on the device’s screen, browsers will pick the corresponding source.

Responsive images #

Responsive images is an HTML specification that allows us to serve the correct image size to users, depending on the space the image occupies on the user’s screen, and taking the device pixel ratio into account.

The simplest way to code responsive images is to list all the image sizes we have in a srcset attribute, using the w descriptor, and tell the browser how big is our image, using the sizes attribute. Browsers will do the math and will download the most appropriate image.

<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"
/>

Additionally, when the size of your images changes depending on media queries, we can add the same media queries in the sizes attribute.

<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"
/>

If you feel confused, I recommend you to read Srcset and Sizes from Eric Portis. That article lighted my way when I was starting to play around with responsive images.

Devices with 3x displays #

At the time I am writing this article, there's a bunch of high-end devices, both from Apple and Google, mounting a HiDPI display with 3x pixel density or more. Apple calls them Super Retina displays, Google calls them FHD+ displays.

Devices with super HiDPI displays

Apple launched their first Super Retina display with the iPhone X, the same kind of display is mounted in the iPhone XS / Max, iPhone 11 Pro / 11 Pro Max, and on all the phones in the iPhone 12 line-up, including the 12 Mini.

Google Pixel phones have their FHD+ displays with a 3x pixel density, and QHD+ displays with a pixel density of 3.5x on the Pixel 4 XL.

Capping image fidelity #

According to the analysis on a Twitter mobile app change, capping image fidelity to 2x leads to a significant improvement in terms of rendering speed and no perceivable quality loss for your users.

Images in timelines on ultra-high resolution devices now load roughly 33% faster while using 1/3rd less data, and with no visible quality change.

The problem with doing responsive images using the img tag, as we saw above, is there is no way to stop browsers from downloading the 3x image. The reason is that to determine which image to download from the srcset, they do the following calculation:

width of the image on screen × device pixel density = width of the image to download

So for example, if an image has to be displayed at a width of 300px on an iPhone 12, browsers would do the following calculation:

300 × 3 = 900

And they would download the 900-pixels-wide image. What we want is to cap the fidelity to 2x so that it downloads the 600-pixels-wide image instead.

The only way to do that on the web is to use the picture tag like the following:

<picture>
	<!-- Landscape tablet / computers -->
	<source
		media="(min-width: ####px)"
		srcset="batman_###w.jpg 1x, batman_###w.jpg 2x"
	/>
	<!-- Portrait tablet / landscape smartphone -->
	<source media="(min-width: ###px)" srcset="batman_###w.jpg 2x" />
	<!-- Larger smartphone(s) -->
	<source media="(min-width: ###px)" srcset="batman_###w.jpg 2x" />
	<!-- Smallest smartphone -->
	<img
		src="batman_###w.jpg"
		srcset="batman_###w.jpg 2x"
		alt="Batman Super-man and Wonder"
	/>
</picture>

Note: I replaced the real numbers with a ### placeholder because those numbers are not relevant to this explanation.

Notice that:

on the smartphones media queries, we describe only the 2x image because all smartphones mount a retina display nowadays
on the landscape, tablet and computers media query, we should describe both the 1x and 2x images.
the src attribute on the img tag is required, but it will be used only by legacy browsers, IE 11 included

Optionally reduce complexity on tablets and computers media queries #

If your layout requires you to do more than 1 media query for tablets and computers, you should then consider using the srcset attribute with the w descriptor and the sizes attribute, which leads to this:

<picture>
	<!-- Landscape tablet / computers -->
	<source
		media="(min-width: ###px) "
		sizes="(min-width: ###px) 33vw, 50vw"
		srcset="
            batman_####w.jpg ####w,
            batman_####w.jpg ####w,
            batman_###w.jpg   ###w
        "
	/>
	<!-- Portrait tablet / landscape smartphone -->
	<source media="(min-width: ###px)" srcset="batman_###w.jpg 2x" />
	<!-- Larger smartphone(s) -->
	<source media="(min-width: ###px)" srcset="batman_###w.jpg 2x" />
	<!-- Smallest smartphone -->
	<img
		src="batman_###w.jpg"
		srcset="batman_###w.jpg 2x"
		alt="Batman Super-man and Wonder"
	/>
</picture>

In this way, from the landscape tablets and computers media query and above, you won’t need to add other source tags, because there’s no need to cap image quality on computers. The upmost source tag does the trick.

“That’s a lot of markup for one image”, you say? #

If you are using responsive images you probably already have considerably large img tags, each one listing a set of image URLs in the srcset attribute, and a set of media queries and sizes in the sizes attribute. The code listed above can be slightly larger, but not significantly.

That said, tools like GZip and Brotli — which are working out of the box in most applications servers and CDNs — do a great job at compressing repeated characters in markup, and there are lots of repeated characters in those image tags.

I did a test and I found out that an HTML file containing 54 images weighs 37 kb uncompressed, but it only weighs 530 bytes GZipped. If you compare this to the 45% data savings on the downloaded images, that’s probably a good trade-off.

Result: 45% lighter images #

Using this technique on the product listing page of one of the websites we manage led to an image weight reduction of 45%. Images weight on an iPhone 11 Pro was 1.7 Mb before and it’s only 949 kb after the capping.

Images weight before (left) and after the capping (right)

Demos #

I’ve created a GitHub repo and a Codepen. Feel free to try and fork them.

Single image with fidelity capped to 2x:

Or try the page shown in the video above.

🌟 Open the live demo 💻

Psst! You can still lazy-load images #

One of the best practices to minimize your website’s Largest Contentful Paint is to eagerly load the above-the-fold images, lazy load below-the-fold ones. You can do that by using data-src, data-srcet, data-sizes instead of src, srcset, sizes both in the img and in the source tags.

<picture>
	<!-- Landscape tablet / computers -->
	<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
        "
	/>
	<!-- Portrait tablet / landscape smartphone -->
	<source media="(min-width: ###px)" data-srcset="batman_###w.jpg 2x" />
	<!-- Larger smartphone(s) -->
	<source media="(min-width: ###px)" data-srcset="batman_###w.jpg 2x" />
	<!-- Smallest smartphone -->
	<img
		data-src="batman_###w.jpg"
		data-srcset="batman_###w.jpg 2x"
		alt="Batman Super-man and Wonder"
	/>
</picture>

More about lazy loading responsive images.

To wrap up #

In web design with responsive images, capping image fidelity on super HiDPI devices is a relatively new best practice, because of the growing number of smartphones spoiling super HiDPI displays.

Capping image fidelity will improve the rendering speed of your website, as well as your users’ experience and your pages’ Largest Contentful Paint metric.

How to optimise for CLS when loading more content asynchronously

2020-08-31T00:00:00Z

Cumulative Layout Shift (CLS) is an important, user-centric metric for measuring visual stability because it helps quantify how often users experience unexpected layout shifts — a low CLS helps ensure that the page is delightful.

What you might not know is:

CLS is measured continuously. In fact, its value is also updated while your users scroll your page, if the scroll generates some layout movement
CLS measurement is paused for 500ms whenever a user interaction like a click or a keyboard event occurs

Long story short, Cumulative Layout Shift measures every unexpected layout movement occurring while your users interact with the page, including while they scroll down.

When loading more content in our pages, the most common source of CLS is the page footer becoming visible for a while, then being pushed below-the-fold again by new, dynamically added content.

So how to keep CLS from growing when we need to load new content dynamically, e.g. to load a whole new page of products?

Continue reading on Medium

Lazy load responsive images in 2020

2020-05-24T00:00:00Z

Do you want to boost performance on your website? You can do that by using responsive images and lazy loading! In this article, you will find the HTML, JavaScript, and CSS code to lazy load responsive images, to make browsers use modern image formats like WebP and Jpeg2000, and to enable native lazy load where supported.

Definitions #

Responsive images are img tags that download the right image source depending on your design and the user's device. You can provide information about your design in the sizes attribute and a list of image sources in the srcset attribute. You can also use media queries by wrapping your img in a picture tag. More about responsive images in the MDN.

Lazy loading images is a technique that makes your website render faster by deferring the loading of below-the-fold images to when they enter the viewport. Beyond performance, this also allows you to save bandwidth and money, e.g. if you're paying a CDN service for your images.

Above-the-fold first #

Bear in mind that using a script to lazy load images is a Javascript-based task and it's relevantly slower than the regular image loading (eager loading from now on) which starts as soon as the HTML document is being parsed.

☝️ For this reason, the best practice is to eagerly load above-the-fold images, and lazy load only the below-the-fold images.

At this point, people usually ask:

💬 My website is responsive, how do I know how many images will be above-the-fold at page landing?

The answer is: count them! Open the web page in a browser, resize the viewport to the most common dimensions (smartphones, computers, and tablets) maybe using the device emulation tool, and count them.

If you can see 4 images above-the-fold in a smartphone viewport, plus only the tip of 4 more images on a desktop viewport, be conservative and eagerly load only 4.

Now to some code! #

Here's the HTML markup of an eagerly loaded responsive image.

<!-- Eagerly loaded,
     above-the-fold only -->
<img
  alt="Eager above"
  src="220x280.jpg"
  srcset="
    220x280.jpg 220w,
    440x560.jpg 440w
  "
  sizes="220px"
/>

And here's the markup to lazy load a responsive image.

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

Want to show a low-resolution preview while your lazy images are loading? You can do that by using a small, low-quality image in the src tag, like the following.

<!-- Lazy loaded,
     + low-res preview,
     below-the-fold only -->
<img
  alt="Lazy below with preview"
  class="lazy"
  src="11x14.jpg"
  data-src="220x280.jpg"
  data-srcset="220x280.jpg 220w,
    440x560.jpg 440w"
  data-sizes="220px"
/>

Open the 👀 demo, then your browser's developer tools, then switch to the Network panel. You will see that the first 2 images are eagerly loaded just after page landing, while the rest of the images are lazily loaded as you scroll down the page.

We're using the img HTML tag and not the picture tag, given that the latter is not necessary in this case. I'll dig into the picture tag use cases later in this article. ⏩ Skip to picture tag use cases

Script inclusion #

To load the lazy images as they enter the viewport, you need a lazy load script such as vanilla-lazyload which is a lightweight (2.5 kb gzipped), blazing-fast, configurable, SEO-friendly script that I created and I've been constantly improving since 2014.

Here is the simplest way to include it in your page.

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

Have a look at the documentation for more ways to include LazyLoad in your web pages, like using an async script with auto-init, using RequireJS, using WebPack or Rollup.

LazyLoad initialization #

Including the vanilla-lazyload script gives you a LazyLoad JS class you can use to load the images identified by the lazy CSS class. You must create a LazyLoad instance like this:

var lazyLoad = new LazyLoad({
  // Your custom settings go here
});

Minimize layout reflow #

When using lazy loading, the images that haven't started loading collapse to 0-height, only to grow when they'll have started loading. Layout reflowing would make your website janky, so it's a best practice to stabilize your layout by occupying the exact amount of space your images will take when loaded, before they start loading.

The universal solution to do that is to use the vertical padding trick, while in the future you'll be able to use the aspect-ratio CSS directive to do it (as I'm writing it's landed in Chrome Canary only).

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

Here's also a useful SASS mixin to do that (source: 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;
  }
}

More info in Sizing Fluid Image Containers with a Little CSS Padding Hack by Andy Shora.

Avoid "broken" images #

To avoid lazy images to appear as broken, even for a short amount of time, use CSS. Hide the images that still don't have neither an src nor a srcset attribute set.

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

No polyfills required #

You might be tempted to add one or more polyfills to support Internet Explorer (yes, I named it and it's 2020). Don't do that, you don't need any. Let me tell you why:

Responsive images: Internet Explorer does not support responsive images, but you don't need to use a polyfill because IE gracefully degrades using the image specified in the src attribute. So choose an image that would appear nice on a regular desktop display, place in the src attribute, and you're cool.
IntersectionObserver: Internet Explorer does not support the IntersectionObserver API, which is used by vanilla-lazyload, but you don't need to provide a polyfill because vanilla-lazyload will detect the support for that API and, if missing, it will loads all images immediately. This leads to the same result as if no LazyLoad was ever used on the page, but it doesn't throw any errors.

That's cool, Internet Explorer is not being used by more than 5% of the users today, and Microsoft is silently replacing it with Edge via Windows Update.

Anyway if for some reason you want it to work in the same exact way on Internet Explorer, you can use the IntersectionObserver polyfill by including it before vanilla-lazyload.

<!-- Don't do this if you're not sure! Read above -->
<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>

Putting it all together #

For your convenience here's all the HTML, JS, and CSS code together.

<!-- Eagerly loaded,
     above-the-fold only -->
<img
  alt="Eager above"
  src="220x280.jpg"
  srcset="
    220x280.jpg 220w,
    440x560.jpg 440w
  "
  sizes="220px"
/>

<!-- Lazy loaded,
     below-the-fold only -->
<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
});

/*
Images container to occupy space
when the images aren't loaded yet
*/
.image-wrapper {
  width: 100%;
  height: 0;
  padding-bottom: 150%;
  /* ☝️ image height / width * 100% */
  position: relative;
}
.image {
  position: absolute;
  /* ...other positioning rules */
}

/*
Hide "broken" images before
they start loading
*/
img:not([src]):not([srcset]) {
  visibility: hidden;
}

And that's it for the simple img tag.

Picture tag use cases #

Until now, I wrote about the img tag with the srcset and sizes attributes, which is the solution to the vast majority of the responsive images you might need to use on a website or web application. Now, in which cases should you use the picture tag?

Different width/height ratio #

Use case: you need to show images with different width/height ratio depending on a media query. e.g. you want to show portrait images on mobile, vertical devices, landscape images on wider viewports, like tablets and computers.

Here's the code you're gonna need in this case. In order to have eagerly loaded images, just use the plain src and srcset attributes, without data- prefix.

<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="Portrait or landscape"
    data-src="1024x576.jpg"
  />
</picture>

Open the 👀 demo, then your browser's developer tools, then switch to the Network panel. You will see that it downloads only the image source corresponding to the first matching media query.

Load modern formats like WebP and Jpeg2000 #

Use case: you want browsers to choose the source to load a modern format like WebP and Jpeg2000 depending on its support for that format.

You need the source tag and the type attribute containing the MIME type of the images in the data-/srcset attribute.

<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 or Jpg"
    class="lazy"
  />
</picture>

Open the 👀 demo, then your browser's developer tools, then switch to the Network panel. You will see that it downloads only the image source corresponding to the first type that your browser supports.

💬 Isn't that markup too long for one image?

Yes, it is. And if you have money to invest in image optimization, there other ways to do that. Most of the cloud-based image servers in the market now automatically serve different image formats at the same URL. This means that you can request 1024x576.jpg and you get a WebP or a Jpeg2000 accordingly. Cloudinary and Akamai Image & Video Manager do that, amongst others.

Image fidelity capping to 2x #

With the rise of very high density "super retina" displays in newest high-end devices such as the whole iPhone 12 and the whole Google Pixel lineups, capping image fidelity to 2x leads to a big improvement in terms of download speed, and no perceivable quality loss for your users.

👉 Here's a new best practice on how to do that.

Native lazyload #

You might have heard or read of native lazy-loading coming to the web. Cool, isn't it? As of May 2020, it's supported in Chrome, Firefox, Edge, Opera, and behind a flag in Safari.

So 100% browsers support isn't quite there, but in case you want to enable it on supported browsers, you could go for hybrid lazy-loading by setting the use_native option of vanilla-lazyload to true.

new LazyLoad({
  use_native: true
});

You might miss these features #

If you go for native lazy-loading or hybrid lazyloading, you might miss some features that JS-driven lazy-loading grants.

automatic classes application on events (loading, loaded, etc.)
automatic retry loading images when the network failed and you're back online
download cancelation when images exit the viewport while still loading, to prioritize the loading of new ones
callbacks on events triggered (viewport enter/exit, loading started/finished, etc.)

Think about it carefully before switching to native lazy-loading. If you don't mind missing the above features, you're good to go.

Conclusions #

Here is a summary:

Use vanilla-lazyload to load your lazy images.
Don't load all the images lazily, just the ones below the fold
Use the img for simple responsive images
Use the picture tag to
- change your images width/height ratio at specific media queries
- conditionally serve your images in modern formats like WebP or Jpeg2000
Don't use any polyfill if not strictly required

Happy lazy loading!

About this article #

If something is unclear or you think it could be improved, let me know in the comments or tweet me.

☕ If you've found this useful, you might want to express your gratitude by buying me a coffee. ☕

Useful resources #

Responsive images in practice @ A List Apart
Responsive images @ Mozilla Developer Network
Responsive images in CSS @ CSS Tricks
Responsive images community group website

How to productively use the new Chromium-based Microsoft Edge browser

2020-01-16T00:00:00Z

Here’s a practical guide on how to productively use the new Chromium-based Microsoft Edge browser: download it, change the default search engine, install extensions, and more.

Index #

Download Microsoft Edge
Change the default search engine
Install extensions from Chrome web store
Set the dark theme
Configure one or more profiles
Become an insider

Download for any platform #

No matter if you are on Windows 10, 8, 7 or on Mac OS, you can download Microsoft Edge for your computer.

Change the default search engine #

After you installed it, the first thing you want to do is to change your default search engine to Google or DuckDuck (unless you really like Bing). You can do that from the Settings panel, Privacy and Services tab.

Click on the ... button
Select "Settings"
Selecte "Privacy and services" in the left menu
(scroll down to the bottom)
Click "Address bar"
Select your favourite search engine from the "Search engine used in the address bar" drop down

Happy usage!

Install extensions #

Microsoft Edge has its own marketplace for extensions, but on Microsoft Edge you can also install extensions from the Chrome web store.

When you visit the Chrome Web Store, Edge shows a blue bar on top telling you that you can install extensions from there. Just click the "Allow extensions from other stores" button and you're good to go.

How to set the dark theme #

If you like dark themes on development stuff like I do, you can activate the dark theme from the Settings panel, Appearance tab.

Click on the ... button
Select "Settings"
Select "Appearance"
Select "Dark" from the "Theme" drop down

More? Profiles #

If you are a Chrome user, at your first usage of Microsoft Edge everything gets magically migrated from Chrome to Edge. At least, that's what happened to me when I started using Edge Dev some months ago.

You might be interested in creating one or more profile and sync options, so that when you use Edge on your other devices (PC, Other PC, Mac, etc.) you find your passwords, autofill options and browsing history at hand.

Become an insider #

You can also be an insider and use Microsoft Edge early releases. There are 3 channels: Beta, Dev and Canary.

Canary is the most frequently updated (updated every day) but also the most unstable
Beta is the less frequently updated (every 6 weeks) so is the more stable
Dev is updated weekly so it's more stable than the Canary, but less stable than the Beta.

Download any of the above in the Microsoft Edge Insider Channels page.

I personally used Microsoft Edge Dev as my primary browser for months on both Mac and Windows for leisure and development purposes with a very high level of satisfaction. Unfortunately, the latest Dev and Canary versions have stopped working on one of my machines starting January 9th, but I already reported it to Microsoft and I expect a fix soon.

Is this the end of Internet Explorer? #

There are still companies using Internet Explorer for some compatibility reasons (old web-based tools or intranet websites). This version of Edge features an "Internet Explorer Mode" so those companies can finally set Microsoft Edge as default browsers for their workers, who will be able to browse the web using a modern browser, without breaking their old tools functionality.

Help the web #

If you know companies that are still using Internet Explorer for some compatibility reasons, you should tell them.

And if you are a web developer like me, you should definitely give Microsoft Edge a try both to test and to develop your websites.

➡ Download Microsoft Edge (stable)

Enjoy!

Critical CSS with Jekyll and SASS

2019-06-17T00:00:00Z

My blog used to be run by Jekyll on GitHub pages and its CSS was built using SASS. Today I decided to boost performance even more inlining the render-blocking critical CSS, but even searching the internet I struggled to find an easy way to do it. This post is for you, in case you want to do the same.

The critical style #

In the critical SASS file, use the SASS @import directive to include all the partials that have an impact on the layout of your page. Also include your variables and mixins that might be required from the imported partials.

For instance, I'm importing:

the base partial, which contains the basic rules of the website like the CSS reset and the typography rules,
the layout partial, which styles the header and layout of the page,
the posts_above partial, which styles the above-the-fold part of the posts list and the post detail,
the utils partial, which contains some helper classes (e.g. visuallyHidden).

The posts_above partial initially was a single file called posts, but I decided to split it in two separate files to optimize even more. The other partial, named posts_below, contains information to style the post footer (the author section, the share button) so it's not included here.

→ Create a critical.scss file inside the includes folder.

File includes/critical.scss:

// Import partials for critical css content
@import "variables", "mixins", "base",
  "layout", "posts_above", "pages",
  "utils";

IMPORTANT: Place this file in the includes folder! You'll need to include it in your HTML later.

Stick it in your `head` #

Inline the critical CSS inside a style tag in the <head> section of your HTML. You can do that using the following Jekyll code, which is based on the Liquid template engine used in Jekyll.

→ Open your head.html partial if you have any.

File includes/head.html:

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

{{ critical | scssify }}

The rest of your stylesheet #

If your website is simple enough, you can import the rest of your partials inside a single SCSS file, which you will load asynchronously using JavaScript.

I for instance imported there all the SASS partials which style the page sections that are likely to appear below-the-fold:

the syntax highlighting style,
the footer style,
the pagination style,
the SVG icons style,
the iframes and tables styles

→ Put the rest of your SASS rules inside your regular CSS file.

File assets/main.scss:

---
---

// Import partials for below-the-fold content
@import "variables", "mixins",
  "posts_below", "syntax-highlighting",
  "footer", "code", "pagination",
  "icons", "iframes", "tables";

IMPORTANT: The two lines with a triple dash at the beginning of the file are required by Jekyll to recognize and deploy the file as content.

Load the rest of your stylesheet #

There are many ways to load the rest of your CSS using Javascript, but I've decided to use the modern async technique which makes a CSS file load with low priority, then apply it to the page when loaded.

File head.html:

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

This works!

Conclusion #

Inlining the critical part of your CSS makes your pages to display faster since CSS is in the browser's critical rendering path.

Give it a try! If you have any comments, let me know in the comments section below!

Web Share API, the step after PWA

2019-06-14T00:00:00Z

Today I experimented with the Web Share API and implemented it on this website, just to begin. Here's what I did and how you can implement it on your website.

After I made a Progressive Web Application out of this website, I also removed the AddThis script which was used to add the share buttons ad the end of each posts, because it was slowing down the website. I then realized that, after adding the website to my home screen as a standalone app, users couldn't share posts anymore.

I've added the following script to my website's post pages:

(function() {
  // Detects support for the web share feature
  var supportsShare = "share" in navigator;

  // No support?
  // - Add a "noShare" class to the document
  // - Don't do anything else
  if (!supportsShare) {
    document.documentElement.classList.add("noShare");
    return;
  }

  // Supported? Get:
  // - the share button (DOM element)
  // - the canonicalUrl of the page
  // - the title of the page
  var shareButton = document.querySelector(".post-share");
  var canonicalUrl = document
    .querySelector("link[rel=canonical]")
    .getAttribute("href");
  var title = document.querySelector("title").innerText;

  // Add a listener to the share button
  shareButton.addEventListener("click", function(event) {
    // Call navigator share with the title and the canonical URL
    navigator
      .share({
        title: title,
        url: canonicalUrl
      })
      .then(() => {
        // You do whatever you want here
        console.log("Thanks for sharing!");
      })
      .catch(e => {
        // Manage errors here
        console.error(e, "Share failed")
      });
  });
})();

Then, to hide the share buttons using CSS when the noShare class is added to the document:

.noShare .post-share {
  display: none;
}

That easy!

The support for the Web Share API is still little, but at least is supported from Safari and Chrome for Android, so it'll help whoever installed your PWA in their mobile's home screen.

Making my blog a Progressive Web Application

2019-06-10T00:00:00Z

Some of my workmates and I took part to a Google Hackathon about Progressive Web Application and we learned a lot, so I've decided to enable this website as a PWA. Here's what I did...

To make an app installable, you need to add a manifest to your website. Here's the manifest for this website.

{
    "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": "/"
}

If you want to enable your website as a PWA, I reccommend you to start with reading the Workbox Getting Started guide.

Service Worker file #

I'm using Workbox to enable Service Workers and manage cache strategies etc.

importScripts('https://storage.googleapis.com/workbox-cdn/releases/4.3.1/workbox-sw.js');

/*
 * ROUTING RULES
 */

// Caching every JS file with the Stale While Revalidate strategy
workbox.routing.registerRoute(
  /\.js$/,
  new workbox.strategies.StaleWhileRevalidate({
    cacheName: "js-cache",
  })
);

// Caching every CSS file with the Stale While Revalidate strategy
workbox.routing.registerRoute(
  /\.css$/,
  new workbox.strategies.StaleWhileRevalidate({
    cacheName: 'css-cache',
  })
);

// Caching every Image file with the Cache First strategy
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 every post's HTML with the Network First strategy
workbox.routing.registerRoute(
  /\/[^\/]+\/$/,
  new workbox.strategies.NetworkFirst({
    cacheName: 'posts-cache',
    plugins: [
      new workbox.expiration.Plugin({
        maxEntries: 20
      })
    ],
  })
);

I've temporarily disabled precaching of other pages because I found out that those information are then added to the routing strategy with the Cache First strategy, whichs is not good in order to make your website always retrieve fresh information.

/*
 * PRECACHING
 */

// TURNED OFF BECAUSE THESE RESOURCES WOULD BE CACHE-FIRST ONLY!
/*workbox.precaching.precacheAndRoute([
  { url: '/', revision: '20190607' },
  { url: '/about/', revision: '20190607' },
  { url: '/contact/', revision: '20190607' }
]);*/

But I'm currently investigating and understanding how to manage this.

Results #

The result is that this website is now:

Installable
Accessible offline
Modern :)

If you have any hints or comments, please reach out and let me know!

A smashing article on hybrid lazy loading

2019-05-16T00:00:00Z

On May 6th, 2019 I wrote my first article on Smashing Magazine: Hybrid Lazy Loading: A Progressive Migration To Native Lazy Loading.

A screenshot of the article on Smashing Magazine

Native lazy loading is coming to the web. Since it doesn’t depend on JavaScript, it will revolutionize the way we lazy load content today, making it easier for developers to lazy load images and iframes. But it’s not a feature we can polyfill, and it will take some time before it becomes usable across all browsers. In this article, you’ll learn how it works and how you can progressively replace your JavaScript-driven lazy loading with its native alternative, thanks to hybrid lazy loading.

In the past few weeks, you might have heard or read about native lazy loading, which is coming to Chromium 75 in the upcoming months.

“Yeah, great news, but we’ll have to wait until all browsers support it.”

If this was the first thing that crossed your mind, keep reading. I will try and convince you of the opposite.

Let’s start with a comparison between native lazy loading and the good ol’ JavaScript-driven one.

→ Read the full article

Native lazy loading and js-based fallback with vanilla-lazyload 12

2019-04-11T00:00:00Z

On April 6th 2019, Addy Osmany wrote about native image lazy-loading. Two days later Yvain, a front-end developer from Paris, asked me if my vanilla-lazyload could be a loading attribute polyfill, inspiring me to develop and release version 12 of the script, which features a new use_native option to enable native lazy-loading where supported. You can already use it today.

Wait... what? #

In case you missed Addy Osmani's article, it will be possible to natively lazy load images through the loading="lazy" attribute on images and iframes, and it's already possible on Chrome 75 (currently Canary).

<img loading="lazy" src="..." />
<iframe
  loading="lazy"
  src="..."
></iframe>

Browsers will initially fetch a tiny bit of the images (~2kb) in order to get some initial information (e.g. size), then fetch the rest when they are about to enter the viewport.

The problem is that if you directly assign the src (and/or srcset) to the images, browsers that still don't support native lazy loading would download them all immediately, and this is something you might want to avoid in order to save bandwidth and speed up your website or web application.

For this reason, I added the use_native option in version 12 of vanilla-lazyload which enables native lazy-loading where supported.

More info on native lazy loading can be found on Addy Osmani's post native image lazy-loading.

The browser you need #

As of 10th April 2019, native lazy-loading is in the early stages (dev preview) and it's available only in Chrome 75 (currently Canary), and under a flag. So in order to test it, you need to:

Download Chrome Canary and install it
In Chrome Canary, go to the URL chrome://flags and enable the following flags:
- Enable lazy image loading
- Enable lazy iframe loading
Restart Chrome Canary

Demo #

Now that you have the Chrome Canary browser with the native lazy loading enabled, you can get started visiting the following demo page.

→ Open the demo and/or Check the code

If you did everything correctly, that's what will happen:

On Chrome 75 (Canary), LazyLoad will trigger the native lazy-loading
On other browsers and older versions of Chrome, the js-based lazy loading will occur

Try it on your website! #

In order to try it yourself, you need to follow the following steps.

Markup #

To make sure that your users see your images as soon as possible, I recommend to immediately load the topmost images of your webpage, only the ones that you know that will be placed above-the-fold in the most common viewports, considering smartphones, tablets and computers.

To do that, the first images in the page should be loaded using regular <img> tags. You can use the loading="eager" attribute to make sure they load as soon as possible.

<img
  src="eager-eagle.jpg"
  loading="eager"
  alt="Eager Eagle"
/>

All other below-the-fold images should be loaded using the data-src, data-srcset and data-sizes attributes instead of src, srcset and sizes, to avoid an eager loading in browsers not supporting loading="lazy".

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

Link: for a complete guide on how to lazy load responsive images, read more about lazy loading responsive images.

Now to the Javascript code! #

You're gonna need vanilla-lazyload version 12.
You can include it via a CDN:

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

Or install it using npm:

npm install vanilla-lazyload@12.0.0

In your code, set the option use_native to true when instantiating LazyLoad:

new LazyLoad({
  elements_selector: `.lazy`,
  use_native: true // This one
});

The use_native: true flag sets up these contextual behaviors:

where native lazy loading is supported, LazyLoad adds the loading="lazy" attribute to the images, then just swaps the data-* attributes for the proper ones. Now the browser will manage the lazy loading itself.
where native lazy loading is NOT supported, the lazy loading continues to be managed by Javascript, leveraging the browser's IntersectionObserver API.

To wrap up #

Loading content lazily is very important to improve a website loading speed, browser vendors are finally starting to implement it natively and I can't wait for it to be available on Edge, Safari and Firefox.

Until then, you can have both native lazy loading and js-based lazy loading using vanilla-lazyload 12, just setting the use_native option to true.

Give it a try!

If you like it, star ⭐ the repo. If you find something wrong, file an issue so I can try and fix it. For any questions, reach me on twitter.

Cheers!

Responsive and accessible table design

2019-03-08T00:00:00Z

How to make a potentially wide table fit on small devices, without losing readability and accessibility? Here are simple solutions to make tables look like lists, lists look like tables, in responsive and accessible design.

So let’s say you have an HTML <table> containing some orders, each one having:

a picture
a description
a price

And you need to make it:

look like a list on small viewports, typically smartphones
look like a table on larger viewports, like tablets and computers
accessible (see accessibility), e.g. to blind users

Table markup #

Here's the markup of the table you've got.

<table>
  <thead>
    <tr>
      <th scope="col">Photo</th>
      <th scope="col">Description</th>
      <th scope="col">Price</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><img src="https://via.placeholder.com/70x100&text=Product"></td>
      <td>Description</td>
      <td>EUR 12.345</td>
    </tr>
    <tr>
      <td><img src="https://via.placeholder.com/70x100&text=Product"></td>
      <td>Description</td>
      <td>EUR 12.345</td>
    </tr>
  </tbody>
</table>

The solution in this case would be to display: flex the rows, then set their cells direction to vertical using flex-direction: column.

tr {
  display: flex;
  flex-direction: column;
}

@media (min-width: 400px) {
  tr {
    flex-direction: row;
  }
}

And boom. Here's the example on codepen.

See the Pen Table markup, list layout (on small viewports) by Andrea Verlicchi (@verlok) on CodePen.

But is this really a table? #

Is table the right tag to use here? Is there a chance that we might have used the table tag only for layout simplicity? I mean, isn't it just a list of orders? So why don't use a ul instead?

<ul>
  <li>
    <div class="photo"><img src="https://via.placeholder.com/70x100&text=Product"></div>
    <div class="description">Description</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">Description</div>
    <div class="price">EUR 12.345</div>
  </li>
</ul>

In this case, in the CSS, we just need to make the divs inside the list items to be aligned horizontally, when there's enough space to do this.

@media (min-width: 400px) {
  li {
    display: flex;
  }
}

div {
  padding: 10px;
}

Here's the result:

See the Pen List markup, table layout (on large viewports) by Andrea Verlicchi (@verlok) on CodePen.

Accessibility considerations #

The tables can be very accessible if you code them properly, but I think it only makes sense to use tables when the data in each data cell have at least 2 headings: one at the beginning of its column and one at beginning of its row.

If it's only a title per each column you have, and you have a few columns, it's probably better to consider it a list and markup it like a list, using ul or ol as you prefer. Make sure you choose properly!

Last but not least, if you have a non-table markup (ul, div, span) that you are displaying as a table, and you want to make it accessible too, make sure you use ARIA roles to define your rowgroups, your columnheaders and rowheaders, your cells, etc.

Conclusion #

You can use flexbox to easily make a table look like a list, or a list look like a table. Keep accessibility in mind! When coding tables use table headers for rows and columns. When coding pseudo-tables use ARIA roles to define which is what.

Lazy load responsive images in 2019

2019-03-01T00:00:00Z

In the latest years, both at my job and as maintainer of a LazyLoad script, I've specialized in lazy loading of responsive images. Today I'm going to show you what HTML, CSS and JavaScript code you need to write in 2019 in order to serve responsive images and load them lazily. In the second part of the post, I'm also showing how to make the browser natively pick the WebP image when it supports it.

Old article! 👀 #

Hold on! You're reading an old version of this article.

👉 Read the 2020 update

Responsive lazy what? #

Responsive images are the images that adapt to the user's screen while keeping our websites fast by downloading just the right image source for the right viewport witdh (from small devices to large desktop computers), also considering the user's screen density (retina display, hiDpi, etc.).

Lazy loading images is a technique to make your website faster by avoiding to load below the fold images, then loading them as they enter the viewport. Beyond performance, this also allows you to save bandwith and money, e.g. if you're paying a CDN service for your images.

Got it! Now show me some code! #

→ Take a look at the results ← that you will achieve. Open your browser's developer tools and switch to the network panel. You will see that the first images are loaded immediately (or eagerly) at page landing, while the rest of the images are loaded as you scroll down the document.

The HTML markup #

Here's the markup of an immediately loaded responsive image.

<!-- Immediately loaded, responsive image -->
<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"
/>

To make sure that your users will see your images as soon as possible, I recommend to immediately load the topmost images of your webpage, only the ones that will be placed above the fold in most common viewports, considering smartphones, tablets and computers.

Always remember that lazy loading is a Javascript-based task, so before any lazy image can start downloading, your Javascript code needs to be downloaded, parsed and executed, your lazy images must be found in the DOM, their position evaluated, and these operations are going to take a while.

And here's the markup you're going to need in order to lazy load a responsive image.

<!-- Lazy loaded responsive image -->
<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"
/>

If you want your lazy images to have a low-quality preview image while they load, you can put a small, low-quality image in the src tag like the following.

<!-- Lazy loaded responsive image with low-quality preview -->
<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"
/>

We're using the img HTML tag and not the picture tag, since the latter is not necessary in this case. I'll dig into the picture tag use cases down below.

But hey, what about Internet Explorer?

It's true, Internet Explorer does not support responsive images, but given that only its latest version stuck around and it's slowly disappearing from our radars (in the websites we manage, its share is around 4%), I'd suggest NOT to use a responsive images polyfill for it, and just rely on the image specified in the src (or data-src) attribute instead.

Script inclusion #

To load the lazy images as they enter the viewport, you need a lazy load script such as vanilla-lazyload which is a lightweight-as-air (1.9 kb gzipped), configurable, SEO-friendly script that I've been developing and improving since 2014. It's also based on the IntersectionObserver browser API so it's blazing fast and grants jank-free scrolling also on slower devices.

Here is the simplest way to include the script in your page.

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

Other ways to include LazyLoad in your web pages, like using an async script with auto-init, using RequireJS, using WebPack or Rollup, are documented here.

LazyLoad initialization #

You need LazyLoad to manage and load all the images with the .lazy class in the page. You can initialize LazyLoad like this:

var lazyLoad = new LazyLoad({
	elements_selector: ".lazy",
	// More options here
});

Some CSS Tricks #

There are also some features that you can achieve using CSS only. You need to:

Make not-yet-loaded lazy images to occupy some space. If you don't do so, those images will have height 0 and they'll collapse one next to another. As a result, all of them will enter the viewport all at the same time, nullifying our efforts to load them as they enter the viewport.
Avoid empty images to appear as broken images
Resolve a Firefox anomaly that displays the broken image icon while images are loading

You can do all that using this CSS rules:

/*
Makes images container to occupy some space
when the images aren't loaded yet.
This value depends on your layout.
*/
.imageList li {
	min-height: 300px;
}

/*
Avoid empty images to appear as broken
*/
img:not([src]):not([srcset]) {
	visibility: hidden;
}

/*
Fixes the Firefox anomaly while images are loading
*/
@-moz-document url-prefix() {
	img:-moz-loading {
		visibility: hidden;
	}
}

Picture tag use cases #

Until now, I wrote about the img tag with the srcset and sizes attributes, which is the solution to the vast majority of the responsive images you might need and use on a website or web application. Now, in which cases should you use the picture tag?

Different width/height ratio #

Use case: you need to show images with different width/height ratio depending on a media query. e.g. you want to show portrait images on mobile, vertical devices, landscape on wider viewports, like tablets and computers.

→ Take a look at the results ←

Here's the code you're gonna need in this case. In order to have immediately loaded images, just use the plain src and srcset attributes, without data- prefix.

<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>

Automatically switch to WebP #

Use case: you want the browser to automatically pick the WebP format depending on its support for that format.

→ Take a look at the results ←

Here's the code! Again, in order to obtain immediately loaded images, just use the plain src, srcset and sizes attributes, without data- prefix.

<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>

One more thing #

The vanilla LazyLoad script leverages the IntersectionObserver API so, in browser not supporting it like Internet Explorer and older versions of Safari, it will load all images as soon as it executes, which leads more or less to the same result as if no LazyLoad was ever used on the page.

If you want to load your content lazily in the 100% of the browsers out there (I wouldn't, but it's up to you), you need to include the IntersectionObserver Polyfill script before LazyLoad.

You can either you put the script in the page just before the LazyLoad one, as it follows...

<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>

...or you can load it the polyfill as a dependency of LazyLoad using RequireJS or another AMD module loader. More info here.

Conclusions #

Here is a summary:

Don't load all the images lazily, just the ones below the fold
Use the img tag to do simple responsive images
Use the picture tag to conditinally serve the WebP version of your images, or to change your images ratio
Use vanilla-lazyload to load your lazy images.
Optionally use the IntersectionObserver polyfill if you want to load lazily on 100% of the browsers.

If something is unclear or could be improved, please reach out and let me know.

If you did find this useful, feel free to share it!

Useful resources #

Responsive images in practice @ A List Apart
Responsive images @ Mozilla Developer Network
Responsive images in CSS @ CSS Tricks
Responsive images community group website

Check if an element is still inside viewport after a given time

2018-08-27T00:00:00Z

What would you do if somebody asked you to load a DOM element only if it stays inside the viewport for a given time? You would use vanilla-lazyload, wouldn't you? 😉 This is exactly what the GitHub community asked for as new feature in LazyLoad, to avoid loading elements which users skipped by scrolling fast beyond them. In this post, I'd like to share the solution with you.

There are a couple of ways of doing this. The first one is check the element's posistion over time, the second one leverages IntersectionObserver.

The (slow) way without IntersectionObserver #

This way is much slower that using IntersectionObserver because it implies:

watching browser’s scroll and resize events to call a (throttled) callback
in the callback, loop through every watched element and call a isInsideViewport function to check if they are inside the viewport
the isInsideViewport function then checks a bunch of things like the element's getBoundingClientRect, the window's innerHeight, pageYOffset, etc. and returns a boolean

All of these only to know when elements enter the viewport.

To know whether or not a given element stayed inside the viewport for a given time, you should do something like:

when the element enters the viewport, setTimeout a function. Let's call it isStillInsideViewport.
in the isStillInsideViewport function, check if the element is still inside the viewport calling isInsideViewport on that element, then:
- if it is, load it and remove it from the watched elements
- if it's NOT, don't load it and keep watching it

Quite straightforward as a thought, but not that fast executing.

The way with IntersectionObserver #

This way is much faster because it only implies the following.

you set an IntersectionObserver and use it to observe all your watched elements
it calls a onIntersection function each time an element intersects with the viewport
you can do the loading logic inside the onIntersection function

No need to watch browser’s scroll nor resize events.

First idea #

My first thought was to do it without IntersectionObserver, meaning I'd have to check the "is inside viewport" state after a timeout.

Turns out there is not an elegant way to check if an element is inside the viewport with IntersectionObserver. All you get are callbacks when an element intersects with the viewport.

Discovering thresholds #

But wait, what is that IntersectionObserver's thresholds option in the doc? 😲

Says MDN:

Either a single number or an array of numbers which indicate at what percentage of the target's visibility the observer's callback should be executed. If you only want to detect when visibility passes the 50% mark, you can use a value of 0.5. If you want the callback run every time visibility passes another 25%, you would specify the array [0, 0.25, 0.5, 0.75, 1]. The default is 0 (meaning as soon as even one pixel is visible, the callback will be run). A value of 1.0 means that the threshold isn't considered passed until every pixel is visible.

After I fiddled around with the option and tried the result in a specific delay load demo, I found out that passing 0 to the thresholds option (which is the default value), the onIntersection function is called also when the element leaves the viewport.

Ultimate solution #

Now that I knew when an element leaves the viewport, it's much easier to solve the main problem.

The solution, ultimately, is to:

when an element enters the viewport, setTimeout a function to load the element
store each timeout ID in a data- attribute of the related element
let the element load when the timeout occurs
if the element leaves the viewport before the timeout is executed, cancel the timeout with clearTimeout

That's linear and easy! 😊

Show me the code! #

You can find the full code in vanilla-lazyload's lazyload.js file + related imports. If you don't feel like jumping from one file to another, you could also open the bundled file lazyload.es2015.js from the dist folder.

A simplified version of the code is provided below for your convenience.

Setting IntersectionObserver #

const gObserver = new IntersectionObserver(onIntersection, {
  rootMargin: "0px",
  threshold: 0
});

The rootMargin option set to 0px here means: "observe the actual viewport size". You could pass any CSS length in order to expand the observed area. E.g. passing 300px would expand it by that length on top, right, bottom, and left.

onIntersection function #

This function is called each time an intersection occurs and the parameter is the set of entries that intersected with the viewport.

Assuming watchedElements are the elements being watched by the script (see below), after each intersection they should be purged from the elements we already dealt with (loaded).

The purgeElements function is out of the scope of this post, but it returns a subset of the watchedElements.

const onIntersection = entries => {
  entries.forEach(manageIntersection);
  watchedElements = purgeElements(watchedElements);
};

manageIntersection function #

This function is called on each entry that intersected with the viewport. Both on enter and exit.

On enter, it starts the delayed loading of the element. On exit, it cancels it.

const manageIntersection = entry => {
  var element = entry.target;
  if (isIntersecting(entry)) {
    delayLoad(element, delayTime);
  } else {
    cancelDelayLoad(element);
  }
};

isIntersecting utility function #

This is a utility function to understand whether or not an entry is intersecting with the viewport.

Note that:

entry.isIntersecting needs fallback because it is null on some versions of Microsoft Edge
entry.intersectionRatio is not enough alone because it could be 0 on some intersecting elements

const isIntersecting = (entry) =>
  entry.isIntersecting || entry.intersectionRatio > 0;

delayLoad function #

This is the function that delays the load of the element by delayTime.

getTimeoutData and setTimeoutData are utility functions to get and set the timeout ID from a data-attribute on the element.

const delayLoad = (element, delayTime) => {
  var timeoutId = getTimeoutData(element);
  if (timeoutId) {
    return; // timeout was already set, do nothing
  }
  timeoutId = setTimeout(function() {
    loadAndUnobserve(element);
    cancelDelayLoad(element);
  }, delayTime);
  setTimeoutData(element, timeoutId);
};

cancelDelayLoad function #

This function's duty is to cancel the element timeout, if it's set.

const cancelDelayLoad = element => {
  var timeoutId = getTimeoutData(element);
  if (!timeoutId) {
    return; // do nothing if timeout doesn't exist
  }
  clearTimeout(timeoutId);
  deleteTimeoutData(element);
};

loadAndUnobserve function #

This immediately loads the element, and takes it away from the IntersectionObserver's observed elements.

const loadAndUnobserve = (element) => {
  // Here's what you actually do something with the element
  revealElement(element);
  gObserver.unobserve(element);
};

At my signal, unleash hell! #

We did everything good until now, but we didn't start anything yet! We need a set of watchedElements to observe with our IntersectionObserver, or nothing will happen.

var watchedElements = document.querySelectorAll("img");
watchedElements.forEach(element => gObserver.observe(element));

All together now #

You can find a working version of the code above on CodeSandbox for you to play around with it!

Final words #

See how easy is it to check if an element is still inside the viewport after some time using IntersectionObserver?

For more information about how to create LazyLoad using IntersectionObserver, see Intersection Observer and Lazy Load of elements.

Is there something you would have done differently, or do you agree with what I did here? Please reach out and let me know!

If you want to show some love to LazyLoad, star it on GitHub! ⭐

Create a JavaScript library using ES2015 modules, Gulp, Rollup and Jest

2017-09-09T00:00:00Z

Let's see how to write a JavaScript library using ES2015 transpiled with Babel, featuring ES modules packed up using Rollup via Gulp, and Jest to test your code.

Here I'm sharing the experience I had while developing my vanilla-lazyload script, since at the time I didn't find anything that explained how to use those libraries together, especially Rollup and Jest.

Installing Gulp #

Gulp is a task runner similar to Grunt for automating painful or time-consuming tasks in your development workflow. I chose to migrate from Grunt to Gulp because the latter is blazing fast, being it based on Node's streams instead of the file system.

In order to use Gulp, you need to install Gulp locally to your project, to do so:

npm install --save-dev gulp

A good option to use Gulp is to install its command line executable with:

npm install -g gulp-cli

For more information, I would suggest to read Gulp for beginners on CSS tricks.

Configuring gulp #

Gulp execution requires a configuration file named gulpfile.js. Create an empty one for now, I'm going to show you what to put in it, step by step.

1. Linting source files #

Being JavaScript a dynamic and loosely-typed language, is especially prone to developer errors. Linting tools like ESLint allow developers to discover problems with their JavaScript code without executing it.

To install ESLint for Gulp, just run:

npm install --save-dev gulp-eslint

Then in your empty gulpfile.js add:

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()) // --> fails if errors
        // --> pipe more stuff here
});

NOTE: Setting the process.env.NODE_ENV variable is necessary to match the task we're running in the Babel configuration. I'll explain this in a while.

2. Bundling modules with Rollup #

Rollup is a module bundler for JavaScript which compiles small pieces of code into something larger, such as a library. It uses the new standardized format for code modules included in the ES2015 revision of JavaScript, today.

Long story short, Rollup reads your main JavaScript file and generates a bigger file with all the modules included, automatically.

Install rollup with:

npm install --save-dev gulp-rollup gulp-rename

Then in your gulpfile, just add a pipe command:

// ----------- rolling up --------------
.pipe(rollup({
    format: "umd",
    moduleName: "LazyLoad",
    entry: "./src/lazyload.js"
}))

This means that Rollup has to produce a umd type of module, the produced module name will be LazyLoad, and the entry point to start looking for dependencies is ./src/lazyload.js.

Since I want to distribute a version of the script which is not transpiled in ES5, I save it to lazyload.es2015.js piping the rename command and the dest one.

.pipe(rename("lazyload.es2015.js"))
.pipe(gulp.dest(destFolder)) // --> writing rolledup

destFolder is a JavaScript variable and it's just set to ./dist inside our gulpfile.js.

NOTE: Webpack is a similar bundling script which might be preferrable to bundle complex applications, but I noticed that the final code generated by Webpack would be much heavier, so Rollup worked better for me.

3. Transpiling to ES5 with Babel #

Until now, we have bundled all our modules in a single file which will work in modern browsers only. Of course we also want to produce a file which is readable by not so modern browsers.

To install babel and its ES2015 preset, plus a plugin to transform Object.assign() to ES5, do:

npm install --save-dev babel-core gulp-babel babel-preset-es2015 babel-plugin-transform-object-assign

Then, to babelize our previously rolled-up JavaScript and save it to lazyload.js, let's require gulp-babel and add the following pipe to our gulpfile.js:

var babel = require("gulp-babel");

// ----------- babelizing --------------
.pipe(babel())
.pipe(rename("lazyload.js"))
.pipe(gulp.dest(destFolder)) // --> writing babelized es5 js

The babel configuration has to be stored in an external .babelrc file, that in my case looks like that:

{
    "ignore": [
        "node_modules/**"
    ],
    "env": {
        "test": {
            "presets": [
                "es2015"
            ],
            "plugins": ["transform-object-assign"]
        },
        "release": {
            "presets": [
                ["es2015", {
                    "modules": false
                }]
            ],
            "sourceMap": false,
            "plugins": ["transform-object-assign"]
        }
    }
}

You may have noticed that I configured two envs differently:

release is the one used by Rollup, in Gulp. Remember? We set it in the gulpfile.js using process.env.NODE_ENV = "release"
test is the one used by Jest (explanation below)

4. Minifying with Uglify #

Uglify JS is a JavaScript compressor toolkit commonly used to minify the distribution version of JavaScript libraries.

npm install --save-dev gulp-uglify

Then, add the following require and pipe to our gulpfile.js:

var uglify = require("gulp-uglify");

// ----------- minifying --------------
.pipe(uglify())
.pipe(rename("lazyload.min.js"))
.pipe(gulp.dest(destFolder)); // --> writing uglified

All together now #

This is how your gulpfile.js should look like at the end:

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()) // --> failing if errors
        // ----------- rolling up --------------
        .pipe(rollup({
            format: "umd",
            moduleName: "LazyLoad",
            entry: "./src/lazyload.js"
        }))
        .pipe(rename("lazyload.es2015.js"))
        .pipe(gulp.dest(destFolder)) // --> writing rolledup
        // ----------- babelizing --------------
        .pipe(babel())
        .pipe(rename("lazyload.js"))
        .pipe(gulp.dest(destFolder)) // --> writing babelized ES5
        // ----------- minifying --------------
        .pipe(uglify())
        .pipe(rename("lazyload.min.js"))
        .pipe(gulp.dest(destFolder)); // --> writing uglified
});

gulp.task("watch", function () {
    gulp.watch("./src/**/*.js", ["default"]);
    // Other watchers
});

The "watch" part is so that if we run the gulp watch command, gulp watches the src folder for changes and re-creates the dist files automatically. Sweet.

Running Gulp #

You can now build your library executing Gulp in single run:

gulp

Or make it watch for changes in your src files if you're still developing:

gulp watch

Making Jest work along with Rollup #

I'll write another in-depth post about how I used Jest to test modules which would become private uglified variables and functions, but the point here is how to make Jest work together with Rollup, since the two require different Babel configuration.

As we saw, the Babel configuration is split in two envs and the one set and used by Jest is test. This is because Jest just needs the presets object to contain ["es2015"], whereas rollup requires ["es2015", {"modules": false}].

If you did what I explained correctly, Jest should work out of the box.

npm install --save-dev jest
npm install -g jest-cli

Then just launch jest like that:

jest

More information on Jest on the Get Started page.

Further steps #

A more advanced configuration would be to configure npm to be the command line interface for the build and the tests, so that we could run npm run build and npm run test to launch either the build or the tests, or better include the testing process in the build so whenever our tests fail, the build fails too. I will do that as next steps.

Intersection Observer and lazy loading of elements

2017-09-04T00:00:00Z

In August 2017 a new exciting browser API finally gained quite wide support: the Intersection Observer API, which we can use to know when two DOM elements intersect, or when a given DOM element enters the browser viewport. The lazy loading of images is just the case.

About 3 years and 500 commits ago, I gave birth to a new vanilla javascript lazy load script, currently known as vanilla-lazyload on npm and cdnjs, and starred by 1,135 people on GitHub.

The switch to Intersection Observer #

As the community around my script started to grow, some members requested it to support the Intersection Observer API, amongst other enhancements.

So I decided to make my script's fans happy, and I did it. The resulting source code is 40% smaller, and vanilla-lazyload is now much faster than its previous version. (by the way, if you know how to measure a script performance precisely, please comment)

How to create an Intersection Observer #

The implementation is quite simple: you create a new Intersection Observer instance specifying a callback function to be called whenever an intersection event occurs, and a couple of options: root and rootMargin, that are:

root: the element you want to test the intersection against, null meaning the browser viewport
rootMargin: in case you want to expand or shrink the effective size of the root element

var myObserver = new IntersectionObserver((entries) => {
    /* do something */
}, {
    root: null,
    rootMargin: "300px 0"
});

Once the intersection observer is created and assigned to a variable, you can start observing on a target element with:

var elementToObserve = document.getElementById('observeMe');
myObserver.observe(elementToObserve);

Creating the observer #

Since I need to test the intersection of a set of images / elements against the scrolling container (the viewport, or any element styled with overflow: scroll), I create a new IntersectionObserver and store it in the LazyLoad property _observer.

this._observer = new IntersectionObserver(onIntersection, {
    root: settings.container === document ? null : settings.container,
    rootMargin: settings.threshold + "px"
});

Notes:

onIntersection is a function, which I explain below
settings.container is the scrolling container, defaulting to document, passed by LazyLoad user in the options object
settings.threshold is the amount of pixels beyond the scrolling container where to start loading the images / elements, defaulting to 300.

The onIntersection function #

The point is that whenever a DOM element intersects with the scrolling container, the onIntersection function is called. Here goes the function definition:

const onIntersection = (entries) => {
    entries.forEach((entry) => {
        if (!entry.isIntersecting) {
            return;
        }
        let element = entry.target;
        revealElement(element, settings);
        this._observer.unobserve(element);
    });
};

The entries argument is passed all the elements being observed by the observer which calls this function. So we need to cycle through each entry and know whether or not it is intersecting with the root element. Fortunately, the isIntersecting property does this exactly, so:

if the entry is not intersecting, we just ignore this entry, returning
if the entry is intersecting, we start loading the element source calling revealElement, then we unobserve this specific entry since its loading is already started and we don't need to keep watching it.

Observing an element #

Isn't something missing? Yes it is! The code explained until now accomplishes nothing, if we don't tell our observer to observe an element, or more than one in our case. What we need to do is:

this._elements.forEach(element => {
    this._observer.observe(element);
});

Being this._elements the set of elements that LazyLoad has found inside this._container by a specific selector, purged by the ones that are already being processed (to deal with cases of infinite scroll, or other DOM updating cases).

Fallback #

Since not every browser are created equal we need to test the support for IntersectionObserver before we use it. The way to do it is simple:

if (!("IntersectionObserver" in window)) {
    return;
}

In my case, on browsers where IntersectionObserver is not supported, LazyLoad will load all the images at once. Therefore, if you need to load lots of images and your user base is browsing with a consistent share of older browsers, you should use LazyLoad a version less than 9. See changelog for more details.

Conclusion #

That's it! Intersection Observer makes your code much smaller, faster and more legible. If you're not using it already, you should definetly start playing around with it.

And don't forget, if you have a very long page stuffed with images and other content, you should load them lazily using a lazy load script, and your best choice is vanilla-lazyload!

Using CSS variables as a spacing unit

2017-06-14T00:00:00Z

Here I show you how you can CSS variables, popular name of CSS custom properties, to scale your layout spaces across different media queries.

The advantage: shorter, lighter, easier-to-maintain CSS files.

To demonstrate this, I created CSS vars based layout spacing on Codepen. Find it embedded at the end of this post.

What are CSS variables #

CSS variables one of the next big things in CSS. They're not widely supported (spoiler: Internet Explorer is missing) for current browsers market share, but it's time we start playing with them, don't you think? They might be useful when developing our next wonderful project!

The advantage of CSS variables is that we can assign a value to a name, and refer to the value using a name.

How to define a CSS variable #

CSS variables can be defined at any point, and they are inherited to all the children of the DOM element they're applied to.

html {
  --base-spacing: 15px;
}

Here we defined a CSS var named --base-spacing and we assigned it a value of 15px. The variable is defined in the html element so it will be available in our whole document.

(Yeah, CSS vars must start with a double hyphen (--), which is ugly, but bare with me)

Difference with SASS variables #

In case you're thinking: "So what? I'm already using SASS and my _variables.scss has plenty of variables!" - Well, it's not quite the same.

SASS variables are pre-processed so they are transformed to a fixed, static CSS value. When the CSS is loaded, the variable is lost and only its value remains, spread out in all of its usages.

A SASS variable cannot be changed after the CSS is loaded. CSS variables can be changed using media queries, javascript, or the developer tools of your favourite browser.

How to use a CSS variable #

We want the --base-spacing variable to be a spacing unit to be used in paddings and margins across our page. So what do we do?

.box {
  padding: var(--base-spacing);
  margin: var(--base-spacing);
}

h1 {
  margin-bottom: var(--base-spacing);
}

That's great! Now we're using our CSS variable as a spacing unit, like we would do with a SASS variable, but... we can now change it!

Changing CSS variables values #

This is where the magic happens. CSS variables values can be re-assigned like you would do with any other CSS property, using:

media queries
javascript
the developer tools of your favourite browser

The first thing you can do to understand the power of CSS variables is open the developer tools, locate the variable in your CSS file, and change its value. Try it here.

In our case, we want to enlarge spaces on wider screens, so we just do the following:

@media (min-width: 500px) {
  html {
    --base-spacing: 30px;
  }
}

That's it. This simple variable reassignment will make all of our paddings and margins scale since we used a variable to define theis values.

DEMO #

This is what I'm talking about.

See the Pen CSS vars based layout spacing by Andrea Verlicchi (@verlok) on CodePen.

Endless possibilities #

Now that you master CSS variables, you can go far beyond and let your users decide the spacing of your layout, the main color, or anything else.

You just need some input fields and a few lines of javascript, like @wesbos is demonstrating here.

See the Pen Update CSS Variables with JS by Wes Bos (@wesbos) on CodePen.

Changing text color for contrast based on background lightness

2017-06-02T00:00:00Z

If you had to change the color of some fixed-positioned text based on the lightness of its scrolling background, how would you do that? CSS filters, blend modes? But what if you had to support all browsers, including Internet Explorer? Here are a couple of ways to do that using CSS clip and clip-path.

Here's the result using clip - wide browser support

See the Pen Text color change at background using clip by Andrea Verlicchi (@verlok) on CodePen.

And here's the result using clip-path - modern browsers only

See the Pen Text color change at background using clip-path by Andrea Verlicchi (@verlok) on CodePen.

What happens here that the content is:

wrapped by a box with class clipper which clips its content
copied inside every container :(
positioned with position: fixed

Being the content in position fixed, the content sticks to our browser window, but is't clipped by the moving clipping elements.

This solutions has 2 problems, though:

there's a bug in IE and Edge which makes the content's block children invisible. It works with inline elements, though, but it's a hack
we need to copy the content inside every container

Can you think of a better solution? If you do, please add it to the comments!

Responsive images, an HTML 5.1 standard

2017-04-10T00:00:00Z

It's official. Responsive images have been a W3C recommendation since November 2016, featuring the brand new picture tag and new attributes for the img tag: srcset and sizes.

Why responsive images? #

Back in 2010, Ethan Marcotte started talking of responsive web design, an approach to web design aimed at allowing webpages to be viewed in response to the size of the browser viewport.

That was revolutionary, but suddenly we developers had a new problem to face: in a responsive website, how big should the website's image files be?

The initial approach was to use one large image for all viewport sizes, so that images looked great on large screens even if they had to be scaled down on smaller devices, but soon this turned out to be a bad practice: slower connections on mobile devices and less performing CPUs were slowing down the website and making user experience worse.

Developers then started to use javascript to pick the right image size based on the viewport, that's when scripts like picturefill came about.

But the thing is that javascript is slower than pure HTML: it must be downloaded, parsed and executed before the browser could even start downloading the images. The web needed something native to go back to defining images in the HTML to allow browsers to start downloading them as soon as possible.

That's why a group of independent designers and developers who go by the name of Responsive Images Community Group, started proposing new tags and attributes.

What are responsive images? #

"Responsive images" is the name given to the technique of defining more than one source per each image, and making browsers to download the best one, depending on the following factors:

browser viewport, or your website layout
device pixel density

Users have different pixel densities depending on the monitor of their device. Standard devices have a pixel density of 1, meaning the monitor has 1 device pixel per CSS pixel, while the newest HiDpi monitors - including "Retina" displays - have a higher density. For example, a pixel density of 2 means that the monitor has 2x2 device pixels per CSS pixel, and so forth.

HiDpi displays are great when rendering vectors, like fonts or SVG images. But when it comes to rendering images, browsers will just stretch the original image, making it blurry on devices that are supposed to deliver a better quality.

Supporting hiDpi displays #

The simplest of things you can do with the new srcset attribute is to support different pixel densities. You just need to specify different sources for your image, describing each one with the x descriptor, which indicates the pixel density of the image source. Like that:

<img
	src="shirt_300w.jpg"
	srcset="shirt_300w.jpg 1x, shirt_600w.jpg 2x"
	alt="A beautiful shirt"
	width="300"
	height="380"
/>

In this example, we want to display an image of 300 x 380 CSS pixels. The standard density image is shirt_300w.jpg and it's described by the 1x descriptor. The double-density image is shirt_300w.jpg, and it needs to be 600 x 760 pixels.

Note: browsers that understand the new srcset attribute will ignore the src one, which is still required.

This is already a good result to deliver the best image quality to our users, but what if in our responsive layout, the image size varies depending on the available space?

Different image sizes #

Let's suppose that our image must be wide:

300 pixels on small (< 600) viewports
600 pixels on medium (> 600) viewports
1200 pixels on large (> 1200) viewports

How do we make sure that our users always get the image size that best fits their viewport and pixel density?

We can define images of these sizes:

Density / Viewport width	< 600	>= 600	>= 1200
1x	300 x 380	600 x 760	1200 x 1520
2x	600 x 760	1200 x 1520	2400 x 3040

As you can see, we're using 4 different image sizes. I would advice to name the images with their width on the name, since it's much clearer to understand.

300 x 380 - shirt_300w.jpg
600 x 760 - shirt_600w.jpg
1200 x 1520 - shirt_1200w.jpg
2400 x 3040 - shirt_2400w.jpg

To markup this in our HTML, we must do:

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

With this markup, the browser knows the space that the image will occupy on the screen (through sizes) and all the available image sources that we prepared for our users (through srcset).

At this point, the browser will choose what image source to download based on the information we provided and the information it knows about our user, such as screen density, cached files, connection speed, etc.

Browser support #

The srcset attribute is supported across all browsers except Internet Explorer. Fortunately, there's an official polyfill that we can use to emulate native browser behavior on legacy browsers.

Responsive images? You don't need the picture tag

2015-12-21T00:00:00Z

Say you have a responsive website layout where images are sized at 100% of the container, but the container is not always as wide as the viewport. Do we need to use the picture tag, or the img tag is enough? The img tag can do it, using its sizes and srcset attributes. Here's how.

The images layout #

The images in the layout are wide as follows:

Viewport Width	Images width	Container width
0 to 767 px	1/2 of container	100% with no padding
From 768 px to 1023 px	1/3 of container	100% with 30 px padding
From 1024 px to 1279 px	1/4 of container	100% with 30 px padding
From 1280 px up	1/4 of container	1280 px with 30 px padding

Units we can use in the `sizes` attribute #

When using the img tag, in the sizes attribute, you can specify how wide your images will display at different media queries, not only using the viewport width (vw) unit (as you could find googling around) but using any length and also using CSS calc() if you have to deal with paddings or container's max-width.

Viewport Width	Images width	Container width	Image width in CSS
0 to 767 px	1/2 of container	100% with no padding	`50vw`
From 768 px to 1023 px	1/3 of container	100% with 30 px padding	`calc(( 100vw - 60 px ) / 3)`
From 1024 px to 1279 px	1/4 of container	100% with 30 px padding	`calc(( 100vw - 60 px ) / 4)`
From 1280 px up	1/4 of container	1280 px with 30 px padding	`305 px`

See this pen which uses media queries and CSS to specify img widths, and this pen which specifies the sizes inside the img tag.

Confused? If you need a more extensive explication, please read srcset and sizes by Eric Portis, in my opinion the best article about using img with srcset and sizes

Calculating optimized image sizes based on spacing and device / orientation #

We want our images to be optimized at most common resolutions, we need to:

Define which are the most common screen resolutions / densities
Decide which are the resolutions / densities that we want to optimize for
Calculate what the image sizes will be at these resolutions / densities
Scale our images to those image sizes
Markup the imgs in our HTML 2. List all the image sizes in the srcset attribute, using the w descriptor 2. List all the image widths in the sizes attribute, as defined in the table above

To define the screen resolutions and decide which ones to optimize for, we can use any tool like Google Analytics to get some information about our users and the devices they mostly use.

After some calculations, the resulting image sizes were the following:

Device & orientation	Screen width	Img width (css px)	Img height (css px)	Screen density	Img width (px)	Img height (px)
iPhone 4/5/5s	320	160	186	2	320	372
iPhone 6	375	187	217	2	374	435
iPhone 5/5s landscape	568	284	330	2	568	660
iPhone 6 landscape	667	333	387	2	666	774
iPad / mini	768	236	274	2	472	549
iPad / mini landscape	1024	241	280	2	482	560
PC with 1280w up	1280	305	355	1	305	355
PC with 1280w and HiDPI	1280	305	355	2	610	709
PC with more than 1280w	1920	305	355	1	305	355

To the code! #

The code of the POC that I created is on GitHub in this repo, and the live demo is here.

picture markup #

<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="A product image" />
</picture>

img markup #

<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="A product image"
/>

Conclusion #

picture markup turns out to be more verbose, and we're still not supporting single density displays under 768px.
img markup is shorter and less repetitive, and lets the browser calculate what is the better image to use considering resolution AND pixel density.

You don't need the picture tag.

The reason is that using the img you'll have to write much less code to support much more devices and screen densities. Given the ability to use CSS' calc() function in the length expression of the sizes attribute, we can do even complex calculations to define the right image to use even in complex layouts.

Note that the picture and img tags are comparable only when all the images have the same ratio over multiple media queries. If the images ratio change to adapt images to devices ratios, the picture tag is the only way to go.

Cheers!

Lazy load of responsive images with srcset and LazyLoad

2015-04-20T00:00:00Z

It's now possible (yes, today!) to have lazy loading on responsive images to make our images to adapt to users screens and keep our website fast. YAY! \o/ In this article, we'll see what markup we need to write and which Javascript libraries we're gonna need to do that.

Old article! 👀 #

Hold on! You're reading an old version of this article.

👉 Read the 2020 update

Responsive lazy what? #

Responsive images is a technique to make the images in your website to adapt to the viewport witdh and screen density (1x, 2x - retina display, etc.). To understand how to do this, you can read Responsive images in practise and you can find more info at the responsive images community group website.

Lazy loading images is a technique to make your website faster by avoiding to load images that the user might never see on his viewport, then loading them as they enter the viewport. Beyond performance, this also allows you to save bandwith (and money, if you're paying a CDN service for your images).

Implementation #

Take a look at the results we're going to achieve using this techniques together.

If you open your browser inspector in the network panel, you would see that the first images are loaded "normally" by the browser at page landing, but the rest of the images are loaded as you scroll down the document.

The markup #

Here's the markup you're gonna need to lazy load a responsive image.

<!-- Image loaded normally by the 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"
/>

<!-- Image loaded lazily by 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"
/>

Note that we're using the img HTML tag and not the picture. The latter is not necessary because we're not changing the image ratio in this case.

Script inclusion #

First of all, we need a library to load the lazy images as they enter the viewport. There are a couple of libraries to have your images loaded lazily, but to have lazy loading of responsive images you're gonna need the one that I wrote: LazyLoad (read about all its advantages here).

Furthermore, as not all browser are supporting responsive images, we need to include Filament Group's picturefill library, a polyfill which allows us fill the gap and make responsive images work in all browsers. Note that this library won't be necessary when all browsers you need to support will support responsive images.

So we're going to include those 2 scripts:

<script src="js/vendor/lazyload.min.js"></script>
<script src="js/vendor/picturefill.min.js"></script>

Script initialization #

What we need to do is create a new instance of LazyLoad to transform that data-srcset attribute into a proper srcset attribute. This would be enough for browsers that natively support responsive images but, for the rest of them, we need to call picturefill soon after LazyLoad has modified the DOM.

We can do all of that using this command:

/*var myLazyLoad = */ new LazyLoad({
	data_src: "src",
	data_srcset: "srcset",
	show_while_loading: true, //best for progressive JPEG
	callback_set: function (img) {
		picturefill({
			elements: [img],
		});
	},
});

For further reference about what we did here, see LazyLoad documentation.

The stylesheet #

There are also some features that can be achieved only using our CSS. We need to:

Make empty images to occupy some space. If we don't do so, all the empty images will be collapsed one to another and they will enter the viewport all at the same time, nullifying our efforts to load them lazily.
Avoid empty images to appear as broken images
(if we used the show_while_loading option, as we did) Resolve a Firefox anomaly that displays the broken image icon while images are loading

We can do all that using this CSS rules:

/*
Makes images container to occupy some space
when the images aren't loaded yet.
This value depends on your layout.
*/
.imageList li {
	min-height: 300px;
}
/*
Avoid empty images to appear as broken
*/
img:not([src]):not([srcset]) {
	visibility: hidden;
}
/*
Fixes Firefox anomaly during images load time
*/
@-moz-document url-prefix() {
	img:-moz-loading {
		visibility: hidden;
	}
}

That's it! #

It was very easy, wasn't it? If you didn't yet, take a look at the demo of what we achieved here.

Advanced sprite generation using Compass (SASS)

2015-03-06T00:00:00Z

Spriting is a way to improve performance in your website by putting many images (or icons) in a single larger image, in order to make a single HTTP request instead of many. Here's how you can make sprites using Compass.

The simple way #

The simpler way to create a sprite with Compass requires you to import a folder of images in your project, then generate a class for each sprite. You can do that by using the following code:

// Required Compass tool import
@import "compass/utilities/sprites";
// Importing all the png images under the flags folder
@import "flags/*.png";
// Generate a CSS class for each sprite
@include all-flags-sprites

Example of CSS output:

.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; }

This can be enough for your needs... but you want more, don't you?

The advanced way #

Skipping all the others way you can do sprites generation with Compass, I found out that if you have to do the following:

Generate dimensions of the box equals to the sprite ones
Use an offset inside the box
Spacing sprites inside the sprite map
Manage 1x, 2x, 3x density displays
Optimize sprite generation time

The only way to do spriting with Compass is to create your own mixins which use Compass base mixins under the hood.

Images and folders structure #

To have the images in single density, double density and maybe triple density, we need to provide the images in 1x, 2x and maybe 3x size.

So, supposing you will create a sprite map containing flags, you can have the following folders under our images folder:

flagsSprite1x - flags images @ single density
- france.png
- germany.png
- italy.png
- ...
flagsSprite2x - flags images @ double density
- france.png
- germany.png
- italy.png
- ...
flagsSprite3x - ...triple density
- ...

And if we're were going to create also an icons sprite map, we'd have to create the folders:

iconsSprite1x
- ...
iconsSprite2x
- ...
iconsSprite3x
- ...

Now let's take a look at the SASS partials you should create.

SASS partials #

To guarantee the maximum flexibility and the smallest build time, I suggest you to use the following:

_variables.scss - all your variables
_mixins.scss - all your mixins
one partial file for set of images
- _flagsSprite.scss - flags
- _iconsSprite.scss - icons
- ...

Let's see what to put in our partials, one by one.

_mixins.scss #

Here's some mixins you might want to include in your mixins file. You can find the explanation of what they do right in the code comments.

/*
Makes possible to use a n-ple density sprite
Automatically adapts background-size and offset when $multiplier is greater than 1
Allows you to use automatic size generation, which is automatically adapted when $multiplier is greater than 1

Required parameters:
- $sprite - the sprite name
- $spriteMap - the spriteMap variable
- $spriteUrl - the sprite map url of the sprite

Optional parameters:
- $multiplier (1) - the sprite density (1 for single density, 2 for retina, 3, etc.)
- $renderSize (false) - tells the mixin to render width and height of the box containing the sprite
- $offsetX (0) - the horizontal offset (px) for the image in the box
- $offsetY (0) - the vertical offset (px) for the image in the 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;
  }
}

/*
Utility mixin to use single and double density sprite, with double density media query included

Required parameters:
- $sprite - the sprite name
- $sprite1xMap - the spriteMap variable for the 1x sprites
- $sprite2xMap - the spriteMap variable for the 2x sprites
- $sprite1xUrl - the sprite map url of the 1x sprites
- $sprite2xUrl - the sprite map url of the 2x sprites

Optional parameters:
- $renderSize (false) - tells the mixin to render width and height of the box containing the sprite
- $offsetX (0) - the horizontal offset (px) for the image in the box
- $offsetY (0) - the vertical offset (px) for the image in the 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 #

This is the file where you define all the variables for your site, that you're going to use across all your scss files.

Here you should define the spacing between sprites in sprite map images.

// Generic spacing (at 1x) for sprites
$spacing-sprites-generic: 10px;

_flagsSprite.scss #

This is the file where you define the variables and the mixins for your flag sprites.

I suggest to @import your _flagsSprite.scss only in files that requires flag sprites. This speeds up build time a lot, by avoiding frequent images check on the file system.

// flagsSprite MAPS and URLS
$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);

// flagsSprite mixin
@mixin flagsSprite($spriteName, $renderSize: false, $offsetX: 0, $offsetY: 0) {
    @include use1x2xSprite($spriteName, $flagsSprite1xMap, $flagsSprite2xMap, $flagsSprite1xUrl, $flagsSprite2xUrl, $renderSize, $offsetX, $offsetY);
}

style.scss - standard usage #

If you don't need space around your sprite and you don't want Compass to generate box dimensions for you, you can simply do the following.

@import "compass/utilities/sprites";
@import "_variables";
@import "_flagsSprite";

// Simple usage
.exampleSimple {
    @include flagsSprite(italy);
}

That will produce the following:

.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 - with box size generation #

If you want Compass to generate box dimensions for you, you should do the following.

@import "compass/utilities/sprites";
@import "_variables";
@import "_flagsSprite";

.exampleWithDimensions {
    @include flagsSprite(italy, true);
}

That will produce the following:

.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 - with offset management #

If you don't want Compass to generate box dimensions for you, but you want to use an offset inside the box, you should do the following.

@import "compass/utilities/sprites";
@import "_variables";
@import "_flagsSprite";

.exampleWithPadding {
    @include flagsSprite(italy, false, 10, 10);
    width: 52px; height: 52px;
}

That will produce the following:

.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;
  }
}

That's it #

Automatic sprite generation using Compass considering all the factors can be quite complex, but if you follow this guide it will be easy and also easier to maintain.

You you found any issues with this post, please tweet me and I'll fix it.

A new LazyLoad to improve your website performance

2014-11-20T00:00:00Z

In the latest days I've been working on websites performance optimization and I realized that there is no way to take advantage of the progressive JPEG image format on websites if you're using jQuery_lazyload. So after sending a pull request to its author, I decided to write my own lazy load, which turned out to be better, because:

it's 6x faster
it allows you to lazy load responsive images
it doesn't depend on jQuery
it best supports the progressive JPEG format

More information on the GitHub Repo.

CSS 3 only spinning "loading" animation

2012-10-03T00:00:00Z

We used GIF images to create animations for years, but they aren't pretty to be used over gradients or pictures (no alpha channel, no anti-aliasing) of which modern web sites are full. There are many workarounds to animate PNG images instead, but...

I want to show you a solution I found to create a "loading" animation from scratch, using only CSS 3, without images.

Results first #

See the Pen CSS 3 only spinning circle quarter - loading animation by Andrea Verlicchi (@verlok) on CodePen.

What happens here #

The core of this is to draw a quarter of circle and animate it. Read on to know the bottom-up steps to do it.

1. Create a circle #

<!-- Inner masked circle -->
<div class="maskedCircle"></div>

/* Spinning circle (inner circle) */
.loading .maskedCircle {
	width: 20px;
	height: 20px;
	border-radius: 12px;
	border: 3px solid white;
}

2. Mask one quarter of the circle #

<!-- Mask of the quarter of circle -->
<div class="mask">
    <!-- Inner masked circle -->
    <div class="maskedCircle"></div>
</div>

/* Spinning circle mask */
.loading .mask {
	width: 12px;
	height: 12px;
	overflow: hidden;
}

3. Make both spin around #

<!-- We make this div spin -->
<div class="spinner">
	<!-- Mask of the quarter of circle -->
	<div class="mask">
		<!-- Inner masked circle -->
		<div class="maskedCircle"></div>
	</div>
</div>

/* Animation keyframes */
@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. Wrap everything in a "loading" container, that will be centered inside its parent #

<!-- Loading animation container -->
<div class="loading">
	<!-- We make this div spin -->
	<div class="spinner">
		<!-- Mask of the quarter of circle -->
		<div class="mask">
			<!-- Inner masked circle -->
			<div class="maskedCircle"></div>
		</div>
	</div>
</div>

/* Loading animation container */
.loading {
	position: absolute;
	top: 50%;
	left: 50%;
	width: 28px;
	height: 28px;
	margin: -14px 0 0 -14px;
}

Resulting HTML and CSS code: #

<!-- Loading animation container -->
<div class="loading">
	<!-- We make this div spin -->
	<div class="spinner">
		<!-- Mask of the quarter of circle -->
		<div class="mask">
			<!-- Inner masked circle -->
			<div class="maskedCircle"></div>
		</div>
	</div>
</div>

/* Animation keyframes - you need to add prefixes */
@keyframes spin {
	from { transform: rotate(0deg); }
	to { transform: rotate(360deg); }
}

/* Loading animation container */
.loading {
	position: absolute;
	top: 50%;
	left: 50%;
	width: 28px;
	height: 28px;
	margin: -14px 0 0 -14px;
}

/* Spinning circle (inner circle) */
.loading .maskedCircle {
	width: 20px;
	height: 20px;
	border-radius: 12px;
	border: 3px solid white;
}

/* Spinning circle mask */
.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;
}

Isn't that cool?

It works perfectly on all desktop browsers like:

Internet Explorer 10+
Edge
Chrome
Firefox
Safari
Opera

and also for all major mobile browsers:

Safari Mobile
Chrome Mobile
Firefox Mobile
Opera Mobile
Internet Explorer Mobile (Windows Phone 8 only)

At the moment, Windows Phone 7's Internet Explorer won't animate the figure.

The fallbacks? #

Need a fallback to see the animation in older browsers? If you read so far, you probably do.

Although the fallback is not the purpose of this article, let's say that the best solution would be preparing a sprite with all the frames of the animation at a constant distance one from each other, use the sprite as background of a DOM element, and animate the background with Javascript.

Andrea Verlicchi

Claude vs Gemini: My Use Cases

Claude in Claude Desktop #

Claude in Claude Code #

Gemini in Antigravity / Antigravity IDE #

Gemini (web / desktop) – Personal Account #

Gemini (web / desktop) – Work Account #

Gemini (web / desktop) – Both Accounts #

Should we stop using the word "Responsive" for design?

The mobile definition of "adaptive" (Android and iOS) #

The web performance definition of "responsiveness" #

The terminology collision #

A proposal: Split the terminology #

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

Watch the video #

Slides #

Google Antigravity 2 & Gemini 3.5 Flash: this AI duo changed my dev workflow... again

Seamless Multi-Project Workflows #

Under the Hood: Gemini 3.5 Flash is Fire #

What Are You Waiting For? #

My dream of a container image format: a call to the web community

Andy's TL;DR #

I have a dream #

A call to the community #

Talk: Enhancing Web Responsiveness at Web Day 2026, Milan

Refactoring Gender Bias, One Commit at a Time

Bologna Front-end 🇮🇹 #

DevRomagna 🇮🇹 #

GitBar Podcast: Non toccate quel tag!

Watch / Listen #

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

Talk video: "Ehi Gemini, sistema il CSS!", Bologna Front-end #58

Watch #

Google Antigravity: The New IDE That Embraces Agentic AI

Learn the basics of Google Antigravity #

Google Antigravity: The New Best AI Editor? #

Improving Web Responsiveness - Interactivity improvements from real-world cases

The macOS clipboard manager you've been waiting for, now native in MacOS 26 Tahoe

Enabling Clipboard History #

Using the Clipboard History #

A Few Things to Note #

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

Introducing yieldy-for-loop: an npm package to keep your loops non-blocking (and your UI smooth)

Background #

What it does #

Installation #

Usage example #

How it works #

Why you need this #

Next steps #

Shout-out #

Conclusion #

Optimizing SVG Usage for Web Performance: A Comprehensive Discussion

1. Inline SVGs #

2. <img> tag #

3. CSS background images #

4. SVG sprites and <use> tag #

Match method to your use case #

Performance considerations #

Styling and interactivity #

Accessibility and semantics #

Avoid outdated techniques: #

Conclusion #

Further reading #

Talk video: "How I made the web more responsive — real-world case studies of INP optimizations", We Love Speed 2024 conference

The web is dead, long live the web (repost in English)

My experience at performance.now() 2024: Europe's premier web performance conference

Exceptional Content and Speakers #

Connecting with like-minded professionals #

Contributing in the help desk sponsored by Google #

Participating in Henri Helvetica's live interview on YouTube #

Pre-event: Performance.Sync by Mozilla #

Captured insights and follow-ups #

Reflecting on the Experience #

How to use Google Meet with two screens: separating shared content and attendees' faces

Step-by-step guide to using Companion mode #

Why this setup works #

Final thoughts #

True full-screen mode for Google Meet shared content

The remote work debate: my view on finding balance

2. `<img>` tag #

4. SVG sprites and `<use>` tag #

An infinite loop with `while(true)` #

An infinite loop with `setTimeout()` #

`requestAnimationFrame` #

An infinite loop with `Promise.resolve()` #