Naguel

I'm Nahuel, and these are my work experiences, ideas and thoughts as a web developer working on the eCommerce industry.

Lazyload post Feature Image from Unsplash in Ghost

Lazyload post Feature Image from Unsplash in Ghost

Unsplash is a great Ghost built-in integration that allows you to quickly add an image to your posts, and I personally use it every time to add the Feature Image to all my articles (the big one below the title, before the content).

Unfortunately, out of the box the image from Unsplash is really big (2000px wide) and impacts on the page speed of the site since the browser will download the image first then continue with the rest of the page.

There's no much we can do about the image size as we can't follow the "How to use responsive images in Ghost themes" official guide because that only applies to images you manually upload and not those coming from third-parties...

Dynamic image sizes are not compatible with externally hosted images. If you insert images from Unsplash or you store your image files on a third party storage adapter then the image url returned will be determined by the external source.

...but with a little bit of HTML and JavaScript we can lazy load them to prioritize the content over the image download.

Usually, the Feature Image in the Ghost theme will look something like:

<img src="{{feature_image}}" />

This is a classic img tag with the src containing the URL of the image. But we need to do some changes here first before moving to the JS side of this technique.

In the src we are going to put a placeholder image to avoid having a broken image while the rest of the page loads, we are going to move the actual image to the data-src attribute, and finally we'll add a new class to the element.

<img src="{{asset "images/placeholder.png"}}" data-src="{{feature_image}}" class="lazyload" />

The placeholder image should be a small image in terms of weight. I'm using an image with a solid colour of 183 bytes so I can "reserve" the space of the final Feature Image to avoid "jumps" in the browser while everything loads.

Finally, the JS is quite simple. We need to wait for the window to be loaded, get all the img elements with the lazyload class, and replace the src with what's on the data-src so we trigger the actual image download.

window.addEventListener('load', (event) => {
    let images = document.getElementsByClassName('lazyload');

    for (let i = 0; i < images.length; i++) {
        images[i].src = images[i].dataset.src;
    }
});

With this in place we should see that the content is prioritized over the Unsplash image, and if we are using a placeholder we should see that first in the "Network" tab of our browser's DevTools, with the actual image loading later.

Change Googlebot crawl rate

Change Googlebot crawl rate

As weird as it sounds it could happen that Google hits your site at a pace your server won't be able to handle, causing page speed issues and a potential site down related to a high CPU usage and too many MySQL connections.

Google claims to be smart enough to be able to self-regulate the crawl rate at which it hits a site (they said that they have "sophisticated algorithms to determine the optimal crawl speed for a site"), but that's not true all the time.

If you can contact your hosting provider, they might be able to tell you the number of requests the bots are making (where around 20000 in the last six hours could be enough to cause issues) and the logs for those calls.

185.93.229.3 - - [23/Sep/2021:05:32:55 +0000] "GET /about/ HTTP/1.0" 200 20702 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Make sure that the IP you are seeing on the logs are really from Google not being smart about the crawl rate, and not a DDoS attack in disguise.

If you are certain about Googlebot being the one causing the problems with your server, you need to adjust the crawl rate first, and then block Google, temporarily, while you wait for the new crawl rate to take effect.

Adjust the crawl rate using Google Search Console

If you are thinking about controlling the crawl rate using the Crawl-delay directive on your robots.txt file, forget it. Google ignores that.

You need to use what's remaining of the old Google Search Console, not the new fancy one, here https://www.google.com/webmasters/tools/settings.

Selecting the “Limit Google's maximum crawl rate“ option will display a slider for you to configure a lower crawl rate.

How low? I can't tell you exactly, since that would depend on your site and server capacity, but as reference I remember configuring it as follow for a Magento project living on a size XL AWS instance.

1 requests per second
1 seconds between requests

You can try something like that, or even lower, maybe at 0.5 requests per second.

Block Googlebot temporary for a few days

So, here's the catch: the new crawl rate setting is not immediately applied.

After saving the new crawl rate you'll get a message saying that "Your changes were successfully saved and will remain in effect until Sep 17, 2021" but it's not until you open up the confirmation email that you'll read that "within a day or two, Google crawlers will change crawling to the maximum rate that you set".

This means that your site will keep on getting hit at the same pace for a day or two, so the solution is to block Google for that period of time while you wait for the new crawl rate to get into effect.

Remember to lift the ban on Google after 2 days, and monitor for the following days that Google isn’t affecting the site performance again (so confirming the new crawl rate is working, otherwise you might need to bring it down a little more).

Fun facts about the page speed of a website

Fun facts about the page speed of a website

Everybody, everywhere, all the time, is saying that page speed matters. We get it, we heard it a trillion times, and I'm not sure why we keep writing about it or discussing it.

Page speed matters as much as the sun is hot, period. If you are still in doubt then you're having a serious problem. Make your website faster, and do not argue this fact, as it will cost you money.

That disclaimer being made, you probably also read that Amazon run some test and found out that if their site become 1 second slower it could cost them 1.6 billions dollars a year. And that's 1.600.000.000 dollars.

How much is 1.600.000.000 dollars?

  • That's more than 133 millions dollars per month. An amount of money I probably never going to see in real life, at least not all together, whether you divide per months or even days (more than 4 millions a day).
  • In Argentina, that's 48 billions pesos considering the currency value by the time I'm writing this post.
  • That's 96 millions (just millions) kilograms of premium ice cream. That amount of ice cream means that you and your future generations can enjoy more than a kilo of ice cream per day starting today and for the following 200 thousands years.
  • If you buy an iPhone X, and iPad Pro, an Apple Watch Series 3... And then a MacBook Pro, an iMac Pro, an Apple TV... and finally an iPod Touch just because, you'll be spending around 20 thousands dollars meaning that for 200 years you can get yourself a brand new model of all this products everyday.
  • 320 millions Caramel Macchiato Venti from Starbucks.
  • A Magento Commerce licence could rise up to 125 thousands dollars per year based on expected annual gross sales revenue, meaning you can build 12800 new eCommerce websites using this platform.
  • The Apple Inc. v. Samsung Electronics Co. legal battle you probably read on the Internet doesn't event get near this number. Wikipedia talks about 539 millions in favor of Apple for the first US trial, and then 120 millions for the second US trial. It was pointless to check the legal battles in the other countries.
  • And my home banking doesn't let me enter 1.600.000.000 in any form's input.

It was hard to find the real source of this 1.6 billions dollars proclamation, so I'm not sure about the veracity of such statement but for the end of this post it is not 100% relevant.

What I did find is that Greg Linder, best known as the inventor of Amazon's recommendations, made a presentation in 2006 saying the following:

Every 100ms delay costs 1% of sales.
Greg Linder

Probably somebody took that statement, and calculated it to be 1.6 billions dollars a year.