Here is an example of where things have gone wrong. Inter is loaded via @font-face and assigned to a font family called 

, this is a weight 900 font. But later on for the 

-class, the font is used but ‘transformed’ into a weight 300 which manipulates the font to look thinner.

Instead what would have been better is to define all weights needed to a collective font family called 

 and then grab the correct font file based on the assigned weight.

Use the right font for the job

In practice, this means that if I publish a new blog post the first visitor that visits my page after that will not see the new post but in the background the server will check and regenerate the page for the next visitor. In some cases, this wouldn’t be a good approach as the content isn’t always up to date and you can end up with different versions of pages for different visitors depending on caching strategy used by the framework and host.

Next.js makes using ISR incredibly simple, using the getStaticProps hook you can return a revalidate key with a value for how quickly content should be regarded as stale.

I use it on the pages containing data grabbed from my CMS like the front page, blog, and game-shelf. I do not publish any content that is critical for my visitors to get right away and generally I make sure to check how everything looks once I publish a new post which means the only one visiting the page and seeing an old version is me. The reason I didn’t go the static generated route is that I do not want to have to trigger a redeploy of my code to build the latest blog posts.

For anyone considering using ISR I would suggest thinking about how critical it is for the content to be completely up-to-date at all times and weigh that against the performance benefits of having the pages served statically instead of generated on demand by the server. It all comes down to the use case.

Some thoughts on ISR, and why I use it

When I decided to re-make my website I first thought about building it in a vue.js framework like Nuxt or Gridsome depending on how I wanted it to be hosted, but in the end I chose a different route. I realized that this would be the perfect time to not only build something new but also learn something new so I went with a front-end framework and a CMS I hadn’t worked with on a real project before. I decided to go with 

 as the headless CMS. As always I also used 

I’ve enjoyed the workflow of building the site in Next.js and I do like the ease of customizing the Sanity Studio (administration panel) to fit my needs with post types and fields. I will hopefully write a more comprehensive post on my thoughts on working with these projects soon. If you have any questions feel free to 

Rasmus Johansson

Hello!

Blog

Use the right font for the job

Some thoughts on ISR, and why I use it

New year, new website