Do Less & Be Lazy: Practical Performance Patterns for Polymer
summary
Claims that meeting RAIL one second needs shrinking both download and render work, measured with webpagetest.org, and shows the PRPL pattern speeds the Polymer Shop demo by multiple seconds on routes. Rendering dominates when resources are local (Chrome UI case), so techniques focus on doing less: dom-repeat initial-count, iron-list, conditional dom-if for usually-false cases, lazy custom-element upgrade via importHref. Measurement tools like polyperf and polydev identify high-frequency expensive elements; a ratings-element case goes from ~6.5× slower than a native input to nearly native speed after CSS, lazy init and deferring listeners.
AI-written summary · about
chapters (5)
- 0:00Performance fundamentals
- 3:50Optimizing network usage
- 7:24Minimizing element count
- 14:17Profiling element costs
- 20:24Optimizing component costs
related talks
32mPerformance Optimizations for Progressive Web Apps
33mEnd to End Apps with Polymer
21mThinking PRPL
40m“Performance by Design”
19mPerceived Performance, And Why It Matters
48mThink Fast, First: Empowering a Performance Culture
34mOptimizing Performance in Large-Scale React & Node.js Applications
27mOptimizing the Critical Rendering Path in React