Performance - Caching

Hajime Yamasaki Vukelic has come to the conclusion that, if you’re dealing with a really big number of DOM nodes that need to be updated in real time, frameworks are usually incredibly slow on top of the already-slow DOM operations you have to do. The solution they settled on is to avoid frameworks altogether for these scenarios and use vanilla JavaScript. Also of note are that repaints and reflows are going to be big bottlenecks regardless of what you use.

• If you are looking for performance, don’t use frameworks. Period.
• At the end of the day, DOM is slow.
• Repaints and reflows are even slower.
• Whatever performance you get out of your app, repaints and reflows are still going to be the last remaining bottleneck.
• Keep the number of DOM nodes down.
• Cache created DOM nodes, and use them as a pool of pre-assembled elements you can put back in the page as needed.
• Logging the timings in IE/Edge console is unreliable because the developer tools have a noticeable performance hit.
• Measure! Always measure performance first, then only fix the issues you’ve reliably identified.

In the nooks and crannies of the web performance discipline there are no simple answers, except “do your research”. Rely on analytics to decide if bundling is a good idea for your HTTP/2-driven site. Do you have a lot of users that only go to one or two pages and leave? Maybe don’t waste your time bundling stuff. Do your users navigate deeply throughout your site and spend significant time there? Maybe bundle.

This much is clear to me: If you move your HTTP/1-optimized site to an HTTP/2 host and change nothing in your client-side architecture, it’s not going to be a big deal. So don’t trust blanket statements some web developer writing blog posts (i.e., me). Figure out how your users behave, what optimizations makes the best sense for your situation, and adjust your code accordingly. Good luck!