No description, website, or topics provided.
Switch branches/tags
Nothing to show
Clone or download

README.md

Caching and iframes

Filament Group

We’re doing some testing around browser caching and assets requested by the “host” page as well as multiple iframes within that page, so I figured we may as well bring enough share with the rest of the class. More data to come.

Total Potential Requests (8):

  • index.html (340 bytes)
    • jquery-1.10.2.js (266KB)
    • frame1.html (226 bytes)
      • jquery-1.10.2.js (266KB)
    • frame2.html (226 bytes)
      • jquery-1.10.2.js (266KB)
    • frame3.html (226 bytes)
      • jquery-1.10.2.js (266KB)

Results:

Empty Browser Cache Primed Browser Cache
Chrome (Current) 8 requests, 268KB transferred 6 requests, 223 bytes transferred
Safari 6.1 8 requests, 1068KB transferred 6 requests, 268K transferred
iOS7 Safari 8 requests, 1068KB transferred 6 requests, 535KB transferred

These totals show WebKit-based browsers—iOS most notably—does not fetch the iframes’ contents from the cache on the first page load, despite having loaded the same file in the head of the index.html.

Given that Firefox/Firebug are somewhat unique in how they reports total aggregated requests, we’ll do a more granular comparison between Chrome and iOS WebKit here.

Chrome (Current)

Empty Cache

Totals

8 requests 268KB transferred

Request Details
  • index.html (340 bytes)
    • jquery-1.10.2.js (266KB)
    • frame1.html (226 bytes)
      • jquery-1.10.2.js (from cache)
    • frame2.html (226 bytes)
      • jquery-1.10.2.js (from cache)
    • frame3.html (226 bytes)
      • jquery-1.10.2.js (from cache)

On an empty cache, Chrome fetches the index page and iframe contents as expected. Chrome immediately caches the script file linked from the index page and makes it available from the cache when requested by the iframes’ contents.

Primed Cache

Total Transfer

223 bytes transferred

Request Details
  • index.html (223 bytes)
    • jquery-1.10.2.js (from cache)
    • frame1.html (from cache)
      • jquery-1.10.2.js (from cache)
    • frame2.html (from cache)
      • jquery-1.10.2.js (from cache)
    • frame3.html (from cache)
      • jquery-1.10.2.js (from cache)

On an primed cache, Chrome returns “304: Not modified” for the index page. Data transferred while checking for “modified” status is the likely reason for the transfer side being smaller than the page itself, as it seems the entire page doesn’t need to be parsed in order to perform said check. All other assets are served from the cache, as expected.

iOS7 Safari

Empty Cache

Total Transfer

1068KB transferred

Request Details
  • index.html (340 bytes)
    • jquery-1.10.2.js (266KB)
    • frame1.html (226 bytes)
      • jquery-1.10.2.js (266KB)
    • frame2.html (226 bytes)
      • jquery-1.10.2.js (266KB)
    • frame3.html (226 bytes)
      • jquery-1.10.2.js (266KB)

iOS Safari does not make the external asset available from the cache during subsequent requests within the iframes on the index page, resulting in a quadrupled transfer size.

As Chrome is known to be especially aggressive about caching, this should be regarded as a systemic issue and not a browser quirk unique to iOS. For the purposes of these results iOS Safari stands in for the vast majority of browsers, particularly mobile ones.

Primed Cache

Total Transfer

535KB transferred *

Request Details
  • index.html (340 bytes)
    • jquery-1.10.2.js (266KB)
    • frame1.html (226 bytes)
      • jquery-1.10.2.js (from cache)
    • frame2.html (226 bytes)
      • jquery-1.10.2.js (from cache)
    • frame3.html (226 bytes)
      • jquery-1.10.2.js (from cache)

On a primed cache, iOS7 Safari makes a fresh request for the index page and iframe pages, but fetches each linked asset from the cache. The cache requests are only reported in the total request count as two: one for the index page, and one for all of the iframes. The transfer size is reported as 535KB based on these two asset requests, despite being fetched from the cache.