Current time: 12-12-2017, 04:29 PM Hello There, Guest! (LoginRegister)

Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
IE8 == Worse Performance?
06-26-2010, 05:00 AM (This post was last modified: 06-26-2010 05:10 AM by jarrod1937.)
Post: #1
IE8 == Worse Performance?
Considering the majority (60%) of our visitors still use browsers that have a 2 connection limit per domain, i've been optimizing for those first. However i've start testing for the other end (40%) who use IE8 that allows for a max of 6 (for http 1.1) connections per domain.
Normally this would mean faster performance, however each test i've run ends up producing worse results:
http://www.webpagetest.org/result/100625...1/details/

If you look at the connection view its spacey like crazy. Why am i getting worse results? Is there a way i can maximize performance for both 2 and 6 connections?
I should add that the desktop version of pagetest says what you'd expect, the opposite. IE in IE8 mode (using web developers toolbar) tends to be quite a bit faster than in IE7 mode.
Find all posts by this user
Quote this message in a reply
06-26-2010, 12:55 PM
Post: #2
RE: IE8 == Worse Performance?
Want some fun? Try firefox 3.6 which bumped connections up to 16 - YIKES!

IE7 mode for IE8 is for the rendering engine, not the network connections (to the best of my knowledge).

One thing you might try doing (if possible) is moving that inline script that comes right after the css. Not sure if the browser would start downloading images earlier if it didn't hit that script but it's worth testing.

Aside from that the only other suggestion I have (if you feel like getting crazy) would be to deliver the images directly in the css (or in an external resource file). mhtml for IE and Data URI's for the browsers that support them. It gets more complicated because you're having to do per-browser logic but you'll see some crazy-fast speedups as all of the images will be downloaded in one request (and without resorting to sprites - regular images).
Visit this user's website Find all posts by this user
Quote this message in a reply
06-26-2010, 02:36 PM
Post: #3
RE: IE8 == Worse Performance?
Hey Patrick,

Could you elaborate on how to create a resource file like the one you mentioned?

I am very interested in reducing the number of requests for images and I am sure other people would be too.

Thanks in advance for any information on this.

Sincerely,
Travis Walters
Find all posts by this user
Quote this message in a reply
06-26-2010, 11:45 PM (This post was last modified: 06-26-2010 11:50 PM by jarrod1937.)
Post: #4
RE: IE8 == Worse Performance?
(06-26-2010 12:55 PM)pmeenan Wrote:  Want some fun? Try firefox 3.6 which bumped connections up to 16 - YIKES!
Wow, didn't know that, thats a tad excessive in my opinion.

(06-26-2010 12:55 PM)pmeenan Wrote:  IE7 mode for IE8 is for the rendering engine, not the network connections (to the best of my knowledge).
I could have sworn it also changed the amount of concurrent connections. I'll run another test later to be sure.

(06-26-2010 12:55 PM)pmeenan Wrote:  One thing you might try doing (if possible) is moving that inline script that comes right after the css. Not sure if the browser would start downloading images earlier if it didn't hit that script but it's worth testing.
Which script exactly? The only thing i see is the lt ie7 conditonal statement, can those cause image downloading to be blocked? Keep in mind the link in the test goes straight to our old, currently live, site. On the old site there is some inline javascript right after the css, but it has been removed in our new site (the one in that test).

(06-26-2010 12:55 PM)pmeenan Wrote:  Aside from that the only other suggestion I have (if you feel like getting crazy) would be to deliver the images directly in the css (or in an external resource file). mhtml for IE and Data URI's for the browsers that support them. It gets more complicated because you're having to do per-browser logic but you'll see some crazy-fast speedups as all of the images will be downloaded in one request (and without resorting to sprites - regular images).
Yeah, i've read up on css data embeding, but considering it only works on IE8 (for the IE browser family), it is not worth the extra development effort to create an maintain such a system. I'm sticking with css sprites for now.

(06-26-2010 02:36 PM)green-watch.org Wrote:  Hey Patrick,

Could you elaborate on how to create a resource file like the one you mentioned?

I am very interested in reducing the number of requests for images and I am sure other people would be too.

Thanks in advance for any information on this.

Sincerely,
Travis Walters

http://www.websiteoptimization.com/speed...ne-images/

Or you can google:
"css data embedding"
"css data URI"
...etc
Find all posts by this user
Quote this message in a reply
06-27-2010, 02:15 AM
Post: #5
RE: IE8 == Worse Performance?
(06-26-2010 11:45 PM)jarrod1937 Wrote:  Which script exactly? The only thing i see is the lt ie7 conditonal statement, can those cause image downloading to be blocked? Keep in mind the link in the test goes straight to our old, currently live, site. On the old site there is some inline javascript right after the css, but it has been removed in our new site (the one in that test).

This right at the end of your head:

<script type="text/javascript" language="JavaScript">
function popUp(URL) {
day = new Date();
id = day.getTime();
eval("page" + id + " = window.open(URL, '" + id + "', 'toolbar=0,scrollbars=0,location=0,statusbar=0,menubar=0,resizable=1,width=730,h​eight=618,left = 275,top = 203');");
}</script>


(06-26-2010 11:45 PM)jarrod1937 Wrote:  Yeah, i've read up on css data embeding, but considering it only works on IE8 (for the IE browser family), it is not worth the extra development effort to create an maintain such a system. I'm sticking with css sprites for now.

Actually, it's not as well known but IE supports Multi-part documents (MHTML). Not sure how far back the support goes but I know at least 6, 7 and 8 all support it.

Here is a reasonably good write-up on it: http://www.phpied.com/mhtml-when-you-nee...and-under/

Make sure to read through the comments though as there are a few tweaks you need to consider on Vista.

The great thing about it (and data uri's) is that you can use it for your product images as well, not just the kinds of things you normally sprite.
Visit this user's website Find all posts by this user
Quote this message in a reply
06-27-2010, 05:20 AM
Post: #6
RE: IE8 == Worse Performance?
Hey There,

http://en.wikipedia.org/wiki/Data_URI_scheme

Looks like IE7 does not support the data URI concept.

It also looks like images that use this concept are not cached so they have to keep being downloaded each time.

IE8 limits the size to a URL to a maximum length of 32 KB.

It seems like it may be more trouble than its worth.

Sincerely,
Travis Walters
Find all posts by this user
Quote this message in a reply
06-27-2010, 06:19 AM
Post: #7
RE: IE8 == Worse Performance?
Not data URI's but MHTML (MHT) packages - haven't heard of a problem with sizes but you'd probably only want to do it with smaller images anyway (like thumbnails).

Yes, it's a lot of work and not for the queasy (It's one of the more extreme optimizations). There are solutions that can do it for you automatically but they are all pay solutions to the best of my knowledge. I know there are some solutions coming out soon where you don't have to control the hosting though so that could be an option (I prefer controlling everything myself but that's just me).
Visit this user's website Find all posts by this user
Quote this message in a reply
06-27-2010, 07:13 AM
Post: #8
RE: IE8 == Worse Performance?
Hey There,

http://en.wikipedia.org/wiki/MHTML

According to the documentation, it looks like few browsers support MHTML and those that do support it do not have a standardized way of doing so.

Opera will work version 9.0 onwards. Firefox requires a MHT plugin for users to be able to read and write MHTML pages. Safari does not support MHTML since version 3.1.1 onwards. Konquerer does not support MTHML since 3.5.7 onwards. Google Chrome took out the ability to view MHTML files since March 2010. It looks like it will work with Internet Explorer 5 onwards. However, IE may have problems saving MHTML files if they contain scripts.

Sincerely,
Travis Walters
Find all posts by this user
Quote this message in a reply
06-27-2010, 10:32 AM
Post: #9
RE: IE8 == Worse Performance?
Sorry, I wasn't clear (and this is why it's not for the fainthearted)...

To inline images you basically need to have 3 code paths depending on the user agent string:

1 - No embedding support - Reference the images as usual
2 - Data URI support - Embed appropriate images as data URI's
3 - MHTML support - Embed or reference the images in a MHTML package

StrangeLoop has an accelerator appliance that can do it automatically (along with all of the other best practices and a few other extras). They also just released it as a no-install in-the-cloud version: http://www.strangeloopnetworks.com/produ...r-service/
Visit this user's website Find all posts by this user
Quote this message in a reply
06-27-2010, 03:22 PM
Post: #10
RE: IE8 == Worse Performance?
Greetings,

This sounds very interesting. I sent them a few questions.

I am looking for a few URL examples that use their service to see what the test results would look like.

Their documentation says that resources can be sent to a user before the html page gets processed.

I do not see any pricing information for their service. I asked them about this.

Do they have any competitors with the same type of service that you know of?

http://www.strangeloopnetworks.com/produ...-your-cdn/

What is ADC stand for? I see CDN + ADC reference in the link above.

I feel like such a newb sometimes with all of these questions but I guess you have to learn some how Smile

Thanks for all the help Patrick and everybody else that helps out here.

Sincerely,
Travis Walters
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)