Leon . Kang
Back to articles
Performance β€’ 2/3/2026 β€’ 8 min read

Blog Loading & Rendering Strategy: A Selective Split Approach

Why Split?

Even though this blog is just my personal record site, I still want it to be "clean, light, and stable." Specifically:

  • Minimize unnecessary initial-load resources.
  • Keep the reading experience as smooth as possible.
  • Delay "non-essential" features like code highlighting and Table of Contents (TOC).

Loading Strategy: Lightweight First

1) Route-level Lazy Loading

BlogList / BlogDetail are split using React.lazy.
Blog-related code is only loaded when the user actually enters the blog section.

2) Data Layer: Metadata-only Lists

The list page only requires metadata such as title, excerpt, category, and publish date.
The article body is only fetched upon entering the detail page.

I also added caching in the loader to avoid repeated Markdown parsing.

3) Selective Loading on Detail Pages

The detail page first renders the structure and article header, while the body content (Markdown renderer) is loaded asynchronously:

  • react-markdown/remark/rehype are lazy-loaded.
  • react-syntax-highlighter only loads if code blocks are present.
  • TOC extraction (extractTOC) is also moved into a dynamic import.

This way, main content arrives faster, while heavy resources are deferred.

Rendering Strategy: Light Render, Heavy Impact

Markdown Rendering

  • Content is rendered by ReactMarkdown.
  • remark-gfm supports tables and task lists.
  • rehype-slug generates heading anchors for easier TOC navigation.

Code Blocks

Code block rendering triggers the highlighter component to load.
If the highlighter isn't ready, a basic pre style is provided first so readers don't wait.

Images

Images are handled by a unified component with lazy/async as default, ensuring they don't block main text rendering.

It's Not Just About "Speed," It's About "Control"

I'm not chasing extreme performance scores, but I want:

  • Controllable initial load.
  • A clear rendering path.
  • No sudden slowdowns in user experience.

Thus, this optimization is more about "order" than simple compression.

Summary

The core of this strategy is simple:
If it can wait, let it wait; if it can be on-demand, make it on-demand.

It's a perfect fit for personal sites and aligns with my preferences.