Running X clients (graphical applications) over SSH with X11 Forwarding is notoriously slow, even over high speed remote links because the nature of the X protocol demands a lot of pinging-and-ponging back and forward which stacks latency up regardless of your connection speed. For performance reasons alone you are better off using VNC, NoMachine NX/FreeNX or X2Go if you find yourself doing a lot of work with remote graphical applications.

However performance isn't the only reason you should stop using X11 Forwarding over SSH if you can; for a very long time this functionality has been considered harmful and the reasons to abandon it have only kept growing.

As always, there are practical reasons to bend or break the rules and no shortage of situations where a thoughtfully configured, trusted environment can exist and X11 Forwarding is appropriate. Firefox is particularly slow over remote X and there are a couple of things you can do to improve the experience:

• Use the -C option when you connect to the remote SSH daemon. This enables compression, which will only help when your problem is low connection speed. Enabling compression on a high speed link will only add to your latency which in 2021 is probably your real problem. Some articles recommend specifying the gzip CompressionLevel (from 0 to 9, default 4), a ssh_config option with the -o flag on the command line (-o CompressionLevel 9) but this directive is only applicable to SSH protocol version 1 and will likely be ignored.
• Specify a cypher that is less computationally expensive for streaming data, i.e. RC4 or BlowFish-CBC; RC4 is deprecated and may not be available so we can specify a list of supported cyphers in decreasing order of preference with -c arcfour,blowfish-cbc. Be advised that these algorithms are considered less secure than the default AES, with RC4 being considered substantially less secure though much faster than BlowFish - apply appropriate judgement when considering the trade-offs of choosing alternate cyphers.
• Use -Y instead of -X to enable "trusted" X11 Forwarding and disable the X11 SECURITY extension controls. This ability relies on the ForwardX11Trusted setting being enabled in your local ssh_config and is generally discouraged however it will reduce the overhead of remote X forwarding at the expense of security considerations like inter-client snooping, key grabs and injection, among many more. That being said, it is debatable how much of a difference this really makes to overall security and running certain apps without trusted X11 Forwarding will cause them to crash. Some excellent reading fodder on the shotcomings of the X11 SECURITY extension can be found in this reddit discussion: What is up with the X11 SECURITY extension? The bottom line here is regardless of whether you use -X or -Y you need to have a lot of faith in the remote system when using X11 Forwarding.
• If it is still available in your version of Firefox, the most impactful thing you can do is enable XRender support in Firefox's about:config by toggling gfx.xrender.enabled from its default false to true. The X Rendering Extension was developed to provide a facility for rendering transparency - either with hardware acceleration (on the GPU) where supported or falling back to software rendering (on the CPU) where it isn't.

  XRender was disabled in Firefox by default when Firefox first moved to a built-in off-screen surface rendering implementation that is, in a conventional setting where the X server and clients are all located on the same machine, more stable and effective at taking advantage of hardware acceleration. Then a whole new compositing engine coalesced under the WebRender moniker. WebRender is a great advancement that takes advantage of OpenGL to vastly speed up virtually all aspects of rendering a page. By design it is tied to the GPU of the machine where firefox is running; this is a desirable trait because it won't suffer from the unnecessary overhead of the legacy, network-oriented X protocol calls XRender uses.

  Unfortunately, disabling XRender has the effect of forcing the entire Firefox window to be composed and redrawn with every change and that has subsequently devastated firefox performance over X11 Forwarding and X2Go. This is covered in numerous Bugzilla tickets where the firefox developers have spoken disparagingly about its use-cases. Worse, firefox is poised to drop support for XRender entirely; although it is obviously no match for WebRender when run locally, those costly X protocol calls and ability to render on whatever machine is actually displaying the application (including any hardware acceleration it makes available) are what makes it ideal for remote use.

  If your browser lacks the gfx.xrender.enabled option you may be able to enable the same functionality by setting gfx.webrender.force-disable to true, however:

  ...with the launch of Firefox 93, the support for the options to disable WebRender will be discontinued and this engine will be mandatory.

  It seems our only option going forward to use Firefox remotely with acceptable responsiveness is to either adopt a bit-scraping remote desktop protocol like VNC or run an insecure and outdated version to continue support for legacy use-cases like multi-seat configurations.