Last modified: 2014-02-12 23:54:03 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T46017, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 44017 - Leverage browser cache for JS and CSS (separate requests for common and page-specific things)
Leverage browser cache for JS and CSS (separate requests for common and page-...
Status: RESOLVED FIXED
Product: MobileFrontend
Classification: Unclassified
stable (Other open bugs)
unspecified
All All
: Unprioritized normal
: ---
Assigned To: Jon
:
Depends on: 41340
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-15 23:40 UTC by Juliusz Gonera
Modified: 2014-02-12 23:54 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Juliusz Gonera 2013-01-15 23:40:58 UTC
Currently, both JS and CSS are concatenated on every page and downloaded in a single request (well, one for JS and one for CSS).

This has the following consequence: Our base JS and CSS (common for all the pages) is (re)requested on every page because the browser sees it as a different file and can't use cache.

To solve this we should serve common JS/CSS in one request and page-specific JS/CSS (e.g. watchlist stuff, edit action) in a separate request.
Comment 1 Jon 2013-02-13 06:24:45 UTC
Special pages and edit pages bypass the cache so not sure what this gains us.
Comment 2 Jon 2013-02-13 06:25:03 UTC
(Also with RL not sure if this is an issue any more)
Comment 3 Jon 2013-02-13 19:52:18 UTC
MaxSem: jdlrobson, I'm not sure 44017 is 100% resolved - I'd rather close it when we switched to OutputPage linking, which supports module groups
Comment 4 Juliusz Gonera 2013-02-26 01:59:23 UTC
Jon, this is about browser cache. Unless people disable cache in their browsers, special and edit pages use it.
Comment 5 Jon 2013-03-07 01:51:33 UTC
I had a go
https://gerrit.wikimedia.org/r/52577
Comment 6 Gerrit Notification Bot 2013-03-07 22:59:22 UTC
https://gerrit.wikimedia.org/r/52577 (Gerrit Change I688128038a2e9366a4dca4bdf52dcbfcc548c0e0) | Code-Review: Reviewed:+2 Verified:+2 Patch Set 1: Verified+2 Code-Review+2

Doesn't seem to explode in my testing... [by com.google.gerrit.server.events.AccountAttribute@7c73eaa8]
Comment 7 Gerrit Notification Bot 2013-03-07 22:59:24 UTC
https://gerrit.wikimedia.org/r/52577 (Gerrit Change I688128038a2e9366a4dca4bdf52dcbfcc548c0e0) | Patch Set 1: -Verified

Starting gate-and-submit jobs.
http://integration.mediawiki.org/zuul/status [by com.google.gerrit.server.events.AccountAttribute@2a4e2ecb]
Comment 9 Gerrit Notification Bot 2013-03-07 22:59:32 UTC
https://gerrit.wikimedia.org/r/52577 (Gerrit Change I688128038a2e9366a4dca4bdf52dcbfcc548c0e0) | change APPROVED and MERGED [by com.google.gerrit.server.events.AccountAttribute@775e9138]
Comment 11 Juliusz Gonera 2013-03-08 01:34:57 UTC
I think I haven't explained well enough what this bug is about.

Go to https://en.m.wikipedia.org/
There's only one <link> tag to styles:
https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=mobile.styles&only=styles&skin=mobile&*

Now go to Settings, there's again only one <link> tag, *but* it's different:
https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=mobile.styles%7Cmobile.mobileoptions.styles&only=styles&skin=mobile&*

What does this mean? Settings page loads additional styles, but it also certainly uses some of the styles from the main page. *But* instead of reusing the browser cache and using the CSS requested on the main page:

https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=mobile.styles&only=styles&skin=mobile&*

*and* adding its own styles in a *separate* <link> tag, it just issues a request that fetches everything together.

This way, we keep reloading (re-requesting) CSS that already is in browser cache instead of reusing it because every <link> tag issues a request for the *entire* CSS of MobileFrontend (+ sometimes page-specific CSS) on every page.
Comment 12 Jon 2013-03-08 15:30:01 UTC
Yes.. and this is what the above patch does..
If you try out master on a local machine you'll notice two link tags for css files.

On local copy of master I see these urls on Special:MobileOptions:

* http://localhost/w/load.php?debug=false&lang=en&modules=mobile.styles&only=styles&skin=mobile&*

* http://localhost/w/load.php?debug=false&lang=en&modules=mobile.mobileoptions.styles&only=styles&skin=mobile&*


On the main page I see (currently incorrectly 2 urls) but they are:
* http://localhost/w/load.php?debug=false&lang=en&modules=mobile.styles&only=styles&skin=mobile&*

* http://localhost/w/load.php?debug=false&lang=en&modules=&only=styles&skin=mobile&*

The latter is empty and shouldn't be added. That was an oversight on my part (as I've been refactoring css to make sure this is never empty - https://gerrit.wikimedia.org/r/52577 )

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links