[wp-trac] [WordPress Trac] #64066: Speculative Loading: Change default eagerness from conservative to moderate when caching is detected

[WordPress Trac]

#64066: Speculative Loading: Change default eagerness from conservative to moderate
when caching is detected
-------------------------------------+-------------------------------------
 Reporter:  westonruter              |       Owner:  westonruter
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  Future Release
Component:  General                  |     Version:  6.8
 Severity:  normal                   |  Resolution:
 Keywords:  2nd-opinion has-patch    |     Focuses:  performance,
  early has-unit-tests               |  sustainability
-------------------------------------+-------------------------------------

Comment (by westonruter):

 Some key Shopify data that @gilbertococchi shared:
 [https://performance.shopify.com/blogs/blog/faster-storefront-navigations-
 with-moderate-speculation-rules Faster storefront navigations with
 moderate speculation rules]

 > The desktop result is the one that stands out. Across the curve, the
 median gain is -285ms TTFB, -224ms FCP, and -228ms LCP. Median TTFB for a
 speculated navigation is now close to zero, which means the HTML response
 often arrives before the buyer even commits to clicking. For roughly 10%
 of speculated navigations, TTFB is exactly 0: the response is already
 sitting in the cache when the navigation fires.

 Gains for mobile are less, as expected, due to the lack of a link hover
 heuristic.

 As for the increase in pages served due unused speculations:

 > Prefetching earlier means the browser occasionally fetches a page the
 buyer never ends up visiting. At the same volume of actual page views,
 moderate triggers nearly 4x as many speculated requests as conservative on
 desktop, while on mobile the volume barely moves. In our case, that
 translated to about a 14% increase in the total number of HTML requests.
 Those numbers will depend on multiple factors: share of same-site
 navigations and browser mix, to name a few. The desktop-versus-mobile gap
 is also wide enough to raise a question: should the API let authors set a
 different eagerness per device type?
 >
 > For us, the tradeoff is acceptable from both infrastructure and user
 perspectives. Still, your mileage may vary.

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