[Astro] Why I Migrated from Jekyll to Astro

Overview

This blog has been running on Jekyll since 2018. Jekyll is a Ruby-based static site generator widely used by developer blogs, thanks to its seamless integration with GitHub Pages.

However, as the number of posts grew and plugins increased, the build speed became dramatically slower. Eventually, I decided to fully migrate to Astro in February 2026.

In this post, I share why I moved from Jekyll to Astro — the background and the reasons behind this decision.

Limitations of Jekyll

Build Speed Issues

The biggest problem running a blog with Jekyll was the build speed. As posts grew and I added multilingual support (Japanese/Korean/English) along with various plugins, the build time increased drastically.

bundle exec jekyll serve

When checking posts locally with this command, I had to wait 209 seconds (about 3 minutes and 30 seconds). In a previous blog post (Speeding Up Blog Preview), I managed to reduce it to 50 seconds by using the limit_posts setting and disabling the minify plugin, but it wasn’t a fundamental solution.

# _config-dev.yml
limit_posts: 3
jekyll-minifier:
  remove_spaces_inside_tags: false
  remove_multi_spaces: false
  remove_comments: false
  compress_css: false
  compress_javascript: false
  compress_json: false

Even with these settings, it still took 50 seconds, and I had to wait that long every time I modified a post.

Difficulty Managing Ruby Dependencies

Since Jekyll is Ruby-based, you need to manage Ruby version management, Bundler, Gem dependencies, and more. As a frontend developer, maintaining a separate environment from the Node.js/npm ecosystem I use daily was cumbersome.

Limitations of Liquid Templates

Jekyll’s Liquid template engine is sufficient for simple blogs, but it becomes limiting when complex logic or component reuse is needed. In particular, implementing multilingual support, dynamic meta tags, and structured data (JSON-LD) tended to result in overly complex code.

Evaluating Alternatives

After deciding to move away from Jekyll, I evaluated several static site generators.

Hugo

• Pros: Very fast build speed based on Go
• Cons: Go template syntax is not intuitive, limited integration with the frontend ecosystem

Gatsby

• Pros: React-based, rich plugin ecosystem
• Cons: Requires learning GraphQL, build time grows proportionally with project size, declining ecosystem activity

Next.js

• Pros: React-based, server-side rendering (SSR) support, active ecosystem
• Cons: Overkill for a blog, complex configuration for static sites, unnecessary JavaScript bundles

Astro

• Pros: Zero JS by default, fast dev server powered by Vite, Content Collections, markdown-first, supports multiple framework integrations
• Cons: Relatively new framework (but with an active community)

Why I Chose Astro

After evaluating all the alternatives, I determined that Astro was the best fit for this blog’s requirements.

1. Zero JavaScript by Default

Astro sends no JavaScript to the client by default. Since a blog is mostly static content, it’s ideal to load quickly with pure HTML/CSS without unnecessary JavaScript bundles.

2. Fast Dev Server Powered by Vite

The dev server built on Vite supports HMR (Hot Module Replacement), so changes to files are instantly reflected in the browser. Compared to waiting 50–209 seconds with Jekyll, this is a revolutionary improvement.

3. Content Collections

When writing blog posts, you include meta information (frontmatter) like title, description, and date at the top of each markdown file. With Jekyll, even if this information had typos or missing required fields, the build would proceed without errors — and you’d only discover problems after deployment.

Astro’s Content Collections solves this problem. By defining the type (string, date, boolean, etc.) and whether each field is required in advance, it automatically validates during build time and reports errors if there’s any incorrect data. It uses a TypeScript validation library called Zod to define these validation rules.

For example, you can define that “a blog post must have title (string), lang (one of ja/ko/en), date (date), etc.” as follows:

const blog = defineCollection({
  loader: glob({ pattern: '**/*.md', base: './src/content' }),
  schema: z.object({
    title: z.string(),           // required, string
    description: z.string(),     // required, string
    lang: z.enum(['ja', 'ko', 'en']), // required, one of 3
    category: z.string(),        // required, string
    permalink: z.string(),       // required, string
    date: z.coerce.date(),       // required, date
    // ...
  }),
});

If you forget to include title in a markdown file, or enter an incorrect value like 'kr' for lang, the build will fail and tell you exactly which file and which field is wrong. This allows you to catch mistakes before deployment.

4. Markdown-First Workflow

I was able to use the existing Jekyll blog’s markdown files almost as-is. The ability to finely customize markdown processing through rehype/remark plugins is also a significant advantage.

5. Node.js Ecosystem

Since all dependencies are managed with npm, there’s no need to separately manage Ruby/Bundler. You can run your blog in an environment familiar to frontend developers.

Migration Results

Build Time Comparison

Let’s start with the build speed, which was the primary motivation for the migration.

The full build time went from 209 seconds to 30 seconds — about 7 times faster. But the most noticeable change in practice is the dev server. With Jekyll, I had to wait at least 50 seconds to verify a single edit, but with Astro, changes appear in the browser the moment I save. Not having my writing flow interrupted is the most satisfying part.

Key Improvements

Beyond build speed, many other aspects improved after migrating to Astro.

• Build Speed: As shown above, both full builds and the dev server became dramatically faster.
• Developer Experience: Thanks to Vite-based HMR, the browser updates instantly when you modify code. In most cases, you don’t even need to refresh.
• Type Safety: With Content Collections and Zod schema validation, if there are typos in frontmatter or required fields are missing, you get an error immediately at the build stage. No more discovering problems after deployment.
• Image Optimization: A custom plugin using Sharp automatically converts images to AVIF/WebP formats. Optimized images are generated during build without any manual work.
• Search: By adopting Pagefind, fast full-text search became possible without a server. With Jekyll, I was using a slow JSON file-based search.
• Code Highlighting: Server-side code highlighting with Shiki provides VS Code-level accurate syntax highlighting without requiring separate CSS files.

Github Sponsor Buy me a coffee

Was my blog helpful? Please leave a comment at the bottom. it will be a great help to me!

App promotion

You can use the applications that are created by this blog writer Deku.
Deku created the applications with Flutter.

If you have interested, please try to download them for free.

word learning app for kids

BlaBoo

Korean TOPIK vocabulary app

TOPIK words

Japanese vocabulary app

Japanese words

Chinese HSK vocabulary app

HSK words