Topic on Talk:Requests for comment/CentralNotice Caching Overhaul - Frontend Proxy

"Static Javascript Controller"

5
Parent5446 (talkcontribs)

Please no. We want to move *away* from having inline Javascript. Adding more is not a good idea. If it's static like the proposal says, just have it in an external Javascript file and include it that way. As long as it's not inline.

Mwalker (WMF) (talkcontribs)

I agree in principle; it's not something I introduce lightly. However, having to call down a JS file first would introduce a round trip and delay, something I'm explicitly avoiding (otherwise I could just hack RL to have it be the first delivered module and be done with it.)

In theory the static JS file could be client side cached and thus remove the RTT from the picture; however... comScore's numbers on the site indicate that the 50th percentile user visits the site only every 17 days indicating that we would have to have a cache timeout on the local file of at least that if not 30 days -- at which point it's on par with page expiry.

.. because ..

Fundraising gets most of our donations from the first impression. We don't know if the time to display factors in for banners; but for landing pages milliseconds matter on if a user will decide to donate.

Based on these things; it still seems the most sane to put it directly in the page.

Parent5446 (talkcontribs)

The only issue is that such a script will be broken when Content Security Policy is finally implemented in core.

Mwalker (WMF) (talkcontribs)

That's a fair point. I talked with Chris on Friday about this and he thinks that the timeline for CSP deploy is greater than nine months. I'll have to check with Mark; but I'm guessing we'll have Varnish deployed to the text cluster before then.

Sharihareswara (WMF) (talkcontribs)
Reply to ""Static Javascript Controller""