DEV Community: Nikita Goncharuk

Do optimised images always bring load speed improvements?

Nikita Goncharuk — Sat, 12 Sep 2020 18:29:23 +0000

Here is the fourth and final article in an image optimization series for my blog built on Nuxt with NetlifyCMS.

In this article, I will go through the speed improvements I achieved.

I have run speed tests using Google PageSpeed Insights.

For testing, I chose these pages:

Index page with my work showcase.
Bio page with one big image of me.
Blog article with many pictures.

Let’s not delay the inevitable and check the optimization results:

Not bad as for me. It wasn't so bad before but got better.

On Google PageSpeed results

I also would like to mention one important thing I noticed while doing tests:

PageSpeed test could give really different results. It could show +-10 points from run to run. Don’t know what it depends on, but, for example, I was getting results as 88-90-91-80 on the absolutely same page. So craving for 1 or even 5 points is not so statistically significant. You should better focus on moving through categories of 10-20 points.

PageSpeed test could give really different results.

It's better to focus on moving through categories of 10-20 points with it.

But anyway let’s check what optimizations led to better speed results.

Main page

The main page contains three images with pretty different sizes, ranging from 330 kb to 1.22 Mb.

After loading optimized images from Netlify Large Media, I got small speed improvements.

Here is the detailed breakdown of image size differences before and after optimization:

Was 448x894 pixels image with a size of 330 kb. Became 250x499 image with a size of 140 kb.
Was 906x2000 pixels with a size of 422 kb. Became 250x552 image with a size of 96.1 kb.
Was 869x2000 pixels with a size of 1.22 Mb. Became 250x558 image with a size of 190 kb. Totally, 1.5 Mb of fewer data to be now loaded.

Also, 2 and 3 images are now lazy-loaded(I described what is this here).

All this resulted in moving from 99 to 100 points on desktop and from 93 to 96 on mobile. Should be enough for living.

Bio page

The main problem with the bio page is that it contains one photo of me.

With an original resolution of 1330x1330 pixels, its size is 2.14 Mb. And this results in a score of 84 on desktop and 90 on mobile. I’m pretty surprised that it loaded faster on mobile 🤔.

After loading the optimized image with the resolution of 250x250 pixels and the resulting size of 114 kb, desktop speed bumped to 100. Could not be better! But on mobile it stayed the same 🤷‍♂️.

Article page

Article I chose for the test contains 9 images with sizes ranging from 34 kb to 845 kb.

On mobile, it had the worst performance out of three test pages - only 59 points. This had to be changed. While on the desktop everything was pretty fine.

As I have written in the previous article, on blog pages images are usually loaded with 600 pixels width and in rare cases with 300px width, when the screen width is around or less than 200 pixels.

Loading optimized images increased score a bit on mobile. I have been getting something like 70 points on good test runs. Adding lazy loading at the same time bumped test scores to 80. Not the green score, but not as bad as it was. On a desktop, it became even 99.

Conclusion

Image optimization on the web is essential since images take a significant part of the page size. It should be especially crucial on images heavy websites. Even with my site, where aren’t a lot of images, I got page load speed improvements.

So answer to the raised question is Yes, doing image optimization on the website is worth it.

Nevertheless, setting up the image optimization service and finding the way to use it with images set in Markdown was a daunting task. Still, I don’t have any regrets I went through this.

If you build your site using the similar stack (headless CMS, front-end framework), feel easy to check what I have run into to give it a better and easier go.

To see more behind-the-curtain of my blog creation join me on Twitter as I continue sharing how I’m making it.

To see more behind-the-curtain of my blog creation join me on Twitter as I continue sharing how I’m making it.

Optimized image loading in HTML and Markdown

Nikita Goncharuk — Sat, 12 Sep 2020 18:29:03 +0000

This is the third article about image optimization I implemented in my blog on Nuxt with Netlify CMS.

In this article, I’m going to talk about how I implemented all this on my website. What worked and what didn’t.

Images in HTML

Let’s start with the images set using HTML.

This is how it’s done with me:

<img
  src="/img/sample_image.png?nf_resize=fit&w=250"
  loading="lazy"
  alt=". . ."
/>

Loading optimized images from Netlify Large Media

I add ?nf_resize&w=250 to load an image with a width reduced to 250 pixels and proportional heigh.

Why I chose 250px? I checked what is the maximum width of the particular image when it’s rendered and set the width accordingly.

On my site, images usually are shown in different sizes. For desktop browsers, it’s fixed width. On mobile, it’s wired to screen width, so it could range from 30px to 236px (something like this), so I simply chose 250px since it never gets bigger than this.

Additional parameters that can be specified on image request from Netlify Large Media you may find in docs.

Lazy loading

Adding loading="lazy" say that browser should load an image only when it’s close to the viewable viewport.

When I didn’t set that at the beginning, the page loaded in the following way: on page open, browser paints the first HTML and starts loading all images used on the current page and until it finishes page are shown as loading. If the page contains many pictures, that take time. Sometimes a lot.

When you set loading="lazy" browser loads only images that are in the viewable part of the page and in the area of 1250px-2500px down it (doc). At least on Chromium browsers it should work this way.

So, yeah, it could speed up page load a lot, since loading first 3 images and then others, as needed, is faster than loading more at once😉.

However, I didn’t set this for the first images on the pages, as advised officially here. These images are anyway going to be loaded on the page open🙂.

Trying `srcset` and `sizes`

I also tried to do responsive image loading with the following code from Mozilla:

<img srcset="path_to_image.png?nf_resize=fit&w=180 180w,
             path_to_image.png?nf_resize=fit&w=250 250w"
     sizes="(max-width: 400px) 180px,
            250px"
     src="path_to_image.png?nf_resize=fit&w=250"
     alt=". . ."
/>

As from code, it means that on screens with a width up to 400 pixels browser should request an image with this parameters: ?nf_resize=fit&w=180 180w. Hence with a width of 180 pixels. While on screens with a width of more than 400 pixels, it should load an image with this parameters: ?nf_resize=fit&w=250 250w. So the width should be 250 pixels.

But these didn’t work.

When specifying sizes in the percentage of vw (viewport), everything works, as you will see later on with Markdown images. But with px specifications nothing worked. Images were always loading with this parameters: ?nf_resize=fit&w=250 250w🤷‍♂️.

After playing with it for some time, I understood that I could simply leave it with one ?nf_resize=fit&w=250 250w parameter. As I had before, like this:

<img
  src="/img/sample_image.png?nf_resize=fit&w=250"
  loading="lazy"
  alt=". . ."
/>

My images become really responsive on mobile, and figuring out correct vw for different layouts is a considerable pain (at least for me).

I have also downloaded images to compare their sizes. 250px one was 114 kb, where 180px one was 63,3 kb. Quite twice a difference, but after running Page Speed tests with 180px image, I didn’t see any improvements🤷‍♂️.

Loading optimized images from Markdown

Doing all this optimization for blog posts is a bit more complicated.

All my posts are written in Markdown and gets converted into HTML by markdown-it plugin.

Markdown language has some specifications and limitations on how images are described. Here is the structure of the image specification: ![Alt text people will see if picture can’t be seen](https://link.of/image “Title to show under the image”). Not so many things we could specify. Luckily we can do a lot of modification on how Markdown is translated to HTML with the additional markdown-it- plugins.

Lazy images

First of all, I found and added a plugin that adds loading=”lazy” to every image that is rendered by markdown-it.

Here is it: markdown-it-image-lazy-loading. ! If you are also planning to load optimized images by adding URL parameters to images, then wait a bit before adding it. There is a way to use only the plugin I will show next without the need to install this one. Just proceed to the next section.

After setting loading="lazy" loading speed of blog pages with many images rocketed. This attribute is really must-have. Check the results in the next article.

Images with `srcset` and `sizes`

Then I tried adding markdown-it-responsive package that should add srcset and sizes attributes to every image, but this didn’t work at all. I have been getting HTML rendering error and broken pages☹️.

After some additional search, I have found this plugin: markdown-it-modify-token. After checking it, I understood that it would work great, and I can do everything I need with it.

Some time and this code was born:

modifyToken: function(token, env) {
  switch (token.type) {
    case "image":
      token.attrObj.srcset =
        `${token.attrObj.src}?nf_resize=fit&w=300 300w, ` +
        `${token.attrObj.src}?nf_resize=fit&w=600 600w`;
      token.attrObj.src = token.attrObj.src + "?nf_resize=fit&w=600";
      break;
  }
},

By specifying srcset this way I’m saying to the browser: here is two images, with the width of 300px and 600px, decide by yourself what image to load according to 100% viewport width.

First I also added size attribute, this way:

token.attrObj.sizes = “100vw”;

But removed it after reading Chris Coyier article. It’s the default value for the browser, so no need to specify that additionally.

It works, but the behaviour is a bit strange (at least for me). When screen width is 200px browser load image with 300px width, but when screen width is set to 250px image with 600px width is loaded… I don’t understand that😐.

And again specifying sizes in px only led to 600px image to be loaded…

Here is code I have tried:

token.attrObj.sizes = "(max-width: 400px) 300px, 600px"

Ok, I will just leave sizes as 100vw and let the browser decide when to load what. Hope browser is smart.

As I wrote before, the usage of markdown-it-image-lazy-loading plugin could be dropped here for additional code in

modifyToken: function(token, env) {

}

Just add this:

token.attrObj.loading = "lazy";

Here, in case "image"::

switch (token.type) {
  case "image":
    token.attrObj.srcset =
      `${token.attrObj.src}?nf_resize=fit&w=300 300w, ` +
      `${token.attrObj.src}?nf_resize=fit&w=600 600w`;
    token.attrObj.src = token.attrObj.src + "?nf_resize=fit&w=600";

    // This will make all images loading lazy
    token.attrObj.loading = "lazy";
    break;
}

By the way, if you want to always load images with one size, just remove srcset setter. It would look this way:

switch (token.type) {
  case "image":
    token.attrObj.src = token.attrObj.src + "?nf_resize=fit&w=600";
    // token.attrObj.loading = "lazy";
    break;
}

As you remember, it’s better to have the first images without lazy load, but it’s a bit hard to do with images from Markdown. Additional logic should be written for markdown-it, and the time investment is not really worth it for me. Yes, there is a small drop a performance, as guys from Google say, but it won’t break the bank, I think.

That’s all I have done for better image loading on my site. In the next article, you could check page speed improvements I got. They are quite solid😉.

To see more behind-the-curtain of my blog creation join me on Twitter as I continue sharing how I’m making it.

By the way, if you know why sizes can only work well with vw, share it in comments. I'm really interested!

Fixing Netlify Large Media install

Nikita Goncharuk — Fri, 28 Aug 2020 16:12:54 +0000

After choosing to use Netlify Large Media as image optimization service, I started setting it up. In this article, you could read why it was selected and how it works.

Here I will mostly use "NLM" abbreviation of Netlify Large Media for convenience.

First, using the docs, I installed Netlify CLI and authenticated. Then I went to the following docs on Large Media setup. After finishing the NLM installation on a PC without a problem, I set all files in static/img/ (where my site images are located) folder for tracking and pushed all that to Git. I fastly checked my GitLab repository and saw correctly looking pointers instead of images:

Then I checked that images are uploaded to NLM. Everything looked good. I was happy and went checking that everything is okay with the site after fresh build … and of course, it was broken. Not really broken(yet 😃), but with problems.

404 error on image loading from Netlify Large Media

After a correct build, images just didn't load on website open. I got baffled and dug into the documentation, searcing for possible missed step, but everything looked great. Many hours were spent trying to find the problem, and I even made an error that broke a project build(I would talk about this a bit later).

I was lost. So I decided to put a project off for some time. Before that, I just set deploy version to the last commit before changing to NLM. Luckily, you could quickly deploy every commit successfully build on Netlify, even old ones.

When I returned to the problem, I got an idea to check the browser console. I'm, as a mobile developer, used to getting all errors in IDE or in some additional services like Sentry or Crashlytics, and I didn't think about browser console, that could lead me to the error. Learning, learning the web… There I saw 404 error on the image fetch for the site with NLM. Some time searching and I landed on this.

So every problem was with this file: .git/hooks/pre-push. When I opened it, it was empty. After I runned git lfs update --force and git lfs push --all origin master then it got file filled with this:

#!/bin/sh
command -v git-lfs >/dev/null 2>&1 || { echo >&2 "\nThis repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting .git/hooks/pre-push.\n"; exit 2; }
git lfs pre-push "$@"

After this, I changed my site deploy version to the one successfully build with NLM enabled and saw all my images got correctly loaded on the website.

Oooooh. Good.

Nope. I also had another problem.

Netlify build error due to broken images

I couldn't build my projects anymore since I was getting Netlify project build error with a very unclear message:

Error: Could not find MIME for Buffer <null>
    at Jimp.parseBitmap (/opt/build/repo/node_modules/jimp-compact/dist/jimp.js:1:120817)
    at Jimp.parseBitmap (/opt/build/repo/node_modules/jimp-compact/dist/jimp.js:1:13252)
    at /opt/build/repo/node_modules/jimp-compact/dist/jimp.js:1:12318
    at FSReqCallback.readFileAfterClose [as oncomplete] (internal/fs/read_file_context.js:63:3) {
  methodName: 'constructor'
}
[error] 1
[error] (node:1318) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 1)
[fatal] 1

   ╭────────────────────────╮
   │                        │
   │   ✖ Nuxt Fatal Error   │
   │                        │
   │   1                    │
   │                        │
   ╰────────────────────────╯

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! Blog@1.0.0 generate: `nuxt build && nuxt export`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the Blog@1.0.0 generate script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /opt/buildhome/.npm/_logs/2020-08-09T13_27_15_157Z-debug.log

┌─────────────────────────────┐
│   "build.command" failed    │
└─────────────────────────────┘
  Error message
  Command failed with exit code 1: npm run generate

  Error location
  In Build command from Netlify app:
  npm run generate

  Resolved config
  build:
    command: npm run generate
    commandOrigin: ui
    environment:
      - NETLIFY_LFS_ORIGIN_URL
    publish: /opt/build/repo/dist

Everything I could understand from this is that problem was with images. But what, when and where…

When I first enabled NLM and pictures on the website didn't get loaded, I checked all documentation, and in Netlify CMS docs I saw this paragraph:

I understood provided Note in a way that I need to track all my .png files with NLM, or otherwise it won't work. That was utterly wrong since this was only related to the Media view in the CMS Admin console. So I mistakenly made track of all .png files in my project and pushed that to the repository. For reference, other .png files that I have not in static/img/ folder are website icons. And for some reason, these files didn't correctly load to NLM. I got site build fail with the error provided before. I got scared and tried to revert changes. But, but when you go for Git LFS and push tracked files to a repository, you have no easy way back 😬.

All that was before I decided to put the problem off and relax for some time. After I solved the problem with 404 error on image loading and returned to this one, I noticed that the images on my PC and in Git are looking strange. They weren't images, nor pointers. Some broken files:

�PNG

After some thought, I just changed that broken images for normal ones and of course stopped tracking all .png files, except ones in static/img/ folder. I pushed all that to the repository, and everything started to work! The project was built, and everything was working as it should.

"Finally!!!"- I wanted to say.

But that wasn't an end.

Problem with local images being pointers

I also had a problem with some of the images locally. In static/img/ folder, some of the images were normal ones(as they should be locally), while some of them were pointers. What? Pointers should only be in the repository on GitLab. While on PC they should be loaded as usual pictures. 🤬. When that (let's say a bad thing) will stop making problems? … Then I saw a warning in the GitKraken (Git client that I use). It said that the repository uses Hooks while it doesn't know where sh.exe file is located, so it couldn't function normally. I said okay, let's fix that. I didn't know if that would help, but anyway. I googled where to find sh.exe file on Windows, and everyone was saying that it should be in C:\Program Files\Git\bin, but I didn't have Git folder in Program Files… I thought okay, let's do the local search. After like 50 minutes, the Win search found +- 100 suitable files. After skimming thew them, I finally found where needed sh.exe file is located. If you are like me, here is the possible path for you:

C:\Users\username\AppData\Local\Programs\Git\bin\sh.exe

After I specified that path in GitKraken, it showed that there are files to pull. Or I by myself did the pull, don't remember for 100% unfortunately 🙁. The pull loaded all my images from NLM, and everything started to work as it should be on the local project!

Finally! Everything works!

Thoughts on Netlify Large Media after install

After the install, I had conflicting feelings. During the installation process, there were many problems. And the clearly opened fact that there is no easy way to revert everything back after you start using Netlify Large Media make me saying that using some other services(Cloudinary, for example) may be a better choice in most scenarios.

Speaking a little ahead, using the Netlify Large Media would help you to optimize images, increase website speed and help handle large-sized files in your repository.

But is this service worth possible problems? Now I hardly see its benefits over Cloudinary, and with the next project, I would rather go with Cloudinary. But, in the end, everyone needs to seriously weigh all pros and cons and make his own decision.

For this site, I will anyway now continue with Netlify Large Media. I anyway made an install, and it's working. And changing it to something else … not now for sure.

To see more behind-the-curtain of my blog creation join me on Twitter as I continue sharing how I’m making it.

Image optimisation service for Netlify CMS and Nuxt

Nikita Goncharuk — Fri, 28 Aug 2020 16:12:42 +0000

I ones wanted to distribute PDF files from my website and was looking for the ways to handle that with my Nuxt site on Netlify. During the search, I found Netlify Large Media service which intended to help to work with large files in Git. In this article, I will mostly use "NLM" abbreviation for convenience. So while I was skimming through its description, I saw the image transformation service that NLM provides. Basically, it makes images with custom sizes on load request. I found this interesting and made a to-do to investigate that.

While building my website, I just used .png images when I needed them. They all were simply located in one of my project folders. And since I use Netlify CMS, images from articles were also stored the same way. And some of the images were pretty big; for example, my picture in the bio page was 2.14 MB. As expected, those pictures sometimes were loading for quite a long time. Not really good. And from the SEO view, site speed is important. So I also started researching how this is usually handled on the web. There are many resources on that topic, and I fastly found service named ImageOptim, which provides the great-looking solution. But it isn't free nor at least offer a free plan. I also read several articles on the topic and got an idea of how it is usually done.

Then I got back to Netlify Large Media. Overall, it looked sufficient for my needs, and long requirements & limitations list looked not so scary. This service use Git Large File Storage that, instead of storing exact files in the repository, stores files somewhere else and put pointers to the files instead of them. And pointers are just fraction of the size of original files. NLM handle the creation of these pointers and stores files on its own CDN's thus enable making transformations on the images when they are requested. While, when you work locally you still have normal images(they are preloaded by Git), not the pointers, so you keep usual easy of use. In the project, you still just specify a path to it, like this: /img/some_image.png. With this, on a local project, the original image would be loaded. On the deployed site, an original-sized image will be fetched from NLM too.

And when you want to transform image, you just add properties to the path, like this: /img/some_image.png?nf_resize=fit&h=400&w=400. Then you will get an image with size reduced to 400x400 px dimensions on the deployed site.

Sounds good, but NLM is not a straight forward solution and completely change the aspect of working with selected files in Git. This can lead to a terrifying time if something doesn't get to work. And a project could completely break, as happened to me, as you can find out in this article.

One more important point was the fact that Netlify CMS should also support selected image optimisation service. So it would be comfortable adding images on articles creation. On-time of writing, there were just three supported systems: Cloudinary, Uploadcare and Netlify Large Media. I also checked the first two.

From my first sight, I wanted to use Uploadcare. It looked so sleek. It's a distinct service where you could upload and store your images and can do a lot of operations on them. All usual ones, like cropping, resizing, adding visual effects, etc. and something more special ones like AI face and objects detection on images. Image fetching in the project is also made by URLs with additional fields for needed transformation, very like with NLM. However, you specify not the local-like image URLs, but the ones from Uploadcare domains, since all your files are completely there. I liked the look of Uploadcare so much that this wasn't a problem at all. Yeah, a great visual presentation has a really high impact on buyers wishes 😉. But when I finally reached the Price page…Well, it's definitely wasn't for me ☹. Basic plans cost over $100 a month, which is something for more big guys.

Great visual presentation has a really high impact on buyers wishes

The third player, the Cloudinary, is very similar to Uploadcare. But for me, it looked less pleasant nevertheless definitely working. The big plus of Cloudinary is that they had a pretty generous free plan. Actually, the price was shown like this: ~~$17~~ - $0 🤔. I think this is just a marketing hack and the plan is always free, but who knows…

After some checks and thinking of what to choose, Cloudinary or Netlify Large Media, I finally went with Netlify Large Media. Mostly what bought me in NLM is that it's still kind of all-in-git approach and the fact that I would stay in Nuxt-Netlify ecosystem. Their pricing also looked pretty generous, and I would hardly reach the bar when I need to pay for it.

In my next article, you can read about my thoughts after installing Netlify Large Media and why I would rather go with Cloudinary next time.

To see more behind-the-curtain of my blog creation join me on Twitter as I continue sharing how I’m making it.

Road to JAMstack blog instead of classic WordPress

Nikita Goncharuk — Thu, 27 Aug 2020 09:05:06 +0000

Here is a bit of into:

As every person who thinks about creating a blog, the first thing I thought is creating one on WordPress. I even have created one a few years ago, and hosted for free on wordpress.com. I have written one article there, and then the blog got lost.

Then, after my first blogging approach, I have learned quite a lot of programming. Mostly mobile programming (I use Flutter for day-to-day programming and from time to time write some native code), and a bit of web development too. Well, I had taken 2 courses (front-end, back-end) on web development on .NET in university. Still, the only thing that stayed with me is writing back-end code and some Razor while front-end (html, css, js) was nearly forgotten.

In my spare time, I launched a few games build on Flutter to start earning money by creating some “cool” products. Up to the day, I have made only a few bucks but got pretty more profound in development. Unfortunately, I couldn’t live for just a few bucks, so I started thinking about what to create next. Ideas were coming and passing, and I caught myself with the fact that many ideas rely mostly on the web rather than mobile usage. So I started thinking more and more about learning web development ...

As every mobile developer coming to the web world, I got lost. It feels like coming from the hills to dense forest. If you want to develop something for mobile, you would need to make just a few choices: going with native development (Android - Kotlin / Java, iOS - Swift / Object-C) or with some cross-platform frameworks (Flutter, React Native , and some other choices with different degree of wildness). But when you want to do something on the web ... the number of options are nearly countless. Really, there are thousands of languages and tools for writing front-end, back-end or both in the same place ... Angular, React, Vue, Django, PHP, JavaScript, TypeScript, Laravel, Node, Rubys, .Net and thousand others. If you don’t want to drop a coin for few times and see where the chance gonna lead you, you could spend months trying to find some suiting tool for you, and you will still keep finding new and new ones with no end. I was feeling completely lost every time I was trying to understand how to approach the web. Well, there is AngularDart (the Angular with common to me Dart language), but Angular seemed overkill for the tasks I had in my mind. Doing projects on .Net seemed ... strange, it looked that no one on the web doing stuff on .Net. So this stayed in limbo ...

Now let’s get more closer to the topic:

During that time, I understood that I want to make myself a blog. Well, many different people write about their experience, and I liked to read their stories. And I thought that I may also have something to share.

Deciding where to build a blog

So I have dug into CMS solutions. WordPress was eliminated at the beginning since many bad things have been stated about it. You know, the security, hacks, other problems… Yes, there are a huge amount of plugins, tools, resources… But that didn’t buy me. During the research process, I have found many other CMS solution that looked better in my eyes.

In the end, I made a list of the tools to decide on. There were Craft CMS, Ghost, Statamic and Drupal. I really liked the look of Craft CMS, and Statamic also was very good. But after trying a sample of Craft CMS, I left a bit confused. It seemed kind of unintuitive in the way of building pages. And to run it, I needed hosting that cost at least 5$ a month, not a lot, but still money. Actually, I needed money to run any of them. Sad but what to do? Also, during the time of my research, Statamic charged more than 200$ for one site if you wanted to use it, which kindly removed it from the list. Recently Statamic got updated to version 3 with a free tier for personal usage, so it got much better in my eyes now. Additionally, Statamic blog could be generated into static pages now (in the next section you’ll see why this is an excellent addition). Ghost looked decent, it’s open-sourced as all 4 candidates with a good pack of plugins and resources available, while Drupal looked … a bit old … in design, feel … It shouldn’t be a huge problem, by the way, since it provides more plugins, themes, etc. compared to the previous three CMS’s. But, as every aspiring developer, I was looking for something fresh, new, cool …

Finding about static sites

This time, I have caught by Gatsby. Gatsby - I really liked the name for a tool. And the icon was appropriate. I read a bit about it, and also landed on Netlify page. I liked the look of their marketing sites, but it was still unclear how I can use that, so I just closed the tabs.

Later that time, I read something about JAMstack and, in some time, landed on their website. The message was right: fast sites and no need to run servers. So far sound good, and I dug deeper. Everything lives in Git, could be hosted literally for free... I have been bought.

Then I learned that Gatsby is used for making static JAMstack sites and many people host these sites on Netlify. You may think that everything was set. But not really. Something inside me just don’t want to go with React on which Gatsby is based. And after research about React vs Vue, the latest seemed like a better choice due to the easier learning curve. So I continued to search and found Gridsome, which looked like a complete Gatsby clone on Vue. So now he should be set, you may think. Not yet, sorry. I also have found Nuxt, which allows building not only static sites as Gridsome, but pretty standard, server run ones. So I thought that for long term learning Nuxt would be a better go. Now it is set. Partially. I also needed a CMS to operate with the content.

Choosing CMS

Choosing CMS for the static site was even a harder decision than selecting what to use to build a blog. After researching for the tools that are used with the static sites, I singled out several headless hosted CMSs and Git-based ones. For hosted ones, I was looking for those that don’t charge for basic usage, and choices were decent: Prismic, Storyblok, Contentful, ButterCMS. ButterCMS message was merely great: “Headless CMS you’ll melt over” - 15/10 points of greatness. There was also Strapi - it looked the best, but I needed to host it myself, so it didn’t fit.

In the same time, I was wondering if I should leave my content somewhere if I can have it all in my Git. With Netlify CMS, for example. And I really got stuck on this question. I was leaning toward Git-based CMS, but I still could not decide. Finally, I decided to drop a coin. I didn’t find any😂 and took a credit card instead. It worked great, and I got an answer - I need to go with Git-based CMS. I also made a small comparison between Forestry which is also Git-based CMS and Netlify CMS and decided to go with Netlify CMS at the end. The final decision was made mostly on the facts that Netlify CMS go well and fast with Netlify(surprise) that I wanted to use and are open-source. Additionally, I could preview the Netlify CMS admin interface, and I liked it. It was simple, clean, basically everything I needed.

Making it live

To make all this live, I followed setup instructions for Nuxt, Netlify and Netlify CMS, thankfully, they all are quite clear.
Only one thing that took a lot of time - is creating Nuxt project. On set up, you can decide between JavaScript or TypeScript for the primary language. I didn’t want to go with JavaScript, since using dynamically typed language after statically one is really the pain. But I thought that finding tutorials on JavaScript would be easier and went with it. You also may choose some additional modules, plugins which also took time to research what to add. But the biggest pain was selecting a linting package for js. To keep it short, I could not run even Hello World project before I have deleted all the linters.

Luckily, Netlify smoothed out my angry feelings later on since it is really no friction in use. Two clicks and your website is ready - great service. Connecting Netlify CMS also went without problems. Their docs lead through all the steps you may need.

And after some basic styling I, finally, got my website up and running.

To see more behind-the-curtain of my blog creation join me on Twitter as I continue sharing how I’m making it.

DEV Community: Nikita Goncharuk

Do optimised images always bring load speed improvements?

On Google PageSpeed results

Main page

Bio page

Article page

Conclusion

Optimized image loading in HTML and Markdown

Images in HTML

Loading optimized images from Netlify Large Media

Lazy loading

Trying srcset and sizes

Loading optimized images from Markdown

Lazy images

Images with srcset and sizes

Fixing Netlify Large Media install

404 error on image loading from Netlify Large Media

Netlify build error due to broken images

Problem with local images being pointers

Thoughts on Netlify Large Media after install

Image optimisation service for Netlify CMS and Nuxt

Road to JAMstack blog instead of classic WordPress

Here is a bit of into:

Now let’s get more closer to the topic:

Deciding where to build a blog

Finding about static sites

Choosing CMS

Making it live

Trying `srcset` and `sizes`

Images with `srcset` and `sizes`