Does this report represent gzipped sizes of CSS files or the uncompressed size? It would be helpful to have a report showing raw size, which is what’s parsed by the browser and affects rendering performance.
Would also be nice to update this report’s description regarding raw vs gzipped size:
Hey @AnthumChris. Thanks for your question.
We simply report on the transfer size which may or may not be compressed.
We do mention this in the description, although only the Total Kilobytes section includes the link to the W3C page on transfer size:
The sum of transfer size kilobytes of all external stylesheets requested by the page.
Would it be helpful if we link all instances of “transfer size” in the report to make this clearer? We can also be clearer that transfer size is compression-agnostic.
I’d be open to including uncompressed stats in the report if it seems generally useful. Meanwhile those stats could be manually analyzed in BigQuery if you want to get the answers sooner.
I don’t know if it’s in the new reports but https://legacy.httparchive.org/trends.php#perCompressed already contains information about the use of compression and http/2 uses compression by default. As pure text, CSS will compress very well (>= 10x) with gzip so compression is generally only disabled for binary formats such as images, videos and fonts that are already compressed.
Performance aspects will be minimal becuse gzip can be encoded and decoded in streams. The bigger issue with CSS is that it is generally considered to be a blocking resource, ie. must be loaded before the page can render. This is something that http/2 has also addressed using multiplexing to reduce latency (very important for mobile) and load times, meaning that some older tricks such as concenation or inlining are less suitable than they used to be, though it’s worth noting that different browsers employ different loading strategies.
The net effect is to make website performance a far less arcane subject than it was a few years ago.
I think linking to “transfer size” would help users obtain a good technical understanding by reading the spec.
For an immediate, high-level understanding, adding “compressed” or “uncompressed” at the top of the page in the description, e.g. “Report: Page Weight…This report tracks the size and quantity of many popular web page resources. Sizes may reflect compressed or uncompressed stats”.
“compressed” or “uncompressed” is not found anywhere on the page, and adding that could remove all ambiguity through declarative clarity.
I think that’s a very good suggestion. Filed this issue: https://github.com/HTTPArchive/httparchive.org/issues/137
@AnthumChris are you able to submit a pull request?