Drupal 11.3 Removes Path Alias Preload Cache – What Developers Need to Know

With the release of Drupal 11.3, a long-standing optimization has been removed from core: the path alias preload cache. This mechanism, introduced in Drupal 6, has officially been deprecated and replaced with a more modern approach.

In this article, we'll explore why the preload cache was removed, what replaced it, and what—if anything—you need to change in your custom or contrib modules.

What Was the Path Alias Preload Cache?

Back in Drupal 6, Drupal implemented a cache that would collect all internal system paths used on a page and store their aliases for 24 hours. The goal was simple:

✅ Load all path aliases in one database query, instead of one query per alias lookup.

This was useful back when pages were assembled from scratch on every request.

Why It Became Obsolete

In modern Drupal (8, 9, 10, and now 11), render caching has significantly evolved.

Because of render cache warming:

• ✅ Once blocks and entities are cached, path aliases are barely looked up anymore.

• ✅ Even when they are — it’s usually just a few, not hundreds.

• ❌ The preload cache was often completely skipped or provided minimal benefit.

Therefore, maintaining this legacy mechanism provided no meaningful performance win — and so it was removed.

What Replaced It: PHP Fibers

While the old preload cache was removed from AliasManager, Drupal 11.3 introduced a new preload strategy powered by PHP Fibers.

How It Works

1. When a path alias is requested inside a Fiber, Drupal adds it to a preload list.

2. When the Fiber resumes execution, Drupal bulk-loads all pending alias requests in one query — including requests from other Fibers.

This new approach performs better than the old cache on cold builds, while staying out of the way on warm caches.

Impact on Module Developers

If your module integrated directly with the path alias cache, you can:

➡ Remove that logic once your module requires Drupal 11.3+ — it no longer does anything.

To take advantage of the new Fiber-based optimization:

✔️ Make sure your blocks and render arrays use #lazy_builder and placeholders, so they can run inside Fibers and contribute to grouped alias loading.

Example: Using #lazy_builder Properly

public function build() { 
  return [ 
    '#lazy_builder' => [ 
      'my_module.lazy_builder:getRenderedBlock', 
      [], 
    ], 
    '#create_placeholder' => TRUE, 
  ]; 
} 

This structure allows Drupal to defer the rendering inside a Fiber — enabling alias preloading to work efficiently.

Summary

Drupal continues evolving toward automatic performance optimization — and this change is a good example of old architecture being replaced with smarter, more dynamic mechanisms.