Excerpts from Google IO 2013 - Drilling down on performance! - Device Agnostic Development

Excerpts from Google IO 2013 - Drilling down on performance!

• Its is seen that support for desktop is 96%, phone 68% & tablet 69%.
• And prioritisation for desktop is 81%, phone 12% & tablet is 7%.

Today web is being consumed by different devices.

According to the grand unified theory of devices, the delay factor can come into existence in the following areas - 

1. Network
2. Compute
3. Render

Device Vs Constraints :

With respect to the available devices and contraints for the same, framerate has to be maintained at 60 fps.

We would need solving for the below areas -

Solving for network :

• Reduce page load time - PLT

 >3 secs, 57% of the users go away.

 46% will not return out of these.

 22% will tell their contacts not to use this website.

•  So on the average 1 in 5 will tell their contacts not to use the site.
• Reduce your requests
• Latency, bandwidth and financial cost.
• Remove any requests which are obsolete or not required : do you really need that file?
• Concatenate and minify
• 60% of web traffic is images - change formats, request the size that is required for the page or fits the page & SVG/ web fonts might be a better option.
• Mod_pagespeed plugin.
• Use page speed insights to analyse and suggest optimisations to the page
• Use resource timing api.

Solving for compute:

• Jank - 60 Hz framerate allows 16.7 milliseconds to get everything done - called as - frame budget.
• Limit style recalculations
• Don't change the body when you should change child elements directly.
• Limit style changes to DOM.
• Avoid layout thrashing - asking for offset fit requires a layout calculation, multiple get(s)/set(s) will increase the cost - should be get once and use at all places.
• Remove unnecessary JS - don't do in JS that which can be done in CSS - animations and one transitions.
• Keep position : fixed or position : sticky.
• Keep your event listener code to a minimum - they can run several times per frame - store the scroll value of the last operation and keep that one value for one handler approach.

Solving for render:

• Typical page shows around 13 ms for processing images and 70ms to image resize rendering time - objective should be getting smallest possible image in the correct dimensions to avoid resizing.
• Paint costs - scroll that corresponds to entire page getting repainted
• 'enable continuous page' painting in chrome settings and check out the css element adding to the cost.

Suggestions:

• Assess performance constraints before you start
• Set limits- eg : no of requests, GCs, paint time, layout, style calculations.
• Track during project lifetime.
• Don't ship until you hit your targets.

Additional tip for different devices:
Give them the same content but refactor for the constraint.

Sites for more information:
Use Jankfree.org for more details.