Frontend performance exercise: eBay.com scrolling
A few days ago, surfing on eBay Italia website, I have noticed that the homepage was losing some frames when scrolling. So I have tried to check if was the website to give me troubles or if was time to change my laptop.
TLDR
Please eBay add this CSS to your stylesheets to improve scrolling performance (at least on Chrome):
.prom span.gspr { -webkit-backface-visibility: visible !important }
// Or remove -webkit-backface-visibility: hidden; from your CSS
.header { will-change: top; }
a#gh-bt { will-change: right; }
#user-feedback { will-change: transform; }Step by step
0. Open Chrome and the developer tools
Here no explanation is needed, just to write something I can say that I’m working with a 2011 Macbook Air 13" and using Chrome 44.0.2403.155 (64-bit)
Every screenshot and all the results can be different from yours, but the improvements should be the same for all.
1. Register a timeline with some scroll events
Activate the tab Timeline in the DevTools of Chrome and start recording using the round button in the top left (or using `cmd+e` on mac).
With the registration started do some scroll of the page, 2 or 3 second are enough. At the end stop the registration in the same way that we used to start.
As we can see there are a lot of frames (the vertical bars) that pass the 60fps limit. They are mainly colored in green, this color says that the longer process for each frame is the Painting.
To better inspect this phase we can relaunch the recording of the timeline with the tick on the Paint checkbox.
Now we have a lot of data to analyze useful to find our bottlenecks.
2. Layers inspect
In the Timeline select one of the longest frame by clicking on it. In the details activate the tab Layers.
Expanding the main layer #document we can notice that there are a lot of span.gspr rendered each one on a dedicated layer. Looking at the preview we can see which elements they are on the page, the red ribbons of the sales.
Looking at the website dynamics I think that they don’t need to be on a dedicated layer, and to detect the cause that create the layer is very simple, just look to “Compositing Reason” and Chrome will say what we want to know.
The backface-visibility CSS property is forcing every span.gspr to detach from the main layer. To solve this problem we have to select one of the spans and from the Elements panel of DevTools disable that CSS property.
If we start a new record of the timeline we can see that now we have just the root layer. A small improvement for the website’s performances but not yet enough.
3. Paint rectangles
Now that we have removed all useless layers, we can check if can be useful to create new ones. Check Show paint rectangles in the Rendering options and let’s make again some scrolls.
As we can see scrolling the page there are 3 green-blinking elements:
- the scrollbar
- the fixed header
- the arrow “Scroll to top”
For the scrollbar we can’t make anything, but for the others 2 elements, maybe, it can be useful to put each one on a new layer.
We have to try and measure!
In the Elements tab of DevTools select the element .header, as it is the one with position: fixed. Analyzing the CSS properties of the element we can notice that it has a transition for top. We can create a new layer adding to the element’s properties will-change: top.
Let’s make the same procedure for the arrow adding will-change: right.
Scrolling the page now we can see that this 2 elements don’t blink anymore. Let’s record a timeline to see if something has changed.
As we can see now there are 2 layers above the root and really good scrolling performances!
eBay.com
For eBay.com we can make the same corrections as made for the italian website. But there is an element more that need a layer: the link to the survey (#user-feedback) at the bottom left. We can just add to it a generic will-change: transform.
Conclusion
There is a thin line, almost invisible, between good website and great website. It is called optimization.
And don’t underestimate the power of CSS!
