For what it's worth, I got the same result when testing in Chrome/Chromium 100, Edge 100, Opera 86 so this is clearly a Chromium core issue.
But yeah, pretty stupid idea to redo the request instead of just downloading from cache. Blame Chromium devs I guess - that's what we always do 😂
Also there is something wrong with that site, it does not give a correct number for the content-lenght header, this could even be a potential cause of the issue:
$ curl -I "https://transition.fcc.gov/fcc-bin/amq?call=&arn=&state=&city=&freq=530&fre2=1700&type=0&facid=&class=&list=4&ThisTab=Results+to+This+Page%2FTab&dist=&dlat2=&mlat2=&slat2=&NS=N&dlon2=&mlon2=&slon2=&EW=W&size=9"
HTTP/2 200
server: Sun-Java-System-Web-Server/7.0
content-type: text/html
content-length: 25412
expires: Mon, 02 May 2022 20:12:36 GMT
cache-control: max-age=0, no-cache, no-store
pragma: no-cache
date: Mon, 02 May 2022 20:12:36 GMT
strict-transport-security: max-age=31536000 ; includeSubDomains
Actually, come to think of it, by the look of the cache-control, expires and pragma header, it might be that Chromium does the "correct" thing here, as the headers tell the client browser to not cache or store the content at all. Again, stupid, but this one's on the site devs.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control