0.76.0 breaks lazy loading on my website

I immediately upgraded to 0.76.0 after I got notification from GitHub. I tried it and was shocked. My previously working fine website, doesn’t work fine anymore. I am lazy loading images, but, that script isn’t working on 0.76.0. I even pushed a changed to my website on Netlify, just to make sure that it’s not specific to my local machine and well, it’s happening there too. For a final confirmation, I reverted back to 0.75.1 and pushed it to Netlify and the website works again. There are no errors in JavaScript console, nothing. It just doesn’t work.

My website: https://hrishikeshk.netlify.app/
My repo: https://www.github.com/Hrishikesh-K/Portfolio/

If someone else can confirm this and possibly let me know about a fix, that would be great. I don’t immediately need 0.76.0, but, I like to keep the dependencies updated.

Update: 0.76.1 has the issue too.

Please try to be polite and try not to use words such as “shocked” when you ask for help about issues with an open source project.

2 Likes

I’m sorry, I didn’t realise that shocked would be considered impolite. Back at my place, we casually use it to express surprise.

What I meant was, I was taken by surprise. Basically, this wasn’t something I had anticipated. I just thought, it’s an update, doesn’t mention any breaking changes, so, updating won’t cause any problems. But when it did, that was something I had not seen coming. I’m sorry if this is still impolite.

I definitely didn’t intend to be impolite. I apologize again if it felt so. I’ll keep that in mind.

I’m experiencing an issue with the JavaScript minification with 0.76.x, so curious to know if your issue is related.

It’d be helpful if you could work out what is going wrong when the site is built. Can you maybe make a copy of the compiled, minified HTML and then compare that to the compiled, minified HTML with 0.75.1?

I just did that and I can definitely confirm something has changed in minification. HTML leaves no space between attributes now. So, I’d have to find more in my generated script to find the cause of the problem.

Here’s a short overview of the changes:

Left: 0.75.1
Right: 0.76.1

See https://github.com/gohugoio/hugo/issues/7792

1 Like

Here is a tip. Don’t. We are using SEMVER. That means right now Hugo is not even a fully finished product (major version is 0). Minor versions (76) might introduce incompatible features. Patch versions (0) will fix issues.

On a testing page you can upgrade to the latest version as soon as they are out. Upgrade, run Hugo, create an issue with anything that turns up (like broken lazy loading).

On a “live” website keep the “last known working version” until you see a day or two after a minor release that nothing larger turns up. I have sites that run under 0.56 because they did not change since then. Why going through the hoops if you don’t need to? Once the static website creator Hugo ran and the website is created nothing will change on the website without content being changed. A version change is not content :slight_smile:

“Never change a running system”. Get a tattoo with that mantra.

If Hugo ever goes 1.0.0 the rules change slightly:

  • updating major versions (2.0.0) will introduce breaking changes
  • updating minor versions (1.1.0) might break your site (by accident) but should not introduce breaking changes
  • updating patch versions (1.0.1) should be a “I updated once I saw the notification” thing.

And even then: if anything breaks it’s not a pitchfork and torch thing. It’s open source. You have a Github repo, you go back a version, you recompile, your website is up and all is well. You found a bug. You helped a project to get better.

Right now, if your website is working, go to your repo and type git tag last-known-working-version. If anything ever happens in the future you can go back via git checkout last-known-working-version. This of course is a quick and dirty thing, you might want to just start using version numbers for your own site using this.

1 Like

That’s a super detailed response. I’ll implement the versioning soon.

1 Like

Sure, but that is not what this thread is about. This was a bug – nothing about semver saves you from doing stupid things. Also, we do take backwards compability seriously, most breakage falls into the accidental category. I know of Hugo sites built for v0.16 that still runs fine on the latest version.

2 Likes

but it gives you an easy duck-out :wink:

I’m the developer of minify and ran a test with your website. I downloaded the source from your repo, updated Hugo to 0.76.0 and ran hugo server --minify. The website displays fine and everything seems to work well. I’m not sure how to reproduce this bug without further information. Do you have something specific such as an error or what exactly doesn’t work?

Side note, Hugo seems to take about 1min to build the website, why is it so slow? It’s stuck at “syncing static files to /”, but those files are not that big, right?

1 Like

Sadly, my JS console doesn’t throw any errors. However, the way the images are set-up is as follows:

In the HTML markup, a low quality image is declared which the class as ‘lazy’ which is stretched to fill the container width and a CSS blur filter is applied. The lazy loading library waits for the image container to enter the viewport. As the image container enters the viewport, the library starts to load the actual high quality image and when that high quality image is completely loaded, it adds a class ‘loaded’ to the container which removes the CSS blur filter and the image is fully visible. You can check the expected behaviour on my current live website: https://hrishikeshk.netlify.app/. Not just on the home page, but, I’m using lazy loading on my entire website as I intend to use high quality images (on average around 1 MB which still take long to load especially on mobile networks).

That’s the expected behaviour, however, with 0.76.0 and 0.76.1, the high quality images never load, thus, the class of the container never changes and my images are blurred out for eternity. Are they loading fine on your machine? I don’t know what exactly is going wrong in minification, but, since browser doesn’t throw any errors, I’m guessing, the JavaScript is fine, but, I don’t know why it won’t work then.

Really? When I build for the first time after my laptop restarts, it takes around 20 seconds, later on, it’s hardly a second.

@tdewolff this is just one of several (at least 3) reports about broken sites due to this/these JS issue(s)

I’m able to reproduce the issue @Hrishikesh describes using his site source and Hugo v0.76.2 (the minify upgrade was reverted in v0.76.3). If I downgrade minify to v2.8.0, the problem goes away. The problem appears with v2.9.0+.

But, as @Hrishikesh says, there are no messages in the Chrome console, so I’m not sure where things are going sideways.

PS - Hugo builds his site in under 800ms for me.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.