#6769 closed enhancement (fixed)
Plugin pages should prewarm s.w.org
Reported by: | jonoaldersonwp | Owned by: | dd32 |
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | Plugin Directory | Keywords: | seo performance |
Cc: |
Description (last modified by )
Plugin pages like https://id.wordpress.org/plugins/tiny-compress-images/ are often slow to load.
As an easy win, we can pre-warm the connection to s.w.org and ps.w.org, which host various resources for the page.
To do this, we should add the following meta tags:
<link rel="dns-prefetch" href="https://s.w.org"> <link rel="preconnect" href="https://s.w.org"> <link rel="dns-prefetch" href="https://ps.w.org"> <link rel="preconnect" href="https://ps.w.org">
Change History (6)
#3
@
22 months ago
Browsers which don't support preconnect
will fall back to dns-prefetch
gracefully when both are included, and preconnect
'includes' dns-prefetch
. So having both is good practices.
I'd be nervous about doing this globally, as there's a cost to (either) hint if/when it's not used.
We should do this regardless of caching, as the browser still needs to do the HTTPS handshake, etc, and getting that started sooner saves a bunch of time.
#4
@
22 months ago
I'd be nervous about doing this globally, as there's a cost to (either) hint if/when it's not used.
*If there are other places these are hit, then I'd love to do it there, too. I'd just started with these locations as easy wins.
Is both
preconnect
anddns-prefetch
required? Doesn'tpreconnect
inferdns-prefetch
?Any change related to
s.w.org
should probably be done globally, not specifically for the plugin directory. Especially if we were to put the CDN to proper use; https://github.com/WordPress/wporg-mu-plugins/pull/173We probably don't want to add a preconnect to
s.w.org
either, as the majority of resources served from there are expected to be cached.A dns-prefetch for
ps.w.org
seems sane, but again,preconnect
feels like it might be a bit too aggressive.