The testing pyramid is a popular communication tool to show where the quantity of testing should occur. Some people have to complain about the analogy. In essences the push is to have a reduction in tests which happen at the UI and with full system integration (end-to-end testing). There is plenty of information out there on why you want to do that, like the article I linked above.
While I haven't actually made this path happen, I'm looking at yet another layer of separation to help facilitate the UI testing, mock the backend interactions. The goal here is to identify the primary state changes the UI is expected to under go, verify the UI requests to the backend and to return events back to the UI to validate its behavior to that response. This keeps the end-to-end part of the setup to be less complete, though a good mocking of backend system is still an undertaking.
The other aspect to UI testing is that Selenium is quite popular, but isn't really stable or consistent. So I'm also going to focus on utilizing only headless Chrome for the majority of UI testing. Once that testing is complete I can look at what is left to test with the end-to-end environment.