[wp-trac] [WordPress Trac] #58775: Remove usage of outputting styles tags

[WordPress Trac]

#58775: Remove usage of outputting styles tags
--------------------------------+---------------------------
 Reporter:  spacedmonkey        |       Owner:  spacedmonkey
     Type:  enhancement         |      Status:  reopened
 Priority:  normal              |   Milestone:  6.4
Component:  Script Loader       |     Version:
 Severity:  normal              |  Resolution:
 Keywords:  2nd-opinion revert  |     Focuses:
--------------------------------+---------------------------
Changes (by spacedmonkey):

 * focuses:  performance =>


Comment:

 I am removing the performance focus here, as that is unclear.

 > @spacedmonkey In the future could you please use Trac references? Makes
 it a lot easier to follow.

 What do you mean here? What should I have referenced?

 > Using the WP_Styles API does not improve handling of these styles in the
 slightest. Please add examples!

 See attached screenshot, of how I can now see if the emoji inline style is
 output or not. I can now use the emoji style as a dependency. You can now,
 write a plugin to collect all inline styles and minify the css ( something
 you would have to do on a case by case basis ).

 > As pointed numerous times it is a bad idea for extenders to remove
 default WP styles.

 Is it a bad idea? Why? I don't think we get to make judgements on what
 developers do and it is is bad. The emoji styles can be a performance
 issue and are removed by a number of plugins.

 For example `print_emoji_styles` is unhooked by a number of popular
 [https://www.wpdirectory.net/search/01HB88CSFDDBV77CG3DZMCNVAF plugins],
 including Yoast SEO, W3 Total Cache, SiteGround Optimizer and WP-Optimize.
 All of which have over 1 million installs each. Saying no one unhooks
 these or it is a bad idea, I feel like is incorrect. Lots of people are
 doing it. Making it easier to do so makes sense.


 As for it being slower, the data does not prove this. Here is the commit
 and the before benchmark data. Between the 1000 runs I did on a 2020 site,
 there is basically no difference. The 0.18ms can be seen as variant
 between different runs of the tool.

 || || [56681] || [56682] ||
 || Response Time (median)|| 104.01 || 104.18 ||
 || wp-load-alloptions-query (median)|| 0.7|| 0.7 ||
 || wp-before-template (median)|| 21.48|| 21.34 ||
 || wp-template (median)|| 76.89|| 76.68 ||
 || wp-total (median)|| 98.9 || 98.56 ||

 One thing I don't understand here, is the Style API is used throughout
 core. It is good enough to use in all these places, why not here? If the
 style api is slow and should not be used in this context, then should it
 be removed everywhere?

 At the end of the day, core should be dogfooding it's own APIs, like the
 style api and encouraging all developers to do the same.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58775#comment:33>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform