https://bugzilla.wikimedia.org/show_bug.cgi?id=27620
--- Comment #5 from Nux <[email protected]> 2011-02-24 21:06:34 UTC --- (In reply to comment #2) > The slowness of BannerLoader is because the script has to lookup your location > based on your IP address before it decides which banner to serve (and it > doesn't even start this until the page is finished loading). We may want to > change this so that your location is stored in a cookie instead. That may be one way but you could also check this for all users based on there most common IP and decide for them. Then you could write it to preferences after a user would confirm that this is his location (something similar is happening in Youtube). That way all this geolocalization and banner stuff could run once and be done for. Users could change their localization/country in preferences (near the language) and they could choose it after registering. > Regardless, CentralNotice/BannerLoader is probably the only JavaScript > component that didn't change with the new 1.17 deployment (since it was > already > loading everything on document.ready to start with). So it's very unlikely the > BannerLoader is responsible for any recent changes in toolbar loading. I'm guessing loading sequence changed with RL, so that might be a bit more of a pain now. Or maybe caching is still a bit unstable. BTW could you load banner script only if banners are not disabled? Something like: if (document.cookie.indexOf('hidesnmessage=1')==-1) mw.loader.load(wgServer + wgScriptPath + '?title=Special:BannerController&cache=/cn.js') It's pointless to load it if it is not going to be used and it might help in page loading speed. Same might apply for the geo stuff... -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
