There is a good article on web.dev about this.

The key takeaway is that in their example of a really long page it was 7x faster at rendering, on a low end mobile device this would obviously be amplified greatly.

In our example, we see a boost from a 232ms rendering time to a 30ms rendering time. That's a 7x performance boost.

So we could infer that if the page goes from 232ms to 30ms on a Mac then on a mid tier mobile phone that could be up to be as high as 1 second vs 120ms as the CPU is about 4 times slower.

side note: For CPU speed differences this page from the Lighthouse repository has a nice table at the bottom that explains the relative performance of a high end laptop vs a mid to low end mobile phone, just so you know where I get a 4 times slowdown.

The difference between lazy loading and content-visibility: auto
This isn't a replacement for lazy loading. If you had to choose between the two pick lazy loading every time!

Lazy loading does not even request the data until it is needed (if done correctly). content-visibility: auto means the browser will still request all the data, it just won't render it.

This codepen from the article lets you confirm that. If you open the network tab and reload the page you will see that all assets are downloaded, but the rendering time is much lower if you leave the following CSS in place (if you remove it you can see the increased rendering time)

.story {
  content-visibility: auto;
  contain-intrinsic-size: 100px 1000px;
}

As most speed issues on sites are down to network requests and data sent over the wire lazy loading is still needed and far superior to just adding content-visibility: auto to every section.

Should I use it?
I mean, yes, I would.

Assuming your page is properly structured you shouldn't have any issues. Setting the intrinsic heights and widths of things is something I need to investigate more to see if that has any impact on Cumulative Layout Shift if you get it wrong.

side note: from what I understand if you get the sizes wrong of the container it will just work like contain: paint so you won't get quite the same benefits. This is pure conjecture, do not take this as part of the answer!

I would especially look at implementing it if your user-base is mainly using Chrome on mobile (35ish percent of all browsers according to caniuse.com) as it is supported on Chrome.

Worst case scenario is that it never gets implemented in other browsers (although Firefox is already looking at implementing it and Edge obviously has it being Chromium powered).

At this stage you have a CSS property that might get deprecated, for the sake of a kilobyte or two it can't hurt (assuming it doesn't negatively affect CLS as I stated earlier)!

driver.execute_script("arguments[0].innerHTML = arguments[1]", element, HTML)

your issue starts here "driver.close()" - close method closes the current window - no matter how many tabs you have, but it doesn't kill chrome instance (drive.quit() - does the job). If you want to close the current tab you can use a workaround like

# Close current tab for windows/linux
driver.find_element_by_tag_name('body').send_keys(Keys.CONTROL + 'w')

# Close current tab for Mac
driver.find_element_by_tag_name('body').send_keys(Keys.COMMAND + 'w')

I have task to build equivalence classes, and boundary values based on given information

To calculate the electricity cost user should enter an old and a new values of electricity counter and press “Calc” button. It works only if values are entered correctly:

contain only digits;
no longer than 6 digits;
new value is not less than an old one;

I did this task, but i don't know if i did it right It would be great to get feedback