Lazy Loading Images, the Jekyll Way

Posted September 10, 2018. 834 words.

Intersection Observer is a relatively new API with decent support that can have a huge impact on performance. It has many uses and can trigger all sorts of code but this article is simply looking into performance. With it, image lazy loading can be quickly and easily added to any site including static Jekyll sites.

To start, define a variable to store the Interaction Observer. For simpler deployment, the code below avoids using modern JavaScript features such as let and arrow functions.

var observer

Secondly, a function to load a given image. Here, a temporary image is created to load the image and if successful the source of the actual image is replaced.

function loadImage(image) {
	var i = new Image();
	i.onload = function() {
		image.classList.add('lazy-loaded')
		image.src = image.dataset.lazySrc
	}
	i.onerror = function() {image.classList.add('lazy-error')}
	i.src = image.dataset.lazySrc
}

Thirdly, a function to process intersections. It checks which images are currently intersecting.

function onIntersection(entries) {
	for (var e in entries) {
		if(entries[e].intersectionRatio <= 0) continue
		observer.unobserve(entries[e].target) // Stop watching
		loadImage(entries[e].target)
	}
}

Fourthly, lazyily loaded images are located and the code is run.

var images = document.querySelectorAll('img[data-lazy-src]')
if ('IntersectionObserver' in window) {
	observer = new IntersectionObserver(onIntersection, {rootMargin: '250px'})
	for(var i in images) {
		if(typeof images[i] === 'object' && 'classList' in images[i] &&
			 !images[i].classList.contains('lazy-loaded') &&
			 !images[i].classList.contains('lazy-error')) {
			observer.observe(images[i])
		}
	}
} else {
	for(var image in images) loadImage(image)
}

But, the code above can only lazy-load images with very specific markup. This is where this nasty piece of Liquid code comes in. Liquid is fundamentally a very limited language with no direct way to initialise arrays, weird syntax, and no regular expressions. So, instead of using regular expressions, we can instead create a nasty piece of splitting code which works just well enough for the job.

The HTML Jekyll generates from Markdown is simple and regular enough for the following code to work. I would not expect it to work for more complicated HTML. But it’s worth a shot!

{%- assign excerpt = content | split: '<img src="' -%}
{%- for e in excerpt -%}
	{%- if forloop.first == true -%}
		{{ e }}
	{%- else -%}
		{%- if e contains '" alt="' -%}
			{%- assign f = e | split: '" alt="' -%}
			{%- assign url = f | first -%}
			{%- assign g = f | shift | join: '" alt="' | split: '"' -%}
			{%- assign alt = g | first -%}
			{%- assign rest = g | shift | join: '"' -%}
			<noscript><img src="{{ url }}" alt="{{ alt }}" /></noscript><img class="script-required" src="#" data-lazy-src="{{ url }}" alt="{{ alt }}"{{ rest }}
		{%- else -%}
			{%- assign f = e | split: '"' -%}
			{%- assign url = f | first -%}
			{%- assign rest = f | shift | join: '"' -%}
			<noscript><img src="{{ url }}" /></noscript><img class="script-required" src="#" data-lazy-src="{{ url }}"{{ rest }}
		{%- endif -%}
	{%- endif -%}
{%- endfor -%}

Now I recommend styling the unloaded images with width and height. If known ahead of time it can be set explicitly. Failing that, I recommend setting a generic default using CSS.

img {
	min-width: 100px;
	min-height: 100px;
}

And finally with this in place, my site often enjoys a perfect score in Google Chrome Inspector Audit. It cleanly beats google.com which has a top score of 91 and even beats motherfuckingwebsite.com in every category but performance where it draws at 100.

(100) Performance, (100) Progressive Web App, (100) Accessibility, (100) Best Practices, (100) SEO

StatCounter Pixel