#3 The Performance Device Gap

#3 The Performance Device Gap

As content consumption on the web is shifting from desktop to mobile, we’ll need to be aware of significant differences between those mobile devices. 

Typically, we assume that our web app roughly behaves the same way on different devices. But sadly, this is not true. And it’s not just about the browser or some ancient OS versions. It’s about the device itself. 

Vendors push low end devices on the market, designed to be affordable to a wide range of consumers. For developers like us, this means that processor power and therefore performance of our websites is varying a lot. 

Why does this matter? As the JavaScript we need to add interactivity to our website is mainly executed in a single thread (except for web workers and service workers) which is consuming CPU power. This thread is called the main thread and runs on a single core. The main thread is the thread from which all other threads will be spawned and workload will be distributed to other cores.

The problem is that the browser's renderer process is also run in the main thread. The main thread of the renderer process handles the code needed to render the page. It parses the HTML and assembles the DOM and it parses and applies the CSS to the DOM, and finally it parses, evaluates and executes the JavaScript. 

In conclusion, any time the main thread is busy doing something, the web site may not respond to interactions, which is finally delivering a bad user experience.

So, the main metric we have to look at is single core performance. This characteristic varies a lot between devices. There is a huge gap between the higher end and the lower end in the market.

Addy Osmani put together a chart which illustrates how bad that gap actually is.

What can we do to improve the situation for lower end mobile devices? We should carefully monitor the performance of our site and try to bring down the load of the main thread where ever possible. Besides compressing the assets served there are several strategies which can help out with this problem: 

Tomorrow follows: #4 Web Performance Basics.

要查看或添加评论,请登录

Thomas Feldhaus的更多文章

  • The speed of use

    The speed of use

    At the previous article "The perception of performance" we found out a lot about the human perception of time and speed…

    1 条评论
  • #19 The perception of performance

    #19 The perception of performance

    Do milliseconds and kilobytes make the difference? In the previous articles on performance we have heard a lot about…

  • #18 Building a web performance culture.

    #18 Building a web performance culture.

    Web Performance is not a product feature that can be easily switched on and off, ideally the entire organization…

  • #17 AMP, Performance built-in.

    #17 AMP, Performance built-in.

    For 16 episodes we have now bombarded you with tips, tricks and ideas how you can improve the speed of your web app…

  • #16 Webassembly

    #16 Webassembly

    WebAssembly or short Wasm is a huge deal as it is enabling deployment of lower level language code on the web for…

  • #15 Image & Video Formats

    #15 Image & Video Formats

    In the first years, the Web was a text-based wasteland with only a few image oases available solely through links. This…

    1 条评论
  • #14 PWA/Service Worker

    #14 PWA/Service Worker

    When thinking about performance, web technologies always had a reputation of being slow and sluggish, especially on…

  • #13 Web Performance Timing APIs

    #13 Web Performance Timing APIs

    If you are into web performance you surely stumbled upon very detailed numbers. No matter whether you measure…

  • 12 Javascript defer or async?

    12 Javascript defer or async?

    When adding interactivity to our web pages we heavily rely on JavaScript. But adding JavaScript comes with a price.

  • #11 JavaScript Performance

    #11 JavaScript Performance

    Nowadays, web applications are heavily interactive and make use of lots of JavaScript. May they be scripts we wrote for…

社区洞察

其他会员也浏览了