3 posts tagged with "Performance"

There is a fascinating conversation happening in the Drupal community right now: HTMX Now in Drupal Core. The proposal? To replace the venerable (but aging) jQuery-based Ajax API with a modern, lightweight, HTML-over-the-wire subsystem based on HTMX.

To understand the practical implications, I built a demo module comparing the two approaches side-by-side.

The Experiment​

I created drupal-htmx-ajax-replacement-demo, a module that renders two identical interactive cards. One uses the standard Drupal.ajax library, and the other uses HTMX.

1. Legacy Drupal Ajax​

The traditional way relies on jQuery and a custom JSON protocol.

The Flow:

1. Client clicks a link with .use-ajax.
2. Drupal.ajax intercepts the click.
3. Server builds an AjaxResponse with commands (e.g., ReplaceCommand).
4. Server returns JSON: [{"command": "insert", "method": "html", ...}].
5. Client Javascript parses JSON and executes DOM manipulation.

The Code:

public function timeAjax() {
  $response = new AjaxResponse();
  $response->addCommand(new HtmlCommand('#container', $html));
  return $response;
}

2. The HTMX Way​

HTMX allows us to be declarative. We define what we want in HTML attributes, and the server just returns HTML.

The Flow:

1. Client clicks <button hx-get="..." hx-target="...">.
2. HTMX intercepts.
3. Server returns standard HTML fragment.
4. HTMX swaps the HTML into the target.

The Code:

public function time() {
  return new Response($html);
}

Why This Matters​

The difference in complexity is striking.

• Javascript: The legacy approach requires the heavy core/drupal.ajax library (and jQuery). HTMX is lighter and requires no custom Javascript for this interaction.
• Backend: The HTMX controller returns a simple Response object with a string. The legacy controller requires instantiating AjaxResponse and learning the Command API.

You can view the full source code and the comparative implementation in the repository below.

View Code

View Code

WordPress 6.8 is set to introduce native support for the Speculation Rules API, a browser feature that allows sites to tell the browser which pages should be prefetched or prerendered before the user even clicks.

Caching is usually the answer to everything in Drupal performance, but there's a crossover point where the overhead of the cache itself—retrieval and unserialization—outweighs the cost of just doing the work.

Two issues caught my eye today that dig into these micro-optimizations: one challenging the assumption that we should always cache JSON:API normalizations, and another squeezing more speed out of the service container dumper.