When we change things on the screen, we frequently trigger repaints in the browser, which can make things flash from quite visibly to almost insensibly. This directly affects the usability of the site and can be another reason for the low engagement of the users. Repaints might be even slower on mobile devices. In web design, it is often said that less is more and this is also valid for repaints. A common advice is to minimize the areas that the browser needs to repaint. This is another reason why we need to adhere to the principle of proximity in the use of design elements—if they are closer together, the repaint cost might be considerably smaller than if they are further apart. We don't want that the diagonal distance between where a user action happens and where the screen is updated is too long as this could trigger a rectangular repaint of the whole screen.
We can find the repaint areas if we enable "Show paint rectangles" in the settings of Chrome Developer Tools. The result can be surprising and will give us a better understanding of how rendering works.
In the following example, we can see a fairly simple screen with one <span> element that has a number and one absolutely positioned <div> element that when clicked, increments this number.
As we can see, the height or the top padding of the <span> element do not affect the paint area, but the font size and the width do. Every time we click the whole repaint area changes, even though the number occupies a negligible space. But it could have been worse, if the height of the area was extended to the point of click on the <div> element. In this simple example, this isn't the case, but we can see that the space between the characters in the <div> was repainted. Every time we click, a different letter or word may be selected and this too will cause a repaint on the small selection. We don't know what might happen if the browser had multiple small areas to repaint in the bottom left corner too. Then it might choose to paint everything together and not update countless small areas individually. As a result, we would still have a large repaint area.
Assuming how repaints will happen is not a good idea. We need to test in our own situation, see how the browser (this one!) behaves and make the necessary adjustments. If we repaint large areas every time the user interacts with the page, the time required will be in the seconds range. Similarly, a great site that has a long page transition time will be tiresome to use. Everything that is repeated many times must as efficient as possible and this includes user interactions as well.
We need to know not only how to complete a project, but also how it will be handled by the browser as an intermediary between us and the user. But we should not limit ourselves in this position. Staying close to the user allows us to learn about its working environment and the laws that are valid in it. Being aware of what is seen as appropriate delay for our kind of system and how different technological constraints influence this delay allows us to serve a range of users and not just a tiny group of have-it-all individuals. At the end, the milliseconds of the few are often the seconds of the many.