#423 - Performance improvements: frontend technologies
-
By Chris Graham
- Added
- 6 views
| Identifier | #423 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Performance improvements: frontend technologies |
| Status | Closed (rejected) |
| Tags |
Type: Performance (custom) |
| Handling member | Chris Graham |
| Addon | core |
| Description | 1) move JS files to the bottom of the HTML, instead of <head>, now that we don't run JS code until DOMload. i.e. CSS render will happen before JS activates itself - gives people a chance to look earlier on before they need to do anything.
2) demodularise- detect what CSS and JS used on front page of current zone by Guests, and merge these into the cache algorithmically. Store what has been merged in the DB (get_value/set_value), so that when we do a require on them we know we don't actually need to do anything. 3) limit where cookies are sent, and allow parallelisation, via automatic CDN detection. Do some auto-probing for common sub-domains. Have a config option that specifies what sub-domains to probe, which defaults to "www,mail,ftp,cdn,<IP>" ('www' would not be used if actual base URL is using that). <IP> should not be parsed into the config option value, but parsed at run time. 4) Use CSS3 for all rounded corners, etc. |
| Steps to reproduce | |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
For example, if you click an expander link, you shouldn't get a function undefined error.
There are various solutions:
- (leave includes at front, as it is now)
- put in aforementioned guards (over-complex)
- put in stubs that wait for full page load (over-complex)
- suppress the errors (nasty)
- attach the Javascript event handlers dynamically, stop using inline JS (see #508 -- very time consuming)
So I kind of think leaving it as is is the best approach. This is not really a big issue, our JS is very lightweight, we're talking a few KB that has to load once into the users browser cache.
Ultimately #508 could happen, but that is beyond reasonable to implement unless we get a sponsor with deep pockets. I don't consider that a high priority as the payoff to work ratio is pretty poor, and it does hamstring support for third-party code quite a bit.
4- done