The environment parity provided by Trellis only applies if you’re provisioning both your local development environment and your remote server with Trellis–if you’re deploying to Kinsta, you aren’t provisioning anything remote: Trellis is only acting as a deploy mechanism for your staging/production servers.
Additionally environment parity is about the environment being the same–i.e. the OS, the configuration of various system services, nginx setup, etc–not resource parity. Your local VM and your remote server are very likely to have different system resources which can affect performance in a variety of ways.
A local VM (I’m guessing on VirtualBox?) is almost always going to be slower, sometimes significantly so, than a remote production server. VirtualBox has to do a lot of negotiation with the host OS and that’s always going to cause speed issues–IME especially w/ filesystem access which can be a bottleneck. Although most web hosts are still technically running virtual machines, they’re running on a system that is using very different, much more optimized virtualization software and hardware that’s going to provide near-native performance for those virtualized machines. You and I are running consumer desktop machines, and VirtualBox has traded performance for (relative) ease of use.
In my experience, slow WordPress sites are frequently the result of a large number of database queries, or slow/badly-written database queries. WP_Query and the other functions that wrap it have the potential to generate on your behalf some very unpleasant queries (i.e.
OR searches for multiple meta fields). The worse performance of a local environment due to virtualization may exacerbate this problem (plus Kinsta has probably tweaked their MySQL environment w/ caching, etc, in a way that results in significantly improved performance to what you might see locally). A plugin like Query Monitor might help you track down bad queries. Kinsta has also recently introduced a very helpful monitoring tool which provides some great feedback on your environment and its behavior. Even if you don’t see the same perf issues in production you’re still running the same queries so you might still get some useful information.
If your site is doing things that hit the filesystem more frequently than usual (i.e. you load a whole bunch of images from the media library) that could also cause a performance dip locally, since filesystem performance in VirtualBox is usually quite a bit worse than what you see on a production server. As always, checking your logs is a good place to look as well.
That seems like a lot of plugins. Even if they are all required for your site to work, you might have some debugging success by selectively turning them off and seeing if you noticed a marked improvement in performance. That could help you narrow down where the issue might be coming from. Even if “delete that plugin” won’t ultimately be a viable solution, you’ll know what’s causing the problem, which can give you a path to solving it or working around it.
If any of your PHP scripts are making remote requests (i.e. to REST endpoints or something) that’s another place to look for performance issues: If they’re having trouble reaching the URLs they want to hit it may be taking them a long time to fail, or if they’re pointing at URLs w/in your site they could be running into and exaggerating the virtualization perf issues described above, or simply failing because for some reason they’re looking for production-y URLs that now no longer exist.