Page MenuHomePhabricator

Investigate the use of DNS prefetching for reducing page load time.
Closed, ResolvedPublic

Description

Looking at http://people.wikimedia.org/~ori/enwiki-waterfall.png (from http://www.webpagetest.org/result/150316_0C_7MB/1/details/), we can see a login.wikimedia.org request that happens late and takes up 270ms. About 200ms of that seems to be the DNS lookup.

Modern browsers do DNS lookups in parallel while fetching the page content. They do this automatically for resources that are referenced from the content (e.g. it happens for bits & upload). However, login.wikimedia.org isn't referenced anywhere in the page itself, as checkLoggedIn gets called from Javascript, which means that this DNS lookup gets serialized and blocked on that CentralAuth script getting fetched and evaluated.

This could be easily be parallelized and shave off a few ms by adding this to head:
<link rel="dns-prefetch" href="//login.wikimedia.org">

@ori points out that meta.wikimedia.org could also be similarly prefetched, as it's used when running campaigns but not referenced anywhere in the original HTML.

There are possible other contenders that we should think of. Note that while major browsers perform link prefetching by default for link targets as well, it's disabled for privacy reasons when viewing a page over HTTPS, so we should explicitly prefetch cross-site links as well, within reason (i.e. not all Wikipedia language variants ;)).

Event Timeline

faidon created this task.Mar 16 2015, 5:48 PM
faidon updated the task description. (Show Details)
faidon raised the priority of this task from to Needs Triage.
faidon added subscribers: faidon, ori.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 16 2015, 5:48 PM
Aklapper triaged this task as Normal priority.Mar 17 2015, 12:53 PM
Krinkle added a subscriber: Krinkle.

CentralNotice added a dns-prefetch link for meta.wikimedia.org to the HTML in 2012 (7012f4e2b1d75; T42969).

CentralAuth could do this as well.

In general I would recommend we use preconnect rather than dns-prefetch, however. See https://www.w3.org/TR/resource-hints/ for details.

Project tags change:

  • Removing Performance tag since this is not a performance-type problem, but rather an enhancement task for improving performance.
  • Moving away from MediaWiki tag since MediaWiki core already has support for adding such a link to the HTML (and has no further use for it by default).
  • Adding CentralNotice and CentralAuth for login.wikimedia.org and meta.wikimedia.org respectively.
ori added a comment.Jun 6 2016, 6:16 PM

In general I would recommend we use preconnect rather than dns-prefetch, however. See https://www.w3.org/TR/resource-hints/ for details.

preconnect might not be the best choice because CentralAuth only connects to login.wikimedia.org at most once a day, using a value in localStorage to indicate when to check logged-in status again.

ori claimed this task.Jun 6 2016, 6:30 PM
ori moved this task from Inbox to Doing on the Performance-Team board.

Change 292985 had a related patch set uploaded (by Legoktm):
Prefetch $wgCentralAuthLoginWiki DNS

https://gerrit.wikimedia.org/r/292985

Change 292985 merged by jenkins-bot:
Prefetch $wgCentralAuthLoginWiki DNS

https://gerrit.wikimedia.org/r/292985

Change 293060 had a related patch set uploaded (by Ori.livneh):
Prefetch $wgCentralAuthLoginWiki DNS

https://gerrit.wikimedia.org/r/293060

Change 293060 merged by jenkins-bot:
Prefetch $wgCentralAuthLoginWiki DNS

https://gerrit.wikimedia.org/r/293060

Mentioned in SAL [2016-06-07T00:26:57Z] <ori@tin> Synchronized php-1.28.0-wmf.4/extensions/CentralAuth/includes/CentralAuthHooks.php: I79cbb1dc: Prefetch $wgCentralAuthLoginWiki DNS (T92864) (duration: 00m 29s)

Krinkle closed this task as Resolved.Jun 7 2016, 1:55 PM
ori added a comment.Jun 7 2016, 4:59 PM

We should make sure we dns-prefetch upload.wikimedia.org when lazy-loading images