Suggestions for more speed - Printable Version
+- WebPagetest Forums (http://www.webpagetest.org/forums)
+-- Forum: Web Performance (/forumdisplay.php?fid=3)
+--- Forum: Discuss Test Results (/forumdisplay.php?fid=4)
+--- Thread: Suggestions for more speed (/showthread.php?tid=10691)
Pages: 1 2
Suggestions for more speed - doc_uk - 03-05-2012 10:35 AM
Results at http://www.webpagetest.org/result/120304_XT_3F5CK/1/details/
The animation is the bugbear I want to work on. At the moment I have it set for IE7 or less to pull the separate images, and IE8+, Chrome and Firefox have the images embedded in the html in base64.
I think I can css sprite a few images, and have just come across Helium (https://github.com/geuis/helium-css) so will be trying this to trim the CSS down. Is there a tool for analyzing js the same way?
Can anyone suggest anything else to improve the results? the TTFB for the images seems slow to me, and I occasionally get a 1sec+ TTFB for favicon.ico
RE: Suggestions for more speed - Marvin - 03-05-2012 10:26 PM
The Base64 images is an interesting idea. Have you done some before/after tests comparing page load times? Has the embedding of images in html improved or worsened the overall page load time?
I played with Base64 images at one point, too, but in my case it slowed the load time. I suspect this trick may be useful for just very small images, but not useful for larger jpegs.
RE: Suggestions for more speed - SWortham - 03-06-2012 02:05 AM
Well you've already mentioned CSS sprites. It'd be nice if you could make CSS sprites out of just about everything. I understand the difficulty though. When you're dealing with images from a product database like this it's not really practical to use CSS sprites for the products, for example.
However, several of your PNGs/GIFs can still be combined.
Check out this sprite from StackOverflow for inspiration...
Then I'd suggest moving as much as you can to a CDN. CDN's are very cheap nowadays. In addition to the performance you'll gain in terms of reduced global latency, you'll have a few other benefits:
1. Moving static content to a cookieless domain helps since the request no longer contains a cookie, therefore reducing request payload & latency.
2. Serving up content from a 2nd domain allows the browser to download more assets in parallel.
3. Using a CDN for your static files frees up your server to just focus on the dynamic content.
Those 3 benefits all pay off. If you look at the graph along the bottom for bandwidth usage, you can see drastic dips in bandwidth. This is due to the inherent latency of so many files being downloaded as well as the browser's limitation of only being able to download 6 files simultaneously from a single host.
Oh, and as for embedding the base64 images in HTML, I'd be worried about how the repeat view time is affected. Sure enough, your repeat view time is only a couple tenths of a second faster than the first view. I'd be tempted to just serve the images individually (and set appropriate max-age headers). Your first page view time might be slightly slower. But the "start render" time should improve, and the repeat view time will definitely improve.
RE: Suggestions for more speed - doc_uk - 03-06-2012 05:19 AM
Thanks for replies
Base64 images - embedding them in the page is about 1/3 worse than the images as std, but don't forget the pages are then gzipped down the line - try the same test for IE7 to see it run with 8 separate images and the results - at least 2 seconds worse, see http://www.webpagetest.org/result/120305_AC_3FJT8/
I'd actually tried the animation as both background and foreground css sprites, but it didn't play nice for me - I couldnt get the images not frontmost to scale properly.
The only other idea I have had is to throw up a static snapshot image of the animation so that there is something there, then lazy load the whole animation on top of it after the page has loaded.
CDN - I have set up 2 subdomains - http://www.cdn1. and http://www.cdn2. - but because the pages have a base ref in the top, then a lot of the images are loading using one of the subdomain paths, as though they are being carried on thru the page from the last subdomain reference. Ideas anyone?
Static content - are js, css and images classed as static content? The pages are all dynamic php, except a single lazy load layer in the footer on the index page
RE: Suggestions for more speed - SWortham - 03-06-2012 05:37 AM
(03-06-2012 05:19 AM)doc_uk Wrote: Base64 images - embedding them in the page is about 1/3 worse than the images as std, but don't forget the pages are then gzipped down the line - try the same test for IE7 to see it run with 8 separate images and the results - at least 2 seconds worse, see http://www.webpagetest.org/result/120305_AC_3FJT8/This isn't actually a fair test. IE7 could only download 2 files simultaneously from a single host. That's why the waterfall looks so different. There aren't as many overlapping downloads. As a result, most websites you visit in IE7 are going to be substantially slower to load than in IE8 (which allows 6 simultaneous downloads per host).
(03-06-2012 05:19 AM)doc_uk Wrote: CDN - I have set up 2 subdomains - http://www.cdn1. and http://www.cdn2. - but because the pages have a base ref in the top, then a lot of the images are loading using one of the subdomain paths, as though they are being carried on thru the page from the last subdomain reference. Ideas anyone?What are you using the base href for? Is it possible to do without it?
The way I've done this in the past is like this...
1. Move my CSS file to cdn.[mydomain].com/screen.css and update my href to point to that URL.
3. Use relative links to images inside screen.css. e.g. url(sprites.png)
(03-06-2012 05:19 AM)doc_uk Wrote: Static content - are js, css and images classed as static content?Yes, that would all be classified as static content.
RE: Suggestions for more speed - Marvin - 03-06-2012 06:06 AM
Quote:Base64 images - embedding them in the page is about 1/3 worse than the images as std, but don't forget the pages are then gzipped down the line - try the same test for IE7 to see it run with 8 separate images and the results - at least 2 seconds worse, see http://www.webpagetest.org/result/120305_AC_3FJT8/
But that's not a fair comparison because IE7 is able to do only 2 parallel downloads per domain while "modern" browsers can do up to 6 of them. That's likely the (main?) reason for your worse test result using IE7.
RE: Suggestions for more speed - SWortham - 03-06-2012 06:33 AM
(03-06-2012 06:06 AM)Marvin Wrote: Doc,That's what I said.
RE: Suggestions for more speed - Marvin - 03-06-2012 07:04 AM
That's the result of me opening my browser to read a post, and then, a half an hour later getting around to replying, but failing to refresh the page first to check if a new reply has been posted since. :-)
RE: Suggestions for more speed - doc_uk - 03-06-2012 07:21 AM
@Marvin + SWortham
Point taken - I had images with less content (and thus less kb) initially when I set this animation up. I've just tried it on our test site for IE8 with the animation as 8 separate images rather than base64, the results come in about the same times for the document complete time. However what has stayed from the initial testing I did when setting up the animation is the improved start render time - 1.9 seconds for the base64 images page as opposed to 3.1 seconds for the 8 images, both on IE8.
The subdomains are symlinked to the main domain at the moment. I am currently loathe to take out the base tag in the header because it's supposed to be good SEO. I'll do some more playing on this to see if I can stop cookies on the subdomain that is symlinked.
RE: Suggestions for more speed - SWortham - 03-06-2012 08:33 AM
(03-06-2012 07:21 AM)doc_uk Wrote: @Marvin + SWortham
Also I don't know if you've run into this problem. But after StackOverflow was launched Jeff Atwood soon regretted launching with the stackoverflow.com domain. By not including a www, the cookies are shared across the entire domain by default. Therefore introducing a cdn.stackoverflow.com subdomain wouldn't actually be a cookieless domain. But if your entire site is sitting on 'www', then you can introduce a new subdomain 'cdn.[mydomain].com' and it will be cookieless as long as you never explicitly create cookies or serve dynamic content from that subdomain.