CHAPTER 6 Finding and Fixing Mobile Web Rendering Issues
you may still need it. The browser developer tools in Chrome, Opera and
Firefox can point out where garbage collection has occurred so you can find
out where and why you’re generating garbage and attempt to address this.
The last thing to keep in mind is something we call deoptimization.
This happens when some of the designs you’ve made in code have led to
the engine having to back out of an optimized path for slower code. There
are tons of reasons why this can happen and it varies from engine to
engine. In Chrome, you can get a little mileage using a standalone version
of V8 called d8. It can inform you what JavaScript is being deoptimized,
giving you a chance to reconsider how you’ve written some of your code.RenDeR
Rendering performance has only recently come under the spotlight for
many Web developers and we’re going to devote the rest of this chapter to
understanding it. Each of your pages contains a DOM tree (representing
its content and structure). Painting the DOM to pixels on the screen can be
one of the most expensive operations in your page’s life cycle. Any extra ef-
fort involved in doing this as your user interacts with your page can result
in a visual slowdown. Lots of things can trigger this — scrolling, injecting
new content into the page, layout thrashing (any changes that modify the
layout of your page), interacting with the UI — pretty much any changes
that need to be painted.
As we’ll discuss in more depth soon, painting isn’t just about user
interactions. It also includes the effort the browser has to put in to decode
images (if you give it a JPEG, this has to be decoded into a Bitmap), as well
as resizing. If you give the browser a 1,024px wide image which you’re
resizing down to 360px using CSS, that’s going to be a lot less efficient than
simply providing a prescaled 360px wide image. Chrome’s DevTools can
give you some more insights into image decode times in Timeline.