I've used Chromatic before and really enjoyed it: https://www.chromatic.com/features/test
Jest also offers the core functionality if you want to roll your own tests: https://jestjs.io/docs/snapshot-testing
But phrases like "snapshot testing" and "visual regression testing" are what you you/your FE team should be Googling – hopefully there's a tool out there that fits your existing architecture!
Otherwise, as sibling commenters have noted, a policy of screenshots also works.
We recently started using Vercel to host our front-end application, and out-of-the box, it automatically deploys every branch to it's own "Preview" environment. This has been game changing for me, inverting my review workflow. Before I look at the code, I typically test out the UX changes live.
As a backend developer there's a certain "thoroughness" you have drilled into you about making sure backend PRs are "rock solid" and everything is well reviewed (because sometimes PR is the only place you catch things that would cost considerable problems in Production). That's a great mindset to have! It's not necessarily a mindset you need to bring to frontend PR reviews.
For UI changes, those often get plenty of "review" in User Acceptance Testing. We want to think that UAT is a deep process that tests every aspect of the app, and sometimes we build complex QA scripts for UAT testers, but in most cases in my experience the things that UAT are most reliable for are primarily fairly shallow, and UI/visual bugs are the number one thing UAT tests find quickly and reliably. (You don't feel a lot of UAT pressure on the backend which is why sometimes you feel a need to get backend PRs as solid and comprehensive as possible. The opposite happens in frontend work: the PRs can be a bit "sloppier" because UAT often is a strong "canary" for bugs/mistakes/glitches/tweaks.)
As often a full stack developer my experience is that backend and frontend focused PRs have very different needs in the PR process. If there's a strong place to apply that "backend mindset" to frontend PRs it is in a lot of the same things that likely make you a good backend programmer: frontend JS has all the same memory and performance management tasks of any other garbage collected language you work with. For instance: are your frontend engineers considering the O-complexity of their algorithms and their memory storage? That may even be the reason they want someone more "backend minded" reviewing "frontend PRs". They may be too busy worrying about the UI/visual changes of their tasks and don't have as much bandwidth or need to pay as much attention to how the code is working at a performance level and that sort of "cross-pollination" between mindsets in PR benefits the project (users experience those performance/memory issues pretty directly, but it can be hard to focus in planning UI/frontend tasks).