I Rebuilt My Blog With SvelteKit. A comparison of my website built using… | by Percy Bolmér | Dec, 2022

Comparison of my website built using Jekyll and Svelte

Original photo by Antonio Guillem

A few months ago a colleague of mine recommended Svelte,

at first i thought

“Oh, a great new JavaScript framework, just what we needed, it’s not like there are hundreds of them”

I usually say I’m a backend developer, but I know my way around a few frontend frameworks, although I’m not in my prime in that realm. I’ve struggled to become familiar with React (using it professionally) and Jekyll (using it for my current blog). It took me a long time to become proficient in using them.

A video recording of this article if you prefer video

At first I was not interested to know about Svelte, but I heard more and more about it, then I saw that it won most preferred web framework,

I started reading more about it as it looked promising. Here’s a brief rundown of the information and features that caught my attention.

  • Web applications are compiled at build time, so they can be blazing fast customization,
  • Svelte is very easy to use with less complexity
  • No custom syntax, simple HTML, JavaScript, and CSS. Hence the entry level is low.

weak is a JavaScript framework, Svelte does not use a virtual DOM Like React or Vue to handle the state of the app.

The fact that no virtual DOM is used allows it to be svelte. truly reactive, This means we don’t need to do any hacks or boilerplate code to re-render the variable when we update the value. I think everyone who writes React applications has run into this problem at some point.

In Svelte, when we update a click counter etc, it gets updated automatically, no useEffects, useStateor other hook.

It’s a simple button component that increments a count, and prints that counter.

Current Count: count

you can try on above code REPL, The great thing about Svelte is that everything inside a single component has a scope. so changing p The color red will only affect the component in which the CSS is declared.

the one thing i loved Go, has simpler syntax and less boilerplate. Svelte promises the same thing but for web applications.

Another cool thing about Svelte is that instead of allowing the browser to do most of the processing, the server handles that. Web applications are compiled before being shipped to production, allowing the server to perform a bunch of build optimizations. This makes building blazingly fast websites an easy task.

Once you start learning Svelte, it won’t take long before you encounter the word SvelteKit, While Svelte is a JavaScript framework, SvelteKit is an application framework.

SvelteKit is used to build applications using Svelte, it adds a bunch of features. The two most important according to me are the following.

Prerendering is when a static site generator creates a static site that gets served when it is stored.

The application is calculated at creation time and static application Stored and served when the website is visited, this means load times are significantly reduced as the heavy lifting has already been done for the client.

This is not the same as server render, as it happens at build time, we can change the content only by rebuilding the application. But it’s a lot easier on the server because it doesn’t have to re-render everything.

prerendering A wonderful tool when you have a static website, such as a blog where all the content can be preset.

Note, it’s really easy to add SSR, prerendering and CSR with SvelteKit. So we can prerender what can be prerendered and no static components, and take advantage of other amazing features like SSR for other content.

Svelte itself does not have a way. That’s where SvelteKit comes in handy, and adds the possibility to easily root users.

SvelteKit enables file-based routing system, Using the filename prefix makes it much easier to control any code running on the server. +server.jsor on the client using +page.js, It’s similar to how we do it in Jekyll so I was familiar with it from the start.

Should I replace my Jekyll blog with a Svelte built blog?

My old blog was a template I found online that I thought looked cool, and it worked. The website was built using Jekyll, which I disliked from the start.

The things I didn’t like about Jekyll are:

  • It uses Ruby, which I have no interest in learning. You don’t have to code in Ruby, but it does take advantage of Ruby’s tooling around.
  • I’ve had a hard time getting used to Gemstone In Jekyll, many of them were out of date and had many dependency issues, conflicting versions, etc.
  • I experienced that it is really slow when working locally and making changes.
  • I had a hard time wrapping my head around how to use Jekyll, it had so many new terms and it didn’t seem clear to me.

I choose Jekyll based template because it was easy to deploy on GitHub Pages and fast to get going.

But since SvelteKit also supports building a completely static website using the Static Site Generator (ssg), there was no problem deploying it to GitHub Pages.

Given the fact that I didn’t like how Jekyll worked and the tools around it, and that I was more used to the tools used by SvelteKit, such as NPM, YARN, and Vite. I decided to try and rewrite my current blog with Svelte.

Fight to the death between Svelte and Jekyll

Let’s start with comparing websites and their performance. I would compare websites that use lighthouse, Lighthouse is present in any Chrome based web browser via the Developer tab (F12 to open), or via an extension. You can also run an online version of this using pagespeedinsights, I’ve deployed both applications to GitHub Pages, and will be running tests on the deployed versions.

Lighthouse is a tool for measuring your website SEO, performance, easy accessAnd best practices,

SEO is measured by checking that search engines can understand the content, that the page can be crawled and indexed, and that it is mobile-friendly.

Performance is a weighted value among the many metrics related to website speed, we will be looking at more of these metrics soon.

Accessibility is checked to ensure that your website is responsive and works for multiple screen sizes.

Best Practices Check that we are following Web Vitals best practices, that the page is not using deprecated technologies, and is fast and secure.

Home page of the old website — This is what the old website looked like, very simple.

The old splash screen when I get to my blog is very basic, it shows the 5 latest posts and a bit of text. It has very few images and looks very simple.

Let us run Lighthouse on this website and review the results. I would run Lighthouse for mobile devices as mobiles are generally slower and more widely used.

Old website home page — Score for the old home page

Lighthouse begins by giving us a summary of four metrics.

The performance was 44, which is bad. Lighthouse also gives us insight into why it falls short.

Old Website Home Page — Metrics based on the Lighthouse Report.

We can see that the most important metric is interactive time, Interactive time is how long before a page is “fully interactive”, meaning the page should respond within 50 milliseconds. my current website takes a surprising 16.7s, Note that this is on a mobile device which is often perceived to be slower than on a desktop.

If this is your first time using Lighthouse, you might think that 16.7 seconds is high, and it is. But it’s probably not as high as you might think. Running Lighthouse on Facebook.com gives me 4.7 seconds.

Given how little information I have on the old website though my result is terrible.

the second scale that is bad is total blocking time, JavaScript is single-threaded, which means that any work being done will block the website. Blocking occurs when that task is longer than 50ms, anything less will not be perceived by a human.

The new blog looks like this.

New Website Home Page — The new website, still simple, but a bit more advanced.

I have updated the style as you can see. Instead of just showing the title and description, the new website also shows thumbnails of the posts. The first splash screen will load 9 images and information about the 9 latest blog posts.

Let us run Lighthouse on the new website and review the results

New Website Home Page — All 4 Digits Incremented

Now, it looks much better than the previous website. All four scores have improved. Performance is very high, even though we are now showing more data.

New website home page — provided metrics

We can see that the new website is fully interactive after 4.3 seconds. It is a decrease of (16.7–4.3) = 12.4s Faster than the old blog.

If you wonder why it is still taking 4.3 seconds, there is still some javascript that I have to run and import, such as Google Analytics and Adsense. These slow down a website significantly.

None the less, it would be a huge improvement for my readers!

Let’s be fair, my readers shouldn’t be staying on my home page, they should be staying inside the blog posts.

Let’s measure the same blog post on each website, and it’s interesting because there’s no difference here, both serve markup file.

Kubernetes posts on the old website.

We can run Lighthouse again but on this page instead.

kubernetes page result

Therefore, the old website is marked with yellow color so it is acceptable. I want to note the Extreme Time to Interactive of 28.7 seconds. Imagine coming to my blog and surviving 28 seconds before everything works.

The new website holds the same Markdown file, and displays almost identical information.

Kubernetes posts to new website

Let’s let Lighthouse consume it.

Kubernetes page on the new website

So everything looks a little better. The performance increased by 22 points, which is the highest considering the 100. If I remove analytics and other stuff I can get to 90 but I want it to be available so I can’t do that.

The interactive time is 3.6 seconds, which is (28.7-3.6) = 25.1 seconds faster!

A vast improvement when rebuilding with SvelteKit

Not only this my blog has become very fast now. It is very easy to maintain and update. In Jekyll, I had to find and test super many different plugins to optimize, and it was generally very hard to get up and running.

I have to say, I’ve done almost no customization to the new website, it’s almost only using out-of-the-box features. This speed gain is purely from using SvelteKit only.

And I got to say it sounds amazing, I’ve been struggling with so many plugins and different tools for my Jekyll site, and to no avail.

The only thing I’ve added extra is wight-plugin to automatically generate webp images for users during build. Something I already did in a Jekyll application. However it was 100 times easier to implement in SvelteKit. And I’ll be doing a blog post about it in the near future.

On the old website, I was very cautious and was afraid to change anything I did because it usually broke a lot of other things. Since SvelteKit has a very understandable and easy to understand structure for both the application and since the Svelte components are very easy to understand, the blog is now very easy to work with for me.

I was very confused when I decided to rebuild, many frameworks have offered “next generation”, but after trying out SvelteKit, it seems to be a next generation framework.

That said, I must clarify that SvelteKit is not yet officially released with version 1.0. the current version is still a release candidate Only.

But it could also mean we’ll see even more amazing stuff from SvelteKit before v1.0,

I’m very excited about this and I can’t wait to hear from you what you think of the new website.

Do you like it? try on

Leave a Reply