WebKit on Windows has progressed since ~5 years ago. The gap between the Windows port and the Linux WPE/GTK ports is shrinking over time.
Every JIT tier has been enabled for JSC on Windows[1], and libpas (the custom memory allocator) has been enabled.
The Windows port has moved from Cairo to Skia, though it's currently using the CPU renderer AFAIK. There's some work to enable the COORDINATED_GRAPHICS flag which would enable Windows to benefit from Igalia's ongoing work on improving the render pipeline for the Linux ports. I go into more detail on my latest update [2], though the intended audience is really other WebKit contributors.
Webkit's CI (EWS) is running the layout tests on Windows, and running more tests on Windows is mostly a matter of test pruning, bug fixes and funding additional hardware.
There's a few things still disabled on the Windows port, some rough edges, and not a lot of production use (Bun and Playwright are the main users I'm aware of). The Windows port really needs more people (and companies) pushing it forward. Hopefully Kagi will be contributing improvements to the Windows port upstream as they work on Orion for Windows.
A CMPXCHG16B instruction is going to be faster than a function call; and if the function is inlined there's still binary size cost.
The last processor without the CMPXCHG16B instruction was released in 2006 so far as I can tell. Windows 8.1 64-bit had a hard requirement on the CMPXCHG16B instruction, and that was released in 2013 (and is no longer supported as of 2023). At minimum Firefox should be building with -mcx16 for the Windows builds - it's a hard requirement for the underlying operating system anyway.
The "Chrome Commit Tracker" linked is a pretty interesting set of visualizations that I hadn't come across before. Makes it a lot easier to get a feel for the sizes of the various teams, and how they change over time.