Drastically reduce action callback calls per page

Currently 'bricks/dynamic_data/render_tag' filter runs for every tag rendered, resulting in the callback for every registered tag effectively being called, potentially hundreds of times per page load.

For built-in tags this is less an issue, but I think even those could benefit by premapping callback lookups. More on that below at the bottom if your interested.

Something like this would reduce needless function calls massively on a large page build.

Example, Say you have 20 custom tags & callbacks (multiple Bricks addons etc), every tag rendered on a page ends up with a 20x function call multiplier.

A simple page with 10-20 dynamic tags now makes 300-400+ useless function calls.

Proposal: Single new filter, bypassing irrelevant callbacks

Create a single new filter containing the tag name in the hookname string, for example:
bricks/dynamic_data/render_tag/post_title.

Migrate existing tags such as {post_title} to only hook this new hook, clearing them from ever being called for any other tags.

No side effects, won’t break any existing integrations, but heavily optimizes the number of function calls per page.

		$content = apply_filters( "bricks/dynamic_data/render_tag/$tag", null, $post, $context );

		if ( null !== $content ) {
			return $content;
		}

		return apply_filters( 'bricks/dynamic_data/render_tag', $tag, $post, $context );

Suggested changes to core rendering

It might also be worth reworking the current internal implementation of tag rendering. At current every render_tag call results in a full lookup against the index of all tags, getting a provider, then a callback and running it.

You can instead rework your providers & registrations to simply hook every tags callback directly to the appropriate "bricks/dynamic_data/render_tag/$tag" filter and call it a day.

Note: It should be noted the current usage of qpply_filters there is not quite as intended, passing $tag and expecting $content back means your really wanting a singular callback, not filtering through lots of them.

Happy to suggest both better way to do it and help with ensuring backward compatibility, something I have A LOT of experience with from our own plugins.

11 Likes

I just noticed this notation in the docs for dynamic tag registraion, it could be avoided with this as well:

It is crucial to exercise extra caution while working on this aspect, as any mishandling may disrupt the dynamic tag functionality across the entire website.

Enforcing these changes in core makes core data impervious to this failure.

And updating the docs for how dynamic tags should be registered via the hook incluidng their name ensures this isn’t a real issue.

3 Likes

Any thoughts from the team on this idea?