Pre-fetching Flash
One of the advantages of sIFR is that the Flash files are cached on the client, saving bandwith. Except, of course, when they aren’t cached, as was pointed out on the sIFR forum. Luckily a solution was hinted at by Marc van den Dobbelsteen from Webbforce. Requesting the Flash file using a document.write() call fixes the problem. Thus, I set out on a journey through seemingly endless browser reloads and cache emptying…
Diagnosing the problem
When sIFR starts replacing elements it adds Flash movies to the document in a very short time. The browser needs to request these movies, which often have the same source. Testcases show that both Internet Explorer and Safari will stupidly request the same source for each movie, until the first request comes back. Upon reload (when the source is in the cache) no further requests are made.
Here are some log files:
# IE
“GET flash-caching/no-caching.html HTTP/1.1” 200 511
“GET flash-caching/test.swf HTTP/1.1” 200 8249
“GET flash-caching/test.swf HTTP/1.1” 206 8249
“GET flash-caching/test.swf HTTP/1.1” 200 8249
“GET flash-caching/test.swf HTTP/1.1” 206 8249
“GET flash-caching/test.swf HTTP/1.1” 200 8249
“GET flash-caching/test.swf HTTP/1.1” 200 8249
“GET flash-caching/test.swf HTTP/1.1” 200 8249
What’s interesting here is the 206 response. It seems IE isn’t happy with requesting the file and asks for it again, but this time it wants a partial file. For the five equal Flash elements on the page, seven requests are made.
# Safari 417.9.2
“GET flash-caching/no-caching.html HTTP/1.1” 200 511
“GET flash-caching/test.swf HTTP/1.1” 200 8249
“GET flash-caching/test.swf HTTP/1.1” 200 8249
“GET flash-caching/test.swf HTTP/1.1” 200 8249
“GET flash-caching/test.swf HTTP/1.1” 200 8249
“GET flash-caching/test.swf HTTP/1.1” 200 8249
Safari is a bit smarter, but still requests the same file five times.
Fixing the problem
Loading the Flash file once, before other requests are made, stops the user agent from requesting it too many times. This gives us a clue for fixing the problem. In Safari we request it through a script in the head:
new Image().src = 'test.swf';
But alas, this doesn’t work in IE. Here’s the IE code:
var head = document.getElementsByTagName('head')[0];
var node = document.createElement('embed');
head.appendChild(node);
node.setAttribute('src', 'test.swf');
You might want to remove the embed element later on, just to keep the DOM tidy. Also note that to be certain the file has been loaded, you need to load the other Flash movies after onload.
Now we have the following in our logs:
# Safari 417.9.2 Prefetching
“GET flash-caching/caching-safari.html HTTP/1.1” 200 1014
“GET flash-caching/test.swf HTTP/1.1” 200 8249# IE Prefetching
“GET flash-caching/caching-iexplore.html HTTP/1.1” 200 1057
“GET flash-caching/test.swf HTTP/1.1” 200 8249
“GET flash-caching/test.swf HTTP/1.1” 206 8249
That’s quite an improvement! Safari requests the file exactly once, while IE is stubborn and requests it twice.
Implementing the fix in sIFR 3
A slightly more specific version of the code above is used in sIFR 3. You can pre-fetch files using sIFR.prefetch('one.swf', 'two.swf', 'etc.swf'). This works pretty well, except that in Internet Explorer sIFR is allowed to kick in before the document has fully loaded.
A trade-off has to be made. Let’s say that the first time the website is loaded, sIFR is not allowed to kick in before the document is fully loaded. The next time it is, since the files no longer have to be pre-fetched. Determining whether the site is loaded for the first time is done through a session cookie. This brings us to the following situations:
- The user visits the site for the first time. The Flash movies are pre-fetched and sIFR will only kick in on page load.
- The user navigates to another page on the site. No pre-fetching takes place, the Flash movies are loaded from cache and sIFR kicks in right away.
- The user has cookies disabled. The Flash movies are prefetched for every page load, but will come from the cache after the first load. Depending on the load time for the page there are extraneous requests for the first load. sIFR does kick in right away.
Of course the cookie path and the use of the cookie itself can be configured.
This fix makes sIFR respond faster and saves bandwidth. And of course, Internet Explorer and Safari can be are a pain to work with.
This problem is now known as bug 8659 in the OpenDarwin bug tracker.
http://ediustraining.grassvalley.com/index.php
I use Mozilla firefox.
I would love to save the tutorials from the above web site, but there is only a brief cache, then it dissappears.
I have tried all sorts of “flash saving” programmes, but none of them work as there appears to be no cache.. no URL that I can identify.
I am so sorry but i do not understand your scripts. Totally my ignorance
Thanks brido
Brian Lemin | 25 March 2007, 15:56 | link
This post does not cover retrieving Flash movies from the browser cache. I’m afraid I can’t help you.
Mark Wubben | 25 March 2007, 16:42 | link
Problem with sIFR 2.0 in IE: it appends the txt as a GET variable to the url for the swf - as a result, each call is considered “unique” and the above solution will not work… src=”testmovie.swf?txt=My%20UUencoded%20Text”
So the call is the same, and unless one has all the same sifr text in each header…
Pat | 18 September 2007, 21:52 | link
Yes this has been resolved in sIFR 2.0.3.
Mark Wubben | 19 September 2007, 08:03 | link
Thanks - got us back on track.
Pat | 19 September 2007, 17:05 | link
does this solution work in safari 3?? it doesn’t seem to. I’ve checked in IE 6 and 7, the swf is only downloaded once but in safari 3 it still downloads multiple items.
buggedcom | 11 February 2008, 18:06 | link
I remember the Activity Monitor in Safari 2 showing incorrect requests, but I’ll verify Safari 3 with the server logs.
Mark Wubben | 11 February 2008, 20:36 | link
The
new Image()trick doesn’t work in Safari 3, and for IE I’ve switched to using a “ tag to load the Flash movie. This same trick also works in Safari. See the sIFR source for the full implementation.Mark Wubben | 24 March 2008, 13:28 | link