After maintaining a Next.js-based portfolio website for several years, I recently migrated to Jekyll. This post details the technical reasoning behind this decision and the implementation process.

Why Jekyll Over Next.js

Build Complexity Reduction

Next.js introduced unnecessary complexity for a portfolio site. The build process required Node.js runtime, webpack bundling, and client-side JavaScript execution. Jekyll generates static HTML files during build time, eliminating runtime dependencies.

Performance Optimization

Static sites outperform dynamic frameworks in Core Web Vitals. Jekyll generates pre-built HTML, CSS, and JavaScript files that serve directly from CDN without server-side processing. This results in sub-100ms Time to First Byte (TTFB) and eliminates JavaScript bundle parsing delays.

Deployment Simplification

Next.js deployment requires Node.js servers, environment variables, and build optimization. Jekyll sites deploy to any static hosting service (GitHub Pages, Netlify, Vercel) with zero runtime configuration. The build process generates optimized assets that serve directly without server-side rendering overhead.

Technical Implementation

Build Process Architecture

Jekyll uses Ruby-based static site generation with Liquid templating. The build pipeline processes Markdown files through layout templates, generating optimized HTML output. This eliminates the need for client-side routing and JavaScript hydration.

# _config.yml configuration
markdown: kramdown
highlighter: rouge
permalink: /blog/:year/:month/:day/:title/
plugins:
  - jekyll-feed
  - jekyll-sitemap
  - jekyll-seo-tag

Asset Optimization

Static assets undergo build-time optimization. CSS and JavaScript files are processed through Jekyll’s asset pipeline, enabling concatenation and minification. Images are optimized during build, reducing runtime processing overhead.

SEO Implementation

Jekyll provides superior SEO capabilities through front matter metadata and plugin integration. The jekyll-seo-tag plugin automatically generates Open Graph tags, Twitter cards, and structured data without client-side JavaScript execution.

Performance Metrics

Build Time Comparison

  • Next.js: 45-60 seconds (webpack bundling, code splitting, optimization)
  • Jekyll: 8-12 seconds (Markdown processing, template rendering, asset generation)

Runtime Performance

  • Next.js: 2.1MB JavaScript bundle, 450ms First Contentful Paint
  • Jekyll: 0KB JavaScript (core functionality), 180ms First Contentful Paint

Lighthouse Scores

Jekyll achieved 98/100 Performance, 100/100 Accessibility, 100/100 Best Practices, and 100/100 SEO. Next.js scored 89/100 Performance due to JavaScript execution overhead.

Migration Challenges

Dynamic Functionality

Portfolio sites require minimal dynamic behavior. Jekyll handles contact forms through form services (Formspree, Netlify Forms) without server-side processing. Search functionality uses client-side JavaScript libraries with pre-built indexes.

Content Management

Jekyll’s front matter system provides structured content management. Markdown files with YAML headers replace dynamic database queries. This approach simplifies content updates and eliminates API dependencies.

Deployment Architecture

GitHub Pages Integration

Jekyll integrates seamlessly with GitHub Pages through automated builds. Push commits trigger automatic site regeneration and deployment. This eliminates manual build processes and reduces deployment complexity.

CDN Performance

Static files serve directly from CDN edge locations. No server-side processing means consistent performance across global regions. Content delivery optimization improves user experience for international visitors.

Maintenance Considerations

Dependency Management

Jekyll uses Ruby gems for plugin management. The Gemfile system provides version control and dependency resolution. This approach reduces security vulnerabilities compared to npm package management.

Update Process

Jekyll updates require Ruby gem updates and potential configuration adjustments. However, the static nature means updates don’t affect runtime performance or introduce breaking changes to existing functionality.

Conclusion

The migration from Next.js to Jekyll resulted in significant performance improvements and operational simplification. For portfolio websites with minimal dynamic requirements, Jekyll provides superior performance, simpler deployment, and reduced maintenance overhead.

The static site approach eliminates JavaScript execution delays, reduces build complexity, and improves Core Web Vitals scores. While Next.js excels for complex web applications, Jekyll offers optimal performance for content-focused portfolio sites.

This migration demonstrates that choosing the right tool for specific use cases often leads to better performance and simpler architecture than using feature-rich frameworks for simple requirements.