Chrome Dev Tools - "Size" vs "Content"
Asked Answered
S

5

268

When viewing information about stylesheets in the Network tab of Chrome's dev tools, one column specifies both "size" and "content":

Screenshot of dev tools with Size/Content column highlighted

Can anybody shed light on the difference between these two numbers? On some pages the numbers are close and others they are different by a considerable amount.

Sealskin answered 9/11, 2011 at 22:57 Comment(1)
According to docs, currently "by default the Requests Table displays resources with small rows; click the Use large request rows button to increase the size of each row". This would also show Content in Size column.Geraint
P
342

"Size" is the number of bytes on the wire, and "content" is the actual size of the resource. A number of things can make them different, including:

  • Being served from cache (small or 0 "size")
  • Response headers, including cookies (larger "size" than "content")
  • Redirects or authentication requests
  • gzip compression (smaller "size" than "content", usually)

From the docs:

Size is the combined size of the response headers (usually a few hundred bytes) plus the response body, as delivered by the server. Content is the size of the resource's decoded content. If the resource was loaded from the browser's cache rather than over the network, this field will contain the text (from cache).

Pittance answered 6/2, 2012 at 19:6 Comment(7)
So Size (The top number) is the actual amount of bandwidth in bytes going across the line? For example on my s/s It goes from 19KB to only 3.4KB. So 19KB is sent, but 3.4kb was loaded in memory? (Because of gzip compression I assume like you said). Wouldn't this theoretically be less data than sending over content in a websocket if it's dynamic content? Then again, that 19.4KB is still being sent though if it's cached right?.. or is it?Norland
@NiCkNewman Yes Size is the actual data size (not bandwidth btw) across the wire (Headers+Content combined). Content is the size of the inflated, uncompressed Content (e.g. if it was gziped) only (Headers excluded!).Sanjuanitasank
Dumb question, but are we using 1000 KB per MB here, or 1024?Metabolism
@ButtleButkus: Chrome, Firefox and IE/Edge all use the outdated JEDEC format, where a kilobyte is 1024 bytes and is written as KB. It would be better if they reported it either in ISO format (base 10) or write it as KiB/MiB.Choochoo
@Fx32 do you have a source for the 1024 size format? I have been trying to find an official document.Springclean
I'm using Chrome Version 60.0.3112.113 (Official Build) (64-bit) on Mac and just came across this same question. The screenshots in this question are the only way I was able to determine what the difference between the gray and black numbers are. The current version of Chrome I'm using doesn't seem to show the subheading "Content". The column just says "Size". Is there somewhere in the docs or in Chrome that explains that the gray number is "Content". I can't find it anywhere.Rezzani
Just a note that in new versions of chrome, the grey number doesn't show by default, you have to click the 'Use large request rows' button in the "View" bar up topBromal
R
56

Size is the size of response itself, and Content is the size of resource, that you are accessing.

Compare:

empty cache:

main.js GET 200 OK .. Size: 31.72KB Content: 31.42KB

cached:

main.js GET 304 Not modified .. Size: 146B Content: 31.42KB

Revenue answered 9/11, 2011 at 23:21 Comment(5)
You probably mean "Size is the size of response itself [...]" ("resource" also has a different meaning in HTTP terms).Jaclynjaco
What @Jaclynjaco said. This answer is just wrong and should not have been accepted.Plop
Yes, this is crazy talk: a 32K REQUEST!?Christmann
zomg, you had 1 year to edit my answer. Just a simple typo, obvious answer for trivial question, was answered within 23 minutes after question was asked, and accepted because it helped author to understand. No idea why so many people even google and upvote it ... so much fuss out of nothing.Revenue
It makes sense to edit answers that are basically correct, but could be improved. Your answer is sort of on the boundary, since you probably meant to say Response, but nonetheless saying the Request was 32K is misleading to anyone who didn't know enough to know it had to be completely false. (That would be the people who ask questions like this, and need correct answers about them.) Also, saying something false does not qualify as a typo. It's an error of fact, not a fat-fingering, even if you intended to say something else.Christmann
J
13

In simple terms Google article explain it as Size = Transfer size and Content = Actual size enter image description here

This is my formula based on reading various articles on this topic (and I am open to improve it further with your comments) Size = Compression(Content) + Response Header

See the image used in this article

Explanation by Google

Jillion answered 20/8, 2015 at 7:51 Comment(0)
H
6

"Use large request rows" to show both values!

If you don't see the second value (content) you need to click the "Use large request rows" button inside Chrome Network tab:

enter image description here

I found this thanks to the answer on this question here:

Chrome Devs tools - where's size and content?

Hewes answered 12/3, 2019 at 13:37 Comment(0)
E
0

Size includes response AND request info

Size is a sum of:

  1. bytes transferred for the request header
  2. bytes transferred for the response header
  3. bytes transferred for the response body

From the docs:

Inspecting the properties of an individual resource, such as its HTTP headers [note the plural, emphasis mine], content, size, and so on.

If you compare the transferSize of a performanceEntry (e.g. for the main document at https://stackoverflow.com/) with the Size in Chrome DevTools' Network tab, you'll see that the two don't match up. That is because the performanceEntry doesn't contain the size of the request header.

Screenshot of the Network tab and a logged performance entry

Euhemerize answered 27/8, 2021 at 10:52 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.