Is Hexo Really Slow in 2025? — A Comparison of Generation Speeds Across Versions

For a long time, Hexo has been criticized by some users for its slow generation speed. But is this really the case? Has Hexo’s performance improved with continuous version iterations? To investigate this, I conducted a series of performance tests, covering versions from Hexo 3.9.0 to the latest 8.0.0, and compared it with Hugo, which is known for its speed.

Test Description

The tests were divided into two scenarios:

• Cold Generate: hexo clean && hexo g, the first generation after clearing the cache, simulating scenarios like initialization or modifying theme configurations.
• Hot Generate: Running hexo g again on an existing build, utilizing the cache for incremental generation, corresponding to daily writing updates.

Hexo Version Performance Comparison

Sample Size: 500 ~ 4000 posts. The test articles are from hexojs/hexo-many-posts, with files duplicated to observe performance at different scales.

Test Environment

• Node: v24.8.0
• OS: Windows 11 Pro 23H2
• Theme: hexo-theme-landscape (Hexo and theme with default configurations)
• Dependencies: Apart from the main Hexo package, other Hexo-related dependencies were kept at the same versions across different version comparisons:

{
  "hexo-generator-archive": "^2.0.0",
  "hexo-generator-category": "^2.0.0",
  "hexo-generator-index": "^4.0.0",
  "hexo-generator-tag": "^2.0.0",
  "hexo-renderer-ejs": "^2.0.0",
  "hexo-renderer-marked": "^7.0.0",
  "hexo-renderer-stylus": "^3.0.1",
  "hexo-server": "^3.0.0",
  "hexo-tag-embed": "^1.0.0",
  "hexo-theme-landscape": "^1.0.0"
}

Cold Generate

A very clear optimization curve can be seen from the chart:

• 3.9.0 -> 4.2.1: A significant performance improvement, especially in the generation (Generate) phase. The main improvements include removing the cheerio dependency and improving the Cache of Rendered HTML mechanism. For details, see Speed is Key! — How We Made Hexo 4.2 30% Faster.
• 4.2.1 -> 6.3.0: The performance of these versions is very close, but they generally maintain a low time consumption without significant performance degradation.
• 6.3.0 -> 7.3.0: A noticeable leap. 7.3.0’s generation time is greatly reduced, with the curve becoming nearly flat and insensitive to scale growth. The main improvement comes from hexo#5145.
• 7.3.0 -> 8.0.0: 8.0.0 continues the performance of 7.3.0 with further optimizations in loading, making it the fastest currently. With 4000 posts, 8.0.0 takes ≈ 23s, while 3.9.0 takes ≈ 301s. The main improvement comes from introducing a binary relation index structure for category and tag lookups in hexo#5605.

Hot Generate

In hot generation, all versions are faster than cold generation (the cache is working), but differences still exist:

• 7.3.0 and 8.0.0 are the most stable. At a scale of 4000 posts, the time is still very low.
• 8.0.0 is also the fastest in hot generation, taking about 16s for 4000 posts.

Hexo Large-scale / Extreme-scale Tests

The tests above focus on the scale of a “typical personal blog” (up to 4,000 posts with a normal number of tags/categories). To see how Hexo behaves under more extreme conditions, I added two stress scenarios:

1. Increase post count to 10,000 (tags 100 / categories 13 unchanged)
2. Explode tag/category counts: Tags = 2,500, Categories = 500 (simulating a highly fragmented information structure)

Comparisons include:

• Core theme: landscape (closer to Hexo baseline)
• Real-world theme: hexo-theme-reimu (more features, extra components, frontend assets & render overhead)
• Framework versions: 7.3.0, 8.0.0 and 8.1.0
• Modes: Cold Generate (Cold) and Hot Generate (Hot)

10k Posts (Tags 100 / Categories 13)

landscape theme

reimu theme

High Tag / Category Count (Tags 2500 / Categories 500)

landscape theme

reimu theme

Memory Overview

Unit: minimum stable --max-old-space-size (MB; ≈ means roughly sufficient; > means anything below will OOM)

10k Posts (100 tags / 13 cats) Cold Generate

Version	landscape	reimu
7.3.0	>8192	>8192
8.0.0	≈4096	≈4096
8.1.0	≈4096	≈4096

High Tag/Category (2500 tags / 500 cats) Cold Generate

Scenario	7.3.0	8.0.0	8.1.0
2000 posts landscape	>8192	>4096	>4096
2000 posts reimu	>12288	>4096	>4096
5000 posts landscape	>12288	>8192	>8192
5000 posts reimu	>12288	>8192	>8192

Hexo vs. Hugo

For a more direct comparison, I compared a Hexo 8.0.0 site with hexo-theme-reimu and a Hugo site with hugo-theme-reimu at the same scale.

• The two themes are kept as functionally consistent as possible.
• On the Hugo side, shortcodes are used to replicate Hexo’s built-in tags to align functionality.
• The configurations of both themes are consistent.
• The two frameworks handle “archives” differently, which may cause slight time differences. The results are for reference only.

Explanation of the chart:

• meta_generator and external_link are two features enabled by default in Hexo themes. They are used to insert a meta generator tag in the page head and add rel="noopener" to external links, respectively. These two features have a certain impact on generation speed and have no corresponding function on the Hugo side, so they are listed separately for reference.
• hexo-renderer-marked (Hexo’s default) and hexo-renderer-markdown-it are two different Markdown renderers. The latter has better performance in some scenarios and is therefore also listed separately for reference.

Hugo is still faster. With 4000 posts, Hugo is about twice as fast as Hexo 8.0.0. The Go language foundation and parallel optimization provide strong throughput. However, Hexo 8’s performance is not bad. For example, with 4000 posts, a cold generation takes ~34s, and with various optimizations, it can even reach ~26s, which is completely acceptable for most personal sites.

Future Outlook: Will Hexo Get Faster?

To make another big leap in speed, “parallelism/multi-threading” is almost unavoidable. However, given Hexo’s current architecture, full parallelization is not easy: the core generation process has clear sequential dependencies and global state, and many plugins also run in the same context by default.

Possible directions:

• Multi-instance parallelism: Start multiple Hexo instances to generate in partitions or shards (e.g., sharding posts, splitting tags/categories/archives), and finally merge the output. The advantage is clear isolation; the difficulties lie in routing conflicts, resource locks, and artifact merging strategies.
• Local multi-threading within a single instance: Offload heavy, isolatable tasks (such as rendering/syntax highlighting/some data pre-computation) to worker threads, with the main thread only handling scheduling and aggregation. A balance needs to be found between cache and context isolation, and the cost of data serialization/transfer.

I personally made an attempt: using piscina to parallelize “code highlighting,” but it turned out to be slower. The reason is likely that the task granularity was too small, and the costs of thread creation and cross-thread communication offset the benefits. (It’s also possible my implementation wasn’t good enough.)

Therefore, it is unrealistic for Hexo to achieve an order-of-magnitude speedup through “full-link parallelism” in the short term. A more prudent route is to continuously optimize hot paths and implement local parallelism within controllable boundaries.

Conclusion

Conclusion: It used to be slow, but not anymore.

• For users of older versions (6.3.0 and earlier): If you have many posts, the upgrade to 8.0.0 will bring a very noticeable improvement.

• For new users: The speed of 8.0.0 is sufficient for the vast majority of personal blogs and small to medium-sized sites. The ecosystem and community remain its advantages.

• For extreme performance: For very large-scale projects that are sensitive to every second, Hugo would be a more suitable choice.

• If you feel that Hexo is still slow, the cause is often an unoptimized plugin/theme, or enabling very time-consuming configurations like relative_link and highlight.auto_detect. Prioritize investigating and upgrading the relevant dependencies, and if necessary, replace plugins or themes that have high implementation overhead.

Additional note: Even with 10k posts, 8.0.0 can keep a cold build within about one minute (normal tag scale). It only really turns ugly when tags/categories become overly fragmented (thousands), causing memory usage and relationship building to explode. If you are approaching that range, restructure the information architecture first instead of just adding hardware or raising the memory limit.

In short, performance is no longer a critical weakness for Hexo. The optimizations in 7.3.0/8.0.0 are substantial, and Hexo is striking a better balance between performance and its ecosystem.