Unmarked cached assests in the Chrome Dev tool

I have web page where a few cached assets are marked as cached (i.e here is from disk cache)

cached assests marked as cached

but seeing blow screen shot , dozens of other cached assests(e.g react ,jQuery) are neither marked as 304 status code nor the cached from disk/from memory cache,etc.

As to their actual size ,they are undoubtedly from cache , how come these cached files are not marked cached?

cached assests marked as cached

Chrome developer tools disable cache on internal resource only?

I want to disable cache on any files in the target site:

http://site-domain/*

but keep cache of external resources like:

http://fonts.gstatic.com/*

http://some-cdn/*

Is it possible with Chrome developer tools?

how to download/copy the audio transcript from flash player(swf)

I have opened a presentation(flash swf) in browser which is located in server.
I am able to see the audio transcript for the presentation by clicking audio transcript button but am unable to copy/download it to save it in my local.

I would like to know how to download/copy the audio transcript. something like from browser cache or using any tool or browser extension.

Any help is appreciated

How to cache selected files with DevTools “Disabled cache” selected?

I have Chrome DevTools with “disable cache” option selected.

The thing is that I have CDN static files that I don’t want to download every time I refresh the page.

I could have them served myself for development purposes, but I have to remember to roll back changes before committing.

Basically, I’d like to tell Chrome: “Don’t cache any file, except for bootstrap.min.css and font-awesome.min.css”?

Chrome is wrong about the value of “Size” in “Chrome Devtools” > “Network”?

To me it looks like Chrome is completely messing up with “Size” in “Chrome Devtools” > “Network”.
But if someone sees the logic behind it, let me know. I will use this post to report it to Google, so it’s actually not 100% a question.

First repeat some definitions:

https://developers.google.com/web/tools/chrome-devtools/network-performance/reference

Size. The combined size of the response headers plus the response body, as delivered by the server.

On that page they also define:

RED PART IN IMAGE:

Figure 30. The total number of requests since DevTools was opened

BLUE PART IN IMAGE:

Figure 31. The total download size of requests

Anyway “since DevTools was opened” in the red part is already INCORRECT, because if you leave DevTools open and you’re making a new request, then they will still show “1 requests” and not “2 requests”. So “since DevTools was opened” must be something like: “when visiting an url”.

Now i did this:

  • Open Chrome
  • Go to DevTools
  • Go to the Network tab
  • There it’s about the column “Size”.

First i did some tests, with this file: test.html




    
    Test


    Test caching behavior ...


You can copy / paste the source code in an online tool, like this one: https://lingojam.com/ByteCounter

The amount of bytes is: 143

To be able to test the behavior in different situations, i used this htaccess file to change some things during different tests.


    RewriteEngine On
    RewriteBase /

    # Enable the rule below (remove hashtag) if you want to disble the gzip compression.
    RewriteRule ^test.html$ test.html [NS,E=no-gzip:1,E=dont-vary:1]



    
        # 1. Just press CONTROL F5 in browser to get status code 200 OK
        # After 1. press enter in address bar within 9 seconds to get back status code 200 OK (cached)
        # After 1. press enter in address bar after 9 seconds to get back status code 304 Not Modified
        Header set Cache-Control "max-age=9, public"


    
        # To avoid problems i disabled the Etag, so it's only about Last-Modified.
    FileETag None
    Header unset ETag

So let’s check some different situations. First we will check situations WITHOUT gzip compression and afterwards WITH gzip compression.

CASE 1A: GZIP COMPRESSION: NO, STATUS CODE: 200 OK

Size:               464 B (Note: "size response headers" + "Content-Length" = 321 + 143 = 464 B, actually same as "Transferred" in Firefox)
Content-Length:     143
Response headers (321 bytes in Firefox ... Chrome does not show size, so we must calculate it by ourselves)

The raw response headers are:

HTTP/1.1 200 OK
Date: Tue, 21 Nov 2017 14:25:03 GMT
Server: Apache/2.4.17 (Unix) OpenSSL/1.0.1e-fips PHP/5.6.16
Last-Modified: Tue, 21 Nov 2017 10:39:29 GMT
Accept-Ranges: bytes
Content-Length: 143
Cache-Control: max-age=9, public
Keep-Alive: timeout=1, max=100
Connection: Keep-Alive
Content-Type: text/html

Copy / paste the source code in an online tool, like this one: https://lingojam.com/ByteCounter , will give: 308 bytes

To get the real size of the response headers, you have to add some extra bytes:

amount of lines + 3 =

So in this case the outcome is 13 bytes. I still don’t understand exactly why it’s like that, see:

Where the extra 13 bytes are coming from in Chrome DevTools > Network > Size

But let’s skip that discussion, so the response headers are in total: 308 + 13 = 321

So:

Size = size response headers + Content-Length

Size = 321 + 143 = 464 and that’s exactly what Chrome is showing us, so that’s correct. Be happy with it, because this is actually the only case Chrome is right about the “Size” value.

Now go to the next case / test.

CASE 1B: GZIP COMPRESSION: NO, STATUS CODE: 304 Not Modified

Size:               360 B
Content-Length:     there is no header like that, because entity-body is coming from cache
Response headers (217 B Firefox, but no size in Chrome)

The raw response headers are:

HTTP/1.1 304 Not Modified
Date: Tue, 21 Nov 2017 14:29:46 GMT
Server: Apache/2.4.17 (Unix) OpenSSL/1.0.1e-fips PHP/5.6.16
Connection: Keep-Alive
Keep-Alive: timeout=1, max=100
Cache-Control: max-age=9, public

Copy / paste the source code in an online tool, like this one: https://lingojam.com/ByteCounter , will give: 208 bytes

Again we have to do: amount of lines + 3 bytes = 6 + 3 = 9

So in total the response headers are: 208 + 9 = 217 bytes (correct compared with value in Firefox)

So Chrome shows “Size” 360 B and that’s: 217 (response headers) + 143 (Content-Length).

IMPORTANT FOR LATER ON:

  • Google shows “Size” 360 B, while actually there are only 217 bytes delivered by the server and the rest is coming from cache.
  • Google shows “The total download size of requests” (definition see beginning of this post) also 360 B, while the total download size is actually 217 bytes and the rest is coming from cache.

So this is wrong! Now go to next test / case

CASE 1C: GZIP COMPRESSION: NO, STATUS CODE: 200 OK (CACHED)

Size:               143 B
Content-Length:     143
Response headers (0 B)

IMPORTANT FOR LATER ON:

  • Google shows “Size” 143 B, while actually there are 0 bytes delivered by the server.
  • Google shows for “The total download size of requests” (definition see beginning of this post) also 143 B, while the total download size is actually 0 bytes, because everything is coming from cache.

Now we will enable gzip compression via the htaccess file. Now realize the response HEADERS can have some extra bytes, because of the gzip compression. For example:

Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip

CASE 2A: GZIP COMPRESSION: YES, STATUS CODE: 200 OK

Size:               522 B (Note: In Firefox "Transferred" is 506 B (127 + 379). In Chrome 143 + 379 = 522)
Content-Length:     127 (same as in Firefox)
Response headers (379 bytes in Firefox ... Chrome does not show size, so we must calculate it by ourselves)

The raw response headers are:

HTTP/1.1 200 OK
Date: Tue, 21 Nov 2017 15:30:51 GMT
Server: Apache/2.4.17 (Unix) OpenSSL/1.0.1e-fips PHP/5.6.16
Last-Modified: Tue, 21 Nov 2017 10:39:29 GMT
Accept-Ranges: bytes
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Cache-Control: max-age=9, public
Content-Length: 127
Keep-Alive: timeout=1, max=100
Connection: Keep-Alive
Content-Type: text/html

Using the online tool again will give: 364 bytes

The same way as before, we have to add: amount of lines + 3 bytes = 12 + 3 = 15

So the response headers must be in total: 364 + 15 = 379. This is correct. But:

1. entity-body = 143
2. compressed entity-body (gzip) = 127

Chrome is using the first one to calculate “Size” and not the second one.

IMPORTANT FOR LATER ON:

  • Google shows “Size” 522 B, while actually there are 506 bytes delivered by the server (Chrome ignores the gzip compression).
  • Google shows for “The total download size of requests” (definition see beginning of this post) also 522 B, while the total download size is actually 506 bytes, because the entity-body is compressed, so less bytes to download.

CASE 2B: GZIP COMPRESSION: YES, STATUS CODE: 304 Not Modified

Size:               378 B
Content-Length:     there is no header like that, because entity-body is coming from cache
Response headers (235 bytes in Firefox ... Chrome does not show size, so we must calculate it by ourselves)

The raw response headers are:

HTTP/1.1 304 Not Modified
Date: Tue, 21 Nov 2017 16:08:12 GMT
Server: Apache/2.4.17 (Unix) OpenSSL/1.0.1e-fips PHP/5.6.16
Connection: Keep-Alive
Keep-Alive: timeout=1, max=100
Cache-Control: max-age=9, public
Vary: User-Agent

Using the online tool again will give: 225 bytes

The same way as before, we have to add: amount of lines + 3 bytes = 7 + 3 = 10

So the response headers must be in total: 225 + 10 = 235. This is the same as Firefox is showing as size of the response headers.
In this case the “Size” Chrome is showing, is: 378 B. This is 235 + 143 = 378.

IMPORTANT FOR LATER ON:

  • Google shows “Size” 378 B, while actually there are 235 bytes delivered by the server (rest is coming from cache).
  • Google shows for “The total download size of requests” (definition see beginning of this post) also 378 B, while the total download size is actually 235 bytes, because the entity-body is coming from cache.

CASE 2C: GZIP COMPRESSION: YES, STATUS CODE: 200 OK (CACHED)

Size:               143 B
Content-Length:     143
Response headers (0 B)

IMPORTANT FOR LATER ON:

  • Google shows “Size” 143 B, while actually there are 0 bytes delivered by the server.
  • Google shows for “The total download size of requests” (definition see beginning of this post) also 143 B, while the total download size is actually 0 bytes, because everything is coming from cache.

So with the definition Google is giving us, actually almost all the values are wrong. Maybe we can make our own definition which matches the results?

 Size = A + B 
 A = Size of uncompressed entity-body. And it does not matter if entity-body is coming from cache or if entity-body is compressed (gzip) ... it always has the same value
 B = Bytes transferred by response headers.

If Google would define it like that, then the definition matches some results.

But with “The total download size of requests” they are showing for example “378 B transferred” (304 status code), while it includes the size of the entity-body. The entity-body is coming from cache, so there are no extra bytes transferred / downloaded because of that.

So it’s also not working to use a definition like that.

Actually it’s just all incorrect!

What would be the right way? This:

Size = total bytes transferred with the request
So:
Size in case of 200 OK:            Content-Length + Size response headers
Size in case of 304 Not Modified:  Size response headers
Size in case of 200 OK (cached):   0

This is actually the same like their definition of “Size”:

Size. The combined size of the response headers plus the response body, as delivered by the server.

So the DevTool is just showing the wrong values. It’s completely a mess:

  • In case of “200 OK” and gzip compression, Chrome takes the uncompressed size instead of the compressed size.
  • In case of “304 Not Modified”, Chrome takes also the size of the entity-body, while it’s not delivered by server, but from cache.
  • In case of “200 OK (cached)”, nothing is delivered by the server, so Google must show 0, but Google shows the size of the uncompressed entity-body.

Possible to view yesterday’s version of a hopefully cached JavaScript file in Chrome?

Using Chrome 61. iCloud Drive mysteriously seems to have reverted a JavaScript file I worked a long time on to a previous version (before I did a git commit). I had viewed this file repeatedly in Chrome (srced from an html page). Is it possible Chrome still has a copy of this somewhere?

Any other way I could possible recover this file? iCloud Drive doesn’t appear to have revision history as I thought (I can only recover deleted files).