3 ms·
With respect, why exactly is total script size 912kb minified? That seems unexpectedly high. Likely not the root of the problem at hand, just curious. Also int
by catshirt 16y ago
With respect, why exactly is total script size 912kb minified? That seems unexpectedly high. Likely not the root of the problem at hand, just curious.
Also interested in what you plan to do to alleviate massive DOM issues, if you could share. Typically an overlooked point of performance.
- russ 16y agoI don't have a breakdown with precise numbers for you, but some bloat comes from the fact that we include all of our templates in the phoenix bundle. Some savings could come from fetching certain components and pages on demand, but right now, we pull down everything. Gzipped it drops to ~200k, which isn't terrible considering that this is fetched in parallel with API resources and the initialization of our cross-domain iFrame. We're currently working on getting our bootstrap time down, so the bundle size may be reduced as a result of that effort. Re: DOM issues, when you switch around between pages and/or timelines, we detach the timeline DOM elements and keep a reference in memory. Upon returning to a previously loaded timeline, we do a repaint (not bad). Right now, we don't employ any such technique for an active timeline that has been scrolled a long way down. One thing we can do is detach large blocks of tweets that aren't in the viewport and splice them back in (while maintaining an accurate scroll height) if the user scrolls back up.
- catshirt 16y agoGood deal russ, thanks. There's a fine balance to maintain between combining and lazy loading files. Still seems to be one of the harder front end problems to solve since client side architectures are all relatively unique. Thanks again sir.