DCT is not an algorithm at all, it’s a mathematical transform.

It doesn’t have a compression ratio.

> DCT compression, also known as block compression, compresses data in sets of discrete DCT blocks.[3] DCT blocks sizes including 8x8 pixels for the standard DCT, and varied integer DCT sizes between 4x4 and 32x32 pixels.[1][4] The DCT has a strong energy compaction property,[5][6] capable of achieving high quality at high data compression ratios.[7][8] However, blocky compression artifacts can appear when heavy DCT compression is applied.

https://en.wikipedia.org/wiki/Discrete_cosine_transform

Exactly, it’s not an algorithm, it’s one mechanism used in many (most?) compression algorithms.

Therefore, it has no compression ratio, and it doesn’t make sense to compare it to other algorithms.

Correct. DCT maps N real numbers to N real numbers. It reorganizes the data to make it more amenable to compression, but DCT itself doesn't do any compression.

The real compression comes from quantization and entropy coding (Huffman coding, arithmetic coding, etc.).

The web didn't go from streaming 480p straight to 4k. There were a couple of intermediate jumps in pixel count that were enabled in large part by better compression. Notably, there was a time period where it was important to ensure your computer had hardware support for H.264 decode, because it was taxing on low-power CPUs to do at 1080p and you weren't going to get streamed 1080p content in any simpler, less efficient codec.

Right.

Modern compression algorithms were developed but not even computationally available for some of the time.

I'm sure it helped, but yeah, not only e2e bandwidth but also the total network throughput increased by vast orders of magnitude.