At the bottom, the event handler has a chance to run sooner. A visualization of what happens to interactions when tasks are too long and the browser can't respond quickly enough to interactions, versus when longer tasks are broken up into smaller tasks.Īt the top of the preceding figure, an event handler queued up by a user interaction had to wait for a single long task before it could run, This delays the interaction from taking place. This matters because when tasks are broken up, the browser has more opportunities to respond to higher-priority work-and that includes user interactions. A visualization of a single long task versus that same task broken up into five shorter tasks. This means taking a single long task and dividing it into smaller tasks that take less time to run individually. Long tasks are indicated by a red triangle in the corner of the task, with the blocking portion of the task filled in with a pattern of diagonal red stripes. A long task as depicted in Chrome's performance profiler. This results in interaction or rendering latency.
#Js benchmark testing with settimeout update#
If the user is attempting to interact with the page while a long task runs-or if an important rendering update needs to happen-the browser will be delayed in handling that work. When tasks stretch beyond a certain point-50 milliseconds to be exact-they're classified as long tasks. The main thread can only process one task at a time. It's called the main thread for a reason: it's the one thread where nearly all the JavaScript you write does its work. The main thread is where most tasks are run in the browser. All of this stuff-with the exception of web workers and similar APIs-happens on the main thread. Later on in the page lifecycle, tasks are kicked off when your JavaScript does work such as driving interactions through event handlers, JavaScript-driven animations, and background activity such as analytics collection. For example, when a browser downloads a JavaScript file during startup, it queues tasks to parse and compile that JavaScript so it can be executed. Tasks impact performance in a couple of ways. A depiction of a task kicked off by a click event handler in the performance profiler in Chrome DevTools. Of all of this, the JavaScript you write and deploy to the web is a major source of tasks.
#Js benchmark testing with settimeout code#
Tasks involve work such as rendering, parsing HTML and CSS, running the JavaScript code you write, and other things you may not have direct control over. What is a task? #Ī task is any discrete piece of work that the browser does. To get your head around why it's important to optimize tasks in JavaScript, you need to understand the role of tasks and how the browser handles them-and that starts with understanding what a task is. What does any of that mean? Shipping less JavaScript is good, but does that automatically equate to snappier user interfaces throughout the page lifecycle? Maybe, but maybe not. If you read lots of stuff about web performance, the advice for keeping your JavaScript apps fast tends to involve some of these tidbits:
0 kommentar(er)
