wordpress-seo icon indicating copy to clipboard operation
wordpress-seo copied to clipboard

Published 20 hours ago • verified publisher icon Yoast

Add a filter to allow changing the priority of head tags

Open lumpysimon opened this issue 3 years ago • 4 comments

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

lumpysimon avatar Mar 22 '22 12:03 lumpysimon

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!

jonoalderson avatar Mar 22 '22 14:03 jonoalderson

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?

lumpysimon avatar Mar 22 '22 14:03 lumpysimon

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.

jdevalk avatar Mar 22 '22 14:03 jdevalk

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...

phil-sola avatar Aug 09 '22 07:08 phil-sola

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:

  1. Defines those types (with some thought towards future-proofing & backwards-compatability)
  2. Considers the default priority of each of those types
  3. 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?

jonoalderson avatar Aug 30 '22 10:08 jonoalderson

NB, I'm closing this issue in the meantime, but please feel free to continue the discussion!

jonoalderson avatar Aug 30 '22 10:08 jonoalderson