The error message cy.type() can only accept a string or number. You passed in: undefined says the last part of the path is undefined, e.g this.data.fullName or this.info.userGoodCredit.company. If this.data was undefined, you error would be cannot get property "fullName" of undefined, so your beforeEach() is probably ok. It looks like there's a typo in the property used in the test, or in the fixture object. Check with console.log(this.info.userGoodCredit) and console.log(this.data).

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)!

Here is how can you do it require('chromedriver'); const path = require('path'); const wd = require('selenium-webdriver'); const chrome = require('selenium-webdriver/chrome'); var builder = new wd.Builder(); var options = new chrome.Options(); var prefs = new wd.logging.Preferences(); var driver; prefs.setLevel(wd.logging.Type.BROWSER, wd.logging.Level.ALL); options.setLoggingPrefs(prefs); driver = builder .forBrowser(wd.Browser.CHROME) .setChromeOptions(options) .build(); driver .get(`file://${path.resolve(__dirname, './page.html')}`) .then(() => driver.manage().logs().get(wd.logging.Type.BROWSER)) .then((logs) => { console.log(logs); }) .then(() => driver.quit());