Fetching latest commit…
Cannot retrieve the latest commit at this time
|Failed to load latest commit information.|
Proof of concept for the moment fiddling with an alternative sitenotice loading architecture. At the moment there's no backend logic or caching logic, I'm just testing the three-level loading. Wiki page HTML contains an unchanging bit that just sets JS variables about what site this is, then calls an external <script> to fetch site notice text. That second level can be a stable URL which can be heavily cached within squids *and* cleanly purged on sitewide updates. It itself is small, just calling out to a third <script>, this time with the site info (project and language) and a cache validation epoch / version marker in the query string. The third level is the bit that would provide the actual site notice text, and could be cached arbitrarily long in both squids and final user agents, since changed versions will get a new URL with a version number one level up. The theory here is that it should interact better with big-site caching. A user agent's first hit to the wiki will look something like: * Load wiki page HTML * Load Special:NoticeLoader JS * Load Special:NoticeText JS A hit to another page on the same wiki can skip the third hit: * Load new wiki page HTML * Load unchanged Special:NoticeLoader JS * skip cached Special:NoticeText JS Then if the site notice changes, the system only has to purge that constant Special:NoticeLoader URL from squids, and right away at the next hit the user agent sees: * Load new wiki page HTML * Load new Special:NoticeLoader JS * Load new Special:NoticeText JS We could spare hits on the notice loader by letting clients cache it for a shorter term as well, so a typical second hit looks nicely like: * Load new wiki page HTML * skip cached Special:NoticeLoader JS * skip cached Special:NoticeText JS This could delay visibility of changed site notices until the allowed age runs out, but if we manage *scheduled* site notices, we could send cache headers which will run out at the expected changeover time. It might be nice to allow for quick corrections though, so caching for weeks at a time might not be wise. ;) This experimental branch attempts to load the notice loader JS in an onload event handler instead of during initial page load, so the whole page won't get held up while waiting for the JS. Unfortunately, while it seems to work fine in Firefox, Opera, and even iCab, I had trouble in Internet Explorer and Safari. Safari 2.x and 3.x mysteriously fail to load the NoticeLoader JS when it's cached (with using maxage > 0), so you see the notice only on first load or after the maxage expires. IE 6 and 7 fail to load the loader JS at all, and further they explode when I try to load in FireBugLite to help debug it. Sigh. Safari 3.x (tested beta on Windows) also renders the page without the notice before loading it, causing visible UI jiggery-pokery even on a fast local network, which is mildly annoying. Safari and IE 6 also don't grok the <style> when done this way, so I redid it to pull the style separately via a proper <link>, which would have to be separately maintained and cache-cleared. This test branch has some FireBug console calls in the JS for testing.