wordpress-seo
wordpress-seo copied to clipboard
Yoast
Add a filter to allow changing the priority of head tags
Context
- Performance is currently an area of significant focus within WordPress.
- Performance of websites can be significantly improved by optimally ordering items in the
<head>element. - See for example https://paper.dropbox.com/doc/Performance-Optimization-Strategy-in-2022-Addk8wccr1TuhKqzLW09b#:uid=776675799262198432449914&h2=1.-Cleaning-up-and-reordering-
- This PR adds a filter so that the priority of the head tags added by the Yoast SEO plugin can be changed from the default value of 1.
- See issue https://github.com/Yoast/wordpress-seo/issues/16421 for details.
Summary
This PR can be summarized in the following changelog entry:
- Added the wpseo_head_priority filter to allow changing the priority of items added to the head.
Relevant technical choices:
- Keep the default priority of 1 and allow it to be overridden by a filter, so there is no backwards compatibilty issue.
- Ideally the priority of the
<title>tag should be able to be set separately from the<meta>tags, but I'm not sure if this is possible, so this PR does not cover that.
Test instructions
The following code will set the priority to 999, so the items added will be at or near the end of the head element:
add_filter( 'wpseo_head_priority', 'my_wpseo_head_priority' );
function my_wpseo_head_priority( int $priority ): int {
$priority = 999;
return $priority;
}
Test instructions for QA when the code is in the RC
- [ ] QA should use the same steps as above.
QA can test this PR by following these steps:
Impact check
This PR affects the following parts of the plugin, which may require extra testing:
UI changes
- [ ] This PR changes the UI in the plugin. I have added the 'UI change' label to this PR.
Other environments
- [ ] This PR also affects Shopify. I have added a changelog entry starting with
[shopify-seo]and I have added test instructions for Shopify.
Documentation
- [ ] I have written documentation for this change.
Quality assurance
- [ ] I have tested this code to the best of my abilities
- [ ] I have added unittests to verify the code works as intended
- [ ] If any part of the code is behind a feature flag, my test instructions also cover cases where the feature flag is switched off.
- [ ] I have written this PR in accordance with my team's definition of done.
Fixes #16421
Thanks for this, @lumpysimon!
I'm intrigued; do you have some examples of where moving non-CSS/JS resources in the <head> makes a difference? I completely understand the rationale for ordering 'resources', but I've not seen any research or evidence that suggests that <meta> and similar cause any kind of blocking behaviour.
Conversely, I've definitely seen examples of problematic behaviour when elements like the <title> and logic which controls the viewport and charset are moved below CSS/JS.
Additionally, we still see people incorrectly adding tracking resources (pixels, tag managers, etc), in ways that break the head; and if critical meta tags are after that, then search engines can sometimes ignore them.
If we're going to explore this, I think I'd rather look for an approach that separates out the different levels. E.g., we can definitely 'demote' open graph tags, but the title should remain as high as possible. That would require some additional thinking!
Hi @jonoalderson - Thanks for responding so quickly. This is all new to me so the only examples I have are from Harry Roberts (who has done a lot of research around this), and the Smashing Magazine Web Performance 2022 online workshop I attended last week (where the above linked doc came from).
I completely agree that the title should be separated out from the meta tags so it can be left at the top of the head, but I couldn't see an easy/quick way to do this. Is that something you would be willing to look into?
Happy to think about it yeah, but honestly would want more input on the why of this first. I've pinged Harry Roberts on Twitter.
Hi,
Is there any more updates on this? It's certainly something I would be interested in seeing made available as well & can't see any downsides personally if it is made available as a filter.
The majority of people probably wouldn't care or use it, the ones that do want to utilise this for performance can...
Hi @phil-sola, I still think we'd need some logic to split out the various types/hierarchies of tag, as per my above comment. I'd definitely be interested in exploring a more sophisticated approach which:
- Defines those types (with some thought towards future-proofing & backwards-compatability)
- Considers the default priority of each of those types
- Defines + provides filters
Realistically, this isn't something we're going to be able to prioritize resourcing or developing in the short-term; but I'd love to discuss and explore. Maybe we can wrangle a community patch for it, or at the very least, define it well enough that I can write up an issue and get it somewhere on our future roadmap?
NB, I'm closing this issue in the meantime, but please feel free to continue the discussion!