421 is returned when the browser tries to reuse the connection for another site. This is allowed under HTTP / 2 to save the cost of opening another connection since, in most cases, it is better to use fewer connections under HTTP / 2.
The browser should only reuse a connection that is assigned to the same IP address and where the certificate used covers both sites (which is the case of its three sites).
Despite these conditions, occasionally the browser will try to reuse a connection when it shouldn't. Apache's main case is if different SSL / TLS settings are configured for each vhost. Looking at ssllabs.com for each of its three domains, the settings look the same, making it difficult to see why Apache is returning this. You should contact your hosting provider and ask them to verify this.
In these cases, Firefox will see response 421, establish a new connection, and request the resource again. However, unlike a 301 or 302, it appears that this won't show up as a separate request in the developer tools.
The alternatives to solve this are:
- Have the hosting provider identify the cause and allow the connections to be reused.
- Use different certificates for each domain (so that the browser does not try to reuse the connection).
- Use a different IP address for the other domains, even if they are assigned to the same server (so that the browser does not try to reuse the connection).
- Stop using http / 2, which seems a shame as it generally provides good performance.
- Stop using other domains, at least for HTTP / 2.
I think you should seriously look at the last one. The benefit of using other domains (called sharding) is often overstated in my opinion for HTTP / 1 and shouldn't be necessary under HTTP / 2.
Fragmentation is done for two reasons:
- To allow 6 lower HTTP / 1.1 connections as browsers, the typical maximum is 6 simultaneous connections per domain. However, unless those seventh, eighth connections … etc. used a lot, the cost of setting them up may not be worth it. And under HTTP / 2, the limit is much higher (generally at least 100 simultaneous streams per connection).
- Domains without cookies to save in request sizes. But under HTTP / 2, the HTTP headers are compressed, so you're less concerned about this (and again, in my opinion, the value of this was overstated: how big cookies really are).
Looking at the web page test for your home page, you're loading the main page over the www domain, and then 6 assets over one static subdomain and 6 assets over the following subdomain and a few more on each:
Here you can see the real cost of your 421s, as almost all connections need to be reestablished with one connection and SSL negotiation. Ignoring this for a moment, you can see that yes, you are downloading more than 6 resources at the same time in your two static subdomains. So if it is an HTTP / 1.1 connection, you would benefit from breaking the 6 connection limit for a moment. But you are also wasting the www connection which is down after the first request. This is made more obvious from the Connection View:
So you can get rid of one of those subdomains and serve those assets for the www domain to get utilization of that first connection.
For HTTP / 2, you can also get rid of the other domain as it shouldn't be necessary. Then it can provide different results to HTTP / 2 and HTTP / 1.1 users, but that's tricky, all major browsers support HTTP / 2 and for 24 requests in total it won't even be a huge performance load going to a domain for those who don't.
In short, stop sharing domains without cookies unless you have a good reason to do so, as a quick glance at your homepage is not helping your performance anyway, and while you're addressing this issue 421, you it is hindering considerably.