The Performance Impact of META REFRESH

Some sites will utilize the META REFRESH directive to perform a client-side redirection. In general, this should be avoided in favor of other redirection types, for instance, a server-side redirection (HTTP/3xx) or by using JavaScript. Using META REFRESH creates a potential performance problem in IE because IE will conditionally revalidate resources when navigating to the target URL.

For instance, when I revisit by typing the address into my address bar, IE issues 6 unconditional HTTP requests (to retrieve the resources which were marked as uncacheable on my prior visit). In contrast, if I use a META REFRESH to redirect to, like so:

<meta http-equiv=”refresh” content=”3;url=” />

… IE issues 6 unconditional HTTP requests and 33 conditional HTTP requests to revalidate the page’s resources.

Interestingly, if your traffic is configured to go through a proxy, IE will also add a Pragma: no-cache header to the outbound requests generated from the META REFRESH. However, the If-Modified-Since and If-None-Match headers, if any, are not removed, so unless the proxy or server respects the Pragma directive, 304s may still be returned.

Now, one scenario where using META REFRESH may prove unavoidable is the case where you want to notify the user that your website requires JavaScript but scripting is disabled. That pattern looks like this:

    <meta http-equiv=”refresh” content=”3;url=” />

Since browsing with script disabled is fairly uncommon, that scenario probably isn’t much of a problem for real-world sites.

Until next time,


Comments (17)

  1. Another downside is that in IE you can set it to not allow Meta Refreshes like I have.

  2. steveg says:

    Great blog. Please keep posting regularly! Some random "history of IE", or "crazy bugs I’ve seen" stories would be nice if they’re geeky — implementation details of pretty much anything would be appreciated.

    Any chance of implementing an Internet for the < 25 and the >= 25? 🙂

  3. ieblog says:

    Thanks, SteveG– I blog in a bunch of places (e.g. /Fiddler) but I have a good-sized backlog to work through here.

    Bill– It’s a fine point, although it should be noted that such a configuration change is so uncommonly made that it’s not a significant downside.

  4. EricLaw [MSFT] says:

    SteveG: How about a "Random people of IE"?

    There are lots of really interesting people working on IE. Zeke, one of our developers, is one of them. His profile was written up on the Microsoft Jobs blog a while ago and it’s so wild that I’d think it fiction it if I didn’t know the guy.  🙂

  5. If you are interested in IE background information – follow these links to some of the blogs we did on that topic:

    CSS Expressions:

    CSS Selectors:

    Understanding IE Rendering Behavior:

  6. Rob^_^ says:

    Eric! Please validate your markup!


    <meta http-equiv=”refresh” content=”3;url=“ />


    is not valid. In fact it is causing problems for Facebook users with IE8.

  7. EricLaw [MSFT] says:

    @Rob! It’s not my markup. I’m not sure what you want me to do about it! It’s a pattern that I’ve seen sites use, probably because it seems to work (in IE, Firefox, Chrome, Safari, and Opera, at least).

    What “problems” does this cause specifically?

  8. Rob^_^ says:

    Eric, <noscript> is not valid in the <head> block.

    Here is the Tidy Validator output from FX when is loaded.

    line 11 column 10 – Warning: <noscript> isn’t allowed in <head> elements

    line 4 column 1 – Info: <head> previously mentioned

    line 11 column 10 – Warning: inserting implicit <body>

    line 11 column 21 – Warning: <meta> isn’t allowed in <noscript> elements

    line 11 column 10 – Info: <noscript> previously mentioned

    As you can see FX makes assumptions and tries to insert an explicit <body> block, and then ignores the ‘real’ <body> tag and rejects the meta tags that follow the <noscript> block.

    To reproduce the issue with, Add FB to your Restricted Sites (or disable Active Scripting in the Internet Zone) and then navigate to in IE. The scripted version of their homepage will load without the redirect to the ?_fb_noscript=1 page.

    What I have seen in the PNG’s is that some OP’s complain that they are unable to login to FB. The solution is ALWAYS ‘Reset all zones to default’. Invariably novice users will try tweaking the default security zone settings in the vain hope of fixing things and then go on to other web sites forgetting about the changes they have made.

    So. <noscript> can’t be placed in the <head> block and if you place the <noscript><meta…..></noscript> block within the <body> tag, XP and Vista versions of IE8 will fall over because a <meta> tag has been placed illegally within the <body> tag. This was corrected for Win7/IE8 which will correctly ignore the <meta> tag that is placed within the <body> tag.(See my "Browser chokes when feed junk" ticket at connect).

    Since active scripting is disabled and a <meta> tag within the body block is no valid, we cannot use a meta redirect or scripting to change the current .location the only option is to display a message to the user from within the <noscript> block.

    Here is my template start of my <body> tag from an project.


    <noscript><div id="divnoscript"><h1>Scripting is disabled.</h1></div></noscript>

    <form ….

    I style the divnoscript to be absolutely positioned and to overlay the full content of the page with a transparency to prevent them from trying to navigate the site without Active Scripting enabled.


  9. Rob^_^ says:

    @Eric, I was not trying to hold you up. Understandably common design patterns are assumed to be well tested and solid. Unfortunately, this may not always be the case, particuarly when we are dealing with new browser versions and the assumptions made in their error handling and correction. My response is in the vain hope that your endoresment here of the design idiom will not be adopted by other web developers.

    It would be nice if the FB developers corrected their pages also.


  10. <<<XP and Vista versions of IE8 will fall over >>>

    I’m aware of no such issue. IE8 on XP has no problem at all with redirecting to the “you need script” page from or the Facebook homepage when Scripting is disabled.

    <<your endoresment here >>>

    There’s no such endorsement, I’m merely pointing out that there are sites that do this.

    <<< Add FB to your Restricted Sites >>>

    There’s your issue: That’s not a valid test case, because the Restricted Sites zone also disables META REFRESH, so while the NOSCRIPT tag runs just fine, the META REFRESH doesn’t do anything.

  11. Rob^_^ says:

    Hi, Thanks for clearing that up.

    There’s your issue: That’s not a valid test case, because the Restricted Sites zone also disables META REFRESH, so while the NOSCRIPT tag runs just fine, the META REFRESH doesn’t do anything.

    Ok… The validators at Tidy, W3c and Visual Studio still flag the idiom as invalid… but that is not the first time. Regards.

  12. ken says:

    …and I thought you were going to point out that a 3xx redirect doesn’t require a response body, only the headers (which saves bandwidth and client resources for parsing/rendering, not to mention lots of perceived time by the user).

  13. ieblog says:

    Ken: Indeed, that’s true, although the delta there would be in the millisecond range. It’s the cache-bypass that’s the killer.

  14. Wurst says:

    Interesting, the NoScript extension for Firefox has an option for blocking meta-refresh redirection in noscript blocks.

  15. EricLaw [MSFT] says:

    Yes, but i'm not sure why that's relevant?

  16. EricLaw [MSFT] says:

    It was recently noted that META REFRESH has another side effect which some folks consider desirable– it drops the HTTP Referer header (

  17. Patrick says:

    Does the current version of IE still behave this way?

    [EricLaw] Observing the network traffic when loading my test page linked above with Fiddler shows that IE11 on Windows 8.1 still behaves this way.

Skip to main content