DEV Community: M4rrc0

Lazy loading images, so easy you won’t believe it (a native strategy)

M4rrc0 — Fri, 10 Jun 2022 06:47:27 +0000

tl;dr

The code is pretty easy to grasp. Read the comments and you should be good to go.

<div class="img-lazy-wrapper"> <!-- We need a wrapper for the placeholder while image lazy loads -->
  <img
    src="/assets/lazy-bear@528w.96b21f25.png" <!-- Compress your image -->
    alt="A lazy bear" <!-- Don't forget the alt attribute -->
    loading="lazy" <!-- Native browser lazy loading -->
    width="528" <!-- Specify width and height so the browser can allocate the appropriate space for the image -->
    height="560"
    class="img-lazy"
    onload="this.parentNode.style.backgroundColor = 'transparent';this.style.opacity = 1;">
        <!-- Transition: Fade the image in and the background out -->
</div>

<style>
.img-lazy {
  opacity: 0; /* Start with image hidden */
  transition: opacity 1s; /* Transition to make the appearance smoother */
  max-width: 100%; /* Avoid image punching out of the screen  */
  height: auto; /* Necessary to keep aspect ratio if width is reduced by max-width */
}
.img-lazy-wrapper {
  width: -webkit-fit-content;
  width: -moz-fit-content;
  width: fit-content; /* Make the wrapper borders stick to the image. Otherwise, would stretch horizontally */
  transition: background-color 1s; /* Make disappearance smoother */
  background-color: var(--color-img-placeholder, rgba(200, 200, 200, 0.3)) /* Basic placeholder */
}
</style>

<noscript><style>
/* Overrides opacity and background-color in case we have no JS to get them it back */
.img-lazy { opacity: 1; }
.img-lazy-wrapper { background-color: transparent }
</style></noscript>

Intro

Us developers really like to reinvent the wheel. Lazy loading images has been a topic of choice to do that.

Nevertheless, we couldn't easily find an elegant, native, lightweight solution we like to implement by default on poko. So here is our solution for now.

Our prerequisites

Use the platform as much as possible
Should provide a minimum viable experience on older browsers and without javascript
Progressively enhanced (image placeholder while loading, transitions, ...)

A solution

Compress images
Determine the dimensions of each image
Activate native lazy loading in browser
Progressively enhance with some styles and two lines of javaScript.

1. Compress images

There are many ways to do it and your development pipeline might have a mature native solution already.

If you are not a tech person and you are not sure your CMS or website builder handles it for you, there are many tools online to compress images.

In our case, using Astro, we simply used astro-imagetools to compress images automatically while importing them. We might improve this later, for example generating multiple image sizes and formats, reducing the load even further for modern browsers. Currently, it checks our box though.

2. Determine the dimensions of each image

This is necessary to make use of some native browser image handling. Providing width and height attributes to <img> tags allows the browser to reserve space for your image before it loads. It is necessary to avoid having content jump around when images load. It used to not be enough to set these up but now it is.

Again, there are multiple ways to get dimensions and your development pipeline might just provide this information by default. In case it doesn't, we have found a nice and small npm package called probe-image-size. It allows for 'probing' an image locally or remotely.

import probeImageSize from "probe-image-size";

const imageData = await probeImageSize(url);

console.log(imageData);
// {
//   url: 'https:// ...',
//   width: 528,
//   height: 560,
//   type: 'png',
//   mime: 'image/png',
//   wUnits: 'px',
//   hUnits: 'px',
//   length: 47951
// }

3. Activate native lazy loading in browser

This is the easy part. Simply set the attribute on your HTML <img> element: <img ... loading="lazy" ... >

The HTML for the image becomes:

<img
  src="/assets/lazy-bear@528w.96b21f25.png"
  alt="A lazy bear"
  loading="lazy"
  width="528"
  height="560">

4. Progressively enhance

Now in modern browsers, we have got a compressed image that is lazy loaded and an allocated space on the page before that. That is great!

Now we'd like to create a transition effect so that visitors understand that something is loading on the reserved space.

On the image itself, we can use the onload attribute to 'do something' when the image is loaded.

The simplest placeholder we can think of is color. So let's color up the reserved space while the image is loading then fade out the color and fade in the image.

First some styles on the <img> and a wrapper <div> for the color.

<style>
.img-lazy {
  opacity: 0;
  transition: opacity 1s;
  max-width: 100%;
  height: auto;
}
.img-lazy-wrapper {
  width: -webkit-fit-content;
  width: -moz-fit-content;
  width: fit-content;
  transition: background-color 1s;
  background-color: var(--color-img-placeholder, rgba(200, 200, 200, 0.3))
}
</style>

Some explanations:

max-width and height is to allow scaling the image according to its context (the browser window or a parent element)
width: fit-content; (and its prefixed versions) is to avoid having the wrapper div stretch wider than the image. Instead it will stick to its content's dimensions.
We load the page with 0 opacity for the image (it will fade in while it loads) and a background-color on the wrapper div (it will fade out when the image loads).
transition is to create the fading effect.

Note: we would very much like to avoid the wrapper <div> but could not find an elegant alternative. Please share if you have one.

Our HTML becomes

<div class="img-lazy-wrapper">
  <img
    src="/assets/lazy-bear@528w.96b21f25.png"
    alt="A lazy bear"
    loading="lazy"
    width="528"
    height="560"
    class="img-lazy"
    onload="this.parentNode.style.backgroundColor = 'transparent';this.style.opacity = 1;">
</div>

Note the onload attribute on the <img> tag. That is the only javaScript we need to make the transition from placeholder to image.

Of course, if we rely on javaScript to display the image, we should have a fail safe mechanism for visitors without JS. In this case, we simply remove the transition effect.

<noscript><style>
/* Overrides opacity and background-color in case we have no JS to get them it back */
.img-lazy { opacity: 1; }
.img-lazy-wrapper { background-color: transparent }
</style></noscript>

Compatibility and final thoughts

According to my limited research (and the caniuse website), around 80% of users (in May 2022) should benefit from the whole technique. 20% of visitors will have a limited experience, either image is not lazy loaded, or content is jumping on image load, or the wrapping div will be wider than the image, or there will be no background transition effect... something like that. In any case, they won't have trouble seeing the content and that is the point.

We love solutions like these which are lightweight and use the platform as much as possible. Technical debt is reduced to a minimum. It makes them future proof and compatibility ratio will only increase with time.

Moreover, with poko we are not forcing this on anyone since using this component is optional.

Building my own static site generator for Svelte

M4rrc0 — Thu, 12 Mar 2020 12:52:01 +0000

Originally posted on https://www.m4rr.co/blog/building-my-own-static-site-generator-for-svelte/

I have been using GatsbyJS since early V2 Alpha. At the time Jamstack was barely a thing but for a newbie (like me at the time) coming into web development and interested in performance and developer experience it was a golden gate wide open and full of fun promises.

It has been so fulfilling to learn web development in the Jamstack communities we have today.

What I have done since

I have been freelancing and doing web projects with React and Gatsby mostly.

A large portion of my time has been going in building toile.io and the Gatsby site builder that it uses. To be honest I don't know if this project is good or bad. I have been told things like "it is not a 'real product' since you don't offer your own editing experience" (editing is done through Contentful). At the same time, clients are happy with the result and it allows me (and my graphic designer partner) to build customizable websites fairly quickly.

While there is a lot of things to improve I think I am reasonably proud of it considering 90% of the code has been written when I was 2-3 years into programming.

I have also done all the classic mistakes a beginner can do. That alone probably makes the experience worthy.

The frustrations

Despite all the good stuff Gatsby was doing for me, frustrations arose. Gatsby is doing a lot of things under the hood. I would argue that it is mostly built for beginners. You can certainly build very big and complex projects with it but then you need a level of expertise that could make Gatsby useless.

The GraphQL layer is a good example of hidden complexity. It is a great way for beginners to be able to explore their data. As a beginner, you feel good using this shiny newish tech and understanding what happens to your data and pulling it in your components. So great...

Then you land on a "bug"... except you are told "that is how GraphQL works...". You know there are clear solutions but you have no idea how to implement this with GraphQL. So you try to find a workaround because you want to stay focus on your project. And here you are 3 years later, still stuck with your workaround...

I am not going to expand on this point because I trust that you have either experienced the same kind of issue or are perfectly happy with your stack.

Bottom line: I have spent countless hours trying to figure out how to solve or work around problems that were very much Gatsby specific. I probably learned a few things from this but mostly it made me knowledgeable with Gatsby, not so much web development in general.

Decoupling your code from the tools you use

The GraphQL layer has become a real burden in my Gatsby site builder. Every time a solution to one of my problems arise it brings new problems that I need to investigate. And every new Gatsby functionality makes the API and the ecosystem wider as well which probably makes it even harder for the Gatsby team to tackle the broad array of issues.

As an experiment, I tried removing usage of the GraphQL layer from my Gatsby site builder. I knew this would solve a bunch of issues I have been dragging for a long time. I didn't really evaluate the consequences of handling data manually but that is why it is an experiment. I wanted to find out.

The data fetching from Contentful took me an hour or so. I could just copy the interesting parts of the code from the gatsby-source-contentful plugin and the Contentful documentation is clear so it is a piece of cake.
Then I was doing a bunch of data transformations with Gatsby plugins like transforming markdown and creating some fields. Also a lot easier to do when you can just manipulate JSON instead of transforming a GraphQL schema...

In the end, I put my experiment on pause because I want to refactor core pieces of my app and some of these pieces were tightly coupled with the way I was handling data with GraphQL.

Bottom line: I cannot fully evaluate yet the benefits and costs of using specific tools but I know I want to pay more attention to spending time learning web development good practices and spend less time debugging specific tooling I have little control on.
We know we need to modularize but we don't really know how to do it until we are faced with our first deep refactoring. I guess that is one of those things that come with experience.

Alway pay attention to the coupling you are introducing in your code base when using specific tools. Ask yourself: "if I want to change this piece, how easy will it be?"

The trigger

Development has been slow on my Gatsby site builder. One reason is bad maintainability. Like I said before, I have probably done all the mistakes a rookie can do (at least I hope I have done most).

Between handling clients' requests, rewriting almost the whole app, implementing new features and improving scalability to be able to make it a business, setting priorities has been challenging to say the least.

One day, as I was disappointed by the loading time of the JS bundle on some clients' sites I re-discovered Rich Harris talk about Svelte Rethinking Reactivity. That lead me to some explorations on (among others) Svelte, Sapper, SSG, Svelvet, ...

I also tried Eleventy. It is super tempting to dig into and must be a delight to use for a personal site for example... I am just not sure I want to drop the 'framework feel' from my daily dev practice

One thought was haunting me:

That would be great to have a super lightweight and fast static site generator that provides the developer experience of a framework while being able to generate an SPA, a PWA or a plain and simple HTML site.

These wanderings and reflexions lead to this discussion.

And finally to launching this site (repo).

Building an SSG

I am finally building my personal site.

I decided to try and build my own static site generator along the way and more generally, create the editing experience I would like to provide to my clients and everyone creating its own personal web space. I am fairly happy with this decision so far. I have been making steady progress and haven't encountered a major road block so far. To be honest I didn't think development would be so smooth especially since I am navigating in uncharted water. JS is my language of choice but all the tools I am using were unknown to me a few weeks back.

The principles I want to follow:

sites must be fast to navigate and have a fast build time
boilerplate is ok if it removes the "magic black box" effect
use the simplest convenient tech possible / stay close to the platform
development experience of a framework
progressively enhance the sites on the principle of Andy Bell's "minimum viable experience", meaning we can use all the shiny new tech available as long as we provide a viable experience for older browsers.
no magic around Progressive Web App creation but sensible defaults

I should point out that the end goal is not simply a SSG but a portable website that is editable without code and customizable with code.

What does this SSG looks like so far

It is very much based on svelvet and snowpack. It is using Svelte only to compile JS and HTML files (no headless chrome or other prerendering engine).

It copies files with random extensions from the src folder to the dist folder
It compiles .svelte and .js files to the dist folder to be used as web modules directly in your application.
It compiles .svelte and .js files to the build folder as needed for server side rendering.
It generates hydratable HTML files for pages
- based on folder structure (every svelte component in src/_pages gets its HTML equivalent)
- programmatically with the src/routes.js file
It puts external dependencies in dist/web_modules as web modules thanks to snowpack

The result is a dist folder with HTML, JS and other assets files you can host on any static host. Files are not bundled so we get some kind of automatic code splitting.

Caveats

Web modules are not supported in IE. It means IE clients will only see our HTML so we need to provide them with a minimum viable experience.

Fun and interesting features

dev server with hot reloading (a bit clumsy at the moment)
CSS can be defined either globally in a CSS file or embedded in the HTML <head> (or inline on html elements if you need dynamic behavior)
can build 2 types of nav experience: "HTML to single page application (SPA)" (like Gatsby) or "each page its JS" (like Eleventy). You can even mix in the same project some parts as individual pages and some groups of pages as SPAs.
can write svelte components in markdown thanks to MDsveX.

WIP roadmap

RSS feed
be able to not load JS at all if we only want HTML and/or our page does not generate any side effect anyway
look into adding more preprocessors like sass, postCSS, ...
design the site with nuds (website design tooling that will be the subject of other articles)
better handle external libraries
make hot reloading work properly
check how to safely remove CSS from JS components created with svelte (should be safe when an HTML page is created but not if it is a client-only route in SPA mode)
looking at Progressive Web App creation
looking at integrating IndieWeb functionalities
incremental builds would be nice

If you are curious, please test it out but don't expect any kind of support until I experiment with it more and decide to release it in some fashion. Nonetheless I would greatly appreciate any constructive feedback or general opinion.

Get in touch on Twitter
Subscribe to the newsletter
Support my work on Patreon