Page MenuHomePhabricator

Leverage browser cache for JS and CSS (separate requests for common and page-specific things)
Closed, ResolvedPublic


Author: jgonera

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.

Version: unspecified
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 1:18 AM
bzimport set Reference to bz44017.

Special pages and edit pages bypass the cache so not sure what this gains us.

(Also with RL not sure if this is an issue any more)

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

jgonera wrote:

Jon, this is about browser cache. Unless people disable cache in their browsers, special and edit pages use it. (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] (Gerrit Change I688128038a2e9366a4dca4bdf52dcbfcc548c0e0) | Patch Set 1: -Verified

Starting gate-and-submit jobs. [by] (Gerrit Change I688128038a2e9366a4dca4bdf52dcbfcc548c0e0) | change APPROVED and MERGED [by]

jgonera wrote:

I think I haven't explained well enough what this bug is about.

Go to
There's only one <link> tag to styles:*

Now go to Settings, there's again only one <link> tag, *but* it's different:*

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:*

*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.

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:

On the main page I see (currently incorrectly 2 urls) but they are:

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 - )