Google Lighthouse has recently had an update. This may also have (negatively) influenced your scores. I briefly paid attention to it in a LinkedIn post, but in this blogpost I will go into it a bit more deeply.
A choppy animation or laggy scroll behavior, you might have run into it before. Even when the actual page speed is good, poor performance can still have an impact on click-through behavior of visitors and the conversion rate.
Optimization doesn't stop at pagespeed alone. Website optimization goes beyond pagespeed as far as I and Core Web Vitals are concerned.
CSS animations on smartphones
Animations can be heavy on older browsers or operating systems, when an animation is done via the Central Processing Unit (CPU), which is responsible for performing tasks assigned by the computer. But even on newer computers, it can happen that it starts to blow as an animation unfolds within your web browser due to the CPU being overworked.
The same goes for mobile phones. Even if you have a newer smartphone, this could have impact on your smartphone device's CPU; Besides that, the animation can appear choppy and the battery of the phone of your website visitors will drain faster (I know mine will).
JavaScript versus CSS animations
For example, animations of a button at mouseover, fold-out navigation, a slowly retracting header on scroll or changing shadows can be realized through JavaScript. jQuery made the life of frontend developers a lot easier, in addition to the fact that CSS notation could be used. However, jQuery isn't exactly known for being fast when it comes to animation performance. Through the CSS transition property, you can easily create animations in CSS only. But even then, vigilance is in order.
Animation processing
Computing power is required for animations to take place. Depending on the implementation of an animation on a website, the entire web page may or may not have to be redrawn by your browser (over several frames per second). You may hardly notice this (if you don't know), but it is something to keep in mind. You can prevent the webpage from being completely redrawn by the browser by off-loading an animation to the GPU of your computer.
GPU vs CPU
GPU is the abbreviation of Graphics Processing Unit and is able to take over tasks from the more famous CPU. The GPU is therefore used for video tasks. Tasks that go over the GPU (hardware) can be run in parallel, allowing animations to run smoother. The hardware on which the calculations take place is called the Hardware Accelerator, which is why this technique is called Hardware Acceleration.
CPU animation gains
As a result, offloading animations to the GPU instead of taking place on the GPU comes with another advantage: smoother animations as the browser will then be able to perform and display animations over 60 frames per second, instead of maybe 30 frames per second.
Another advantage is that as such animations are off-loaded, it won't be impacted by other 1st party or 3rd party JavaScript tasks. If some other task would block the main thread, a CPU animation will freeze for a variable amount of time (for example depending on device constraints, so no one will have the exact same user experience).
However, when animations are offloaded to the GPU, they can continue happening, even if the main thread was blocked. I created a demo that speakes for itself as part of my Chatbot pagespeed impact visualized demo.
How do you address the GPU with CSS animations?
A valid follow-up question is how you can force animations to run on the GPU. A handful of CSS properties will force offloading the work to the GPU when they are animated through the CSS property transition. That means that most of the CSS properties should ideally not be animated.
How it should be
Every frontend developer will have been guilty of changing the left, right, top, bottom, height and / or width property, for example through jQuery or in combination with a CSS transition. This is the best example of how not to do it. In particular, use the transform property in combination with the many possible values to achieve the same effect; getting bigger or smaller buttons or, for example, images at mouseover. In practice, this may require some creativity.
In addition, indicate which exact CSS properties will be animated by means of transition. Multiple transform property values can be animated simultaneously.
A pitfall is to specify "all" as a transition property, so that all properties, from dimensions to use of color, are included in any changes to the header to be animated. This also has the effect that the browser reserves space for this in the memory.
Do you have a more complicated animation that cannot only take place with transform? Then use some sort of CSS hack, to have the processing of the animation moved to the GPU instead of the CPU. One side effect is that it ruins text anti-aliasing during animations.
Using the CSS will-change property as an alternative to the above hack, you indicate to the browser that a change to a specific CSS property is imminent. However, the will-change property comes with a manual if you want to avoid continuously enforcing the required memory through the browser.
How not to do animations, a real world use case
PhoneGap.com shows in their desktop web version how not to do it. When scrolling, the height of the header changes. The size of the logo and accompanying name also changes at the same time. When you dive into the code, you see that it is played with, among other things, the height, padding-top and background-color properties. As if that is not bad enough, it is indicated that all properties can animate. All animations will take place over the CPU. This can be tested by scrolling back and forth a few times, such that you repeatedly trigger the animation. You will notice:
- a
scrollclass is added to.site-header; - this will change properties such as
height,padding-topand evenbackground-color; - this is a less-smooth CPU animation;
- and the fan of your computer or laptop might actually start to blow.
This is a translated article of an earlier written article. While translating, the PhoneGap website was taken offline. I could have seen this coming as Adobe discontinued its support.
The alternative would have been to let the CSS before / after pseudo-element be responsible for the header background and adjust its opacity to mimic a transparent background. Using translateY as transform-value, you move the header element along a vertical axis to make it appear as if the header is moving upwards to take up less space. If they had read this article, they could have implemented it correctly, combined with the above creativity.
Core Web Vitals
Only three metrics are making up Core Web Vitals: LCP, CLS and FID. While LCP is a pagespeed metric and CLS is a UX metric, FID is the only performance oriented metric. However, there is a possibility that web animations will become part of Core Web Vitals as well as part of a new metric. Or it might be combined with FID. Only time
(and by that time Google) will tell.
