By Addy Osmany on 01/08/2018
If client-side JavaScript isn’t benefiting the user-experience, ask yourself if it’s really necessary. Maybe server-side-rendered HTML would actually be faster. Consider limiting the use of client-side frameworks to pages that absolutely require them. Server-rendering and client-rendering are a disaster if done poorly.
- Javascript is the most expensive part of your site.
- Measure.
- 💡 Apply code splitting and tree shaking.
Three moments
-
Is it happenning? Transfering started.
-
Is it useful? Someone of value is seen in the page.
-
Is it usable? Interactive and fully engageable.
Make the application interactive as fast as possible is one of the key things to get faster interactiion time.
TTI varies a lot depending on the devices. A good metrics suggested is under 5 seconds with (3G on a median mobile device)
Problem stated: Loading too much JavaScript into the main thread (via <script>, etc) is the issue.
💡 Pulling JS into a Web Worker or caching via a Service Worker doesn’t have the same negative Time-to-Interactive impact.
There are a lot of things the browser request to start painting the page.(Not very detailed explanation here)
- Parse and compile takes up to 30% of the time engine.
- All bytes are not equal: 200kb js !== 200kb jpg
"stop taking fast networks and fast devices for granted"
- When variance can kill the user experience, developing with a slow baseline ensures everyone
💡 Minify your code 💡 Compress 💡 Ship less 💡 Take advantage of caching for repeat visits
Look for lighter alternatives on libraries. e.g. date-fns instead of moment.
💡 Use the codecoverage tool from chrome dev tools.
- Create a performance vision.
- Setup your budget. lighthoust-ci
- Create regular report on KPI. Webdash
- Long tasks.
- First input delay.