[wp-trac] [WordPress Trac] #63018: Increase styles_inline_size_limit from 20, 000 bytes

[WordPress Trac]

#63018: Increase styles_inline_size_limit from 20,000 bytes
------------------------------+--------------------
 Reporter:  westonruter       |      Owner:  (none)
     Type:  enhancement       |     Status:  new
 Priority:  normal            |  Milestone:  6.9
Component:  Script Loader     |    Version:  5.8
 Severity:  normal            |   Keywords:
  Focuses:  css, performance  |
------------------------------+--------------------
 As shown in #63007, being able to eliminate external stylesheets in favor
 of inline styles can have a dramatic improvement to page load time.
 External stylesheets are render-blocking in the `HEAD` and the Largest
 Contentful Paint (LCP) metric for textual elements often shows up having a
 render delay which corresponds to the time it takes to load external
 stylesheets. Eliminating render blocking stylesheets can cut LCP in half,
 from poor to good.

 We need to analyze the performance tradeoff between inlining a larger
 amount of CSS to reduce render blocking versus having this CSS already
 loaded in cache for subsequent page views. In other words, how much of a
 performance regression will there be for subsequent page views where the
 browser cache has been primed when all CSS is external?

 This is all a follow-up to what was
 [https://core.trac.wordpress.org/ticket/58519#comment:2 raised] by
 @sabernhardt in #58519:

 > We would need metrics for loading the first page plus an identical
 page—after the browser saves the external stylesheet(s)—to compare against
 the same pages with inlined stylesheets.
 >
 > These styles are not minified, so the proposed inlining would print
 hundreds of lines on every page of the site. I thought the 162 lines for
 Twenty Seventeen's SVG icons was a lot, but inlining both the `blocks` and
 `colors-dark` would add more than 1,000 lines in that theme. I also do not
 like the extra page weight when browsers currently cache that for the next
 page view, though I can be convinced this would improve it overall.

 And [https://core.trac.wordpress.org/ticket/63007#comment:8 furthermore]
 in #63007 and :

 > I also requested a performance metrics comparison for loading a
 //second// page (in addition the first) because browsers would already
 have the external file cached.

 Note that the impact to an increase to the size of the HTML in the second
 page load will be lessened by the prefetch introduced by Speculative
 Loading in #62503.

 Related to this:

 * #63012: Bundled themes: Stylesheets should be minified
 * #58519: Inline styles block styles in bundled themes
 * #63007: Bundled themes: Stylesheets for block themes are missing path
 data for inlining
 * #43258: Output buffer template rendering and add filter for post-
 processing (e.g. caching, optimization)

 Classic themes generally have to enqueue a lot more styles than they
 actually need because at `wp_head` they don't know which are actually
 going to be used on the page. So with the output buffering in #43258,
 classic themes could opt-in to `should_load_separate_core_block_assets` by
 default, where individual block styles rendered in the footer can be moved
 to the `HEAD` when processing the output buffer. See also
 [https://github.com/WordPress/performance/issues/1834 performance#1834]
 where this could be experimented on as a Performance Lab plugin.

 The first step here is to do the benchmarking. Based on the findings, this
 ticket can either be closed or moved forward to introducing a patch. The
 benchmarking should find the ideal number of bytes to inline versus to
 remain external (in cache).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63018>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform