Page MenuHomePhabricator

Mobile site should not use ResourceLoader from the desktop domain
Closed, ResolvedPublic

Description

http://www.webpagetest.org/result/150911_0Z_12P7/4/details/

Making sure that all RL requests go through the m subdomain is an easy (if small) performance win.

Event Timeline

Gilles created this task.Sep 15 2015, 1:04 PM
Gilles raised the priority of this task from to Medium.
Gilles updated the task description. (Show Details)
Gilles added a subscriber: Gilles.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 15 2015, 1:04 PM
Krenair renamed this task from ResourceLoader loads some JS from en.wikipedia.org instead of en.m.wikipedia.org on the mobile site to ResourceLoader loads some JS from the desktop site on the mobile site.Sep 15 2015, 4:07 PM
Krenair set Security to None.
Krenair added a subscriber: Krenair.

Is this a ResourceLoader issue or a Wikimedia configuration issue (Wikimedia-Site-requests)?

Is this a ResourceLoader issue or a Wikimedia configuration issue (Wikimedia-Site-requests)?

I suspect it will take as much effort to answer that question as it will to fix the underlying issue.

Krinkle renamed this task from ResourceLoader loads some JS from the desktop site on the mobile site to Mobile site should not use ResourceLoader from the desktop domain.Sep 15 2015, 5:27 PM
Krinkle claimed this task.

Several things:

  • en.m.wikipedia.org load.php startup module:
    • Most things either correctly use en.m.wikipedia.org or they use absolute paths without a server component (e.g. wgWMEStatsdBaseUri: "/beacon/statsv")
    • mw.loader.addSource({"local":"https://en.wikipedia.org/w/load.php"
    • "EmbedPlayer.WebPath": "https://en.wikipedia.org/static/ .. /TimedMediaHandler/ ..
    • "wgEventLoggingBaseUri": "//en.wikipedia.org/beacon/event"
  • "wgULSFontRepositoryBasePath":"//en.wikipedia.org/static/ .. /fonts/"
  • "wgNoticeHideUrls":["//en.wikipedia.org/wiki/Special:HideBanners", "//commons.wikimedia.org ..", ..]

The first one (addSource) is the cause of the load.php requests.

mediawiki/wmf-config:

$wgLoadScript = "{$wgCanonicalServer}/w/load.php";
...
$wgHooks['EnterMobileMode'][] = function() {
    ..
    $wgLoadScript = $mobileContext->getMobileUrl( $wgLoadScript );

I guess this only works on page views, which is why load.php urls in the html are constructed with the mobile domain. But anything loaded with it (mediawiki.js, jquery, and all page/user modules) go through the canonical domain as the startup module request seems unaware of the mobile context.

Change 238511 had a related patch set uploaded (by Krinkle):
Remove hardcoded $wgCanonicalServer from $wgResourceBasePath

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

Change 238511 merged by jenkins-bot:
Remove hardcoded $wgCanonicalServer from $wgResourceBasePath

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

Change 238537 had a related patch set uploaded (by Krinkle):
resourceloader: Don't call wfExpandUrl() on load.php urls

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

Change 238543 had a related patch set uploaded (by Krinkle):
Remove hardcoded $wgCanonicalServer from $wgResourceBasePath

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

Change 238544 had a related patch set uploaded (by Krinkle):
resourceloader: Don't call wfExpandUrl() on load.php urls

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

Change 238545 had a related patch set uploaded (by Krinkle):
resourceloader: Don't call wfExpandUrl() on load.php urls

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

Change 238543 merged by jenkins-bot:
Remove hardcoded $wgCanonicalServer from $wgResourceBasePath

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

Change 238537 merged by jenkins-bot:
resourceloader: Don't call wfExpandUrl() on load.php urls

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

Change 238545 merged by jenkins-bot:
resourceloader: Don't call wfExpandUrl() on load.php urls

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

Change 238544 merged by jenkins-bot:
resourceloader: Don't call wfExpandUrl() on load.php urls

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

Krinkle closed this task as Resolved.Sep 16 2015, 7:26 PM
Krinkle moved this task from Inbox to Doing on the Performance-Team board.