3 ms·

Filesize is not necessarily better performance. On todays hardware i believe (but i have not tested this..) that opening a zipped 1MB file often is slower than

• jo909 10y ago
  On the contrary, reading over the network or from disk (no matter how fast and modern) is still comparatively slow and is nearly always the bottleneck. Most non-embedded CPUs are more than fast enough to decompress every bit they get from the network or disk without decompression becoming the new bottleneck. There are other factors like latency, seeking, the minimum block size, and it always depends on the application, but generally speaking reading and writing compressed data should always be considered. That being said, for CSS the benchmark should rather be the size after gzip or other commonly used HTTP-Stream compressions, which are almost universally used anyway.
  • rocqua 10y ago
    Compression and HTTPS don't play nice together though. So in cases where every byte matters, and you can't get rid of HTTPS (an admittedly rather niche use case). This minification still has some uses.
    • jo909 10y ago
      If you are talking about the BREACH vulerability, CSS won't reflect user input. The attacker is not able to observe thousands of slight variations of the same file, which is how this attack works (simplified). Transferring static files compressed over HTTPS is completely safe to my knowledge. So maybe if you inline your CSS into the page this comes into play. Also I never said minification is useless, only that you need to compare plain+gzip vs minifier1+gzip vs minifier2+gzip to see the _effective_ size reduction.