[wp-trac] [WordPress Trac] #64178: Increased styles_inline_size_limit pushes down oEmbed discovery tags

[WordPress Trac]

#64178: Increased styles_inline_size_limit pushes down oEmbed discovery tags
--------------------------+--------------------------
 Reporter:  swissspidy    |       Owner:  westonruter
     Type:  defect (bug)  |      Status:  accepted
 Priority:  normal        |   Milestone:  6.9
Component:  Embeds        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  performance
--------------------------+--------------------------

Comment (by westonruter):

 I have a solution I like for changing the priority:
 https://github.com/WordPress/wordpress-develop/pull/10449

 However, I think it may make sense to back off of increasing the
 `styles_inline_size_limit` as well. Instead of bumping from 20K to 50K,
 perhaps it would make more sense to meet in the middle at 35K or 40K.

 Note the graphs showing the LCP-TTFB for Fast 4G
 ([https://github.com/GoogleChromeLabs/wpp-
 research/pull/201#issuecomment-3447997500 raw data]) and broadband
 ([https://github.com/GoogleChromeLabs/wpp-
 research/pull/201#issuecomment-3448044083 raw data]) from #63018. In the
 two graphs, the uncached curve starts to flatten out at 40K:

 [[Image(https://core.trac.wordpress.org/raw-attachment/ticket/63018
 /increasing-css-inline-size-limit.png)]]

 [[Image(https://core.trac.wordpress.org/raw-attachment/ticket/63018
 /increasing-css-inline-size-limit-broadband.png)]]

 Reducing the inline limit wouldn't solve the problem for the
 [https://make.wordpress.org/core/2021/10/12/proposal-for-a-performance-
 team/ page in question], however, since the oEmbed discover links appear
 at byte 178,831. So reducing reducing 10K-15K of inline CSS would still
 leave them above the 150K threshold for discovery.

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