4 ms·
I 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 savin
by russ 16y ago
I 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.