| 7:46 pm on Jan 13, 2008 (gmt 0)|
This is geat information tedster, thank you for the post!
| 7:53 pm on Jan 13, 2008 (gmt 0)|
I'm not 100% sure that I agree with all of the findings for the site I just tested it against, but it does give a lot of food for thought in improving design methods. There is one change that I am making immediately, one that I had long forgotten.
I think I found a minor bug or two.
I have a main CSS file which further imports several other CSS files. They are all reported as being outside the document <head> but they are not (as far as suggesting they are in the <body> or somesuch).
On the page listing the objects that don't have an expires header, or one that isn't set far enough in the future, the date format is the default US m/dd/yyyy style and not the one that I have selected in the main Windows options.
I am not sure why this is listed as the second object in the list: http://www.domain.eu/robots.txt#resize_iframe%26remote_iframe_0%26102$.
I am going to have to look up what "minify" a JS file means.
Pfffft. I got an "F".
I must check why GZIP isn't on for this site, and set up the expires headers correctly.
| 8:17 pm on Jan 13, 2008 (gmt 0)|
I made a post about this about a month or so ago - after implementing all those changes, my crawl rate went much higher.
If you look in google webmaster tools, and check out Tools - Set Crawl Rate you'll see some interesting graphs including time spent downloading a page.
Before the changes I had huge spikes and a very erratic graph - now the graph shows the average time cut down in half, and almost totally steady.
Adsense and other revenue went up and traffic as well.
Needless to say, implementing some of those changes was probably the best thing I did for my site all year. Take some time and read the post or watch the video and work on it.. Some of the changes only take a few minutes to do.
| 9:48 pm on Jan 13, 2008 (gmt 0)|
If watching the whole video is too much (I would recommend it though), there is an excellent text summary of the contents of the video available on the Yahoo Developer Network site: Best Practices for Speeding Up Your Web Site [developer.yahoo.com]
Seeing as he mentioned it, I would recommend madmatt69's thread 20% gain in adsense income after speeding up site [webmasterworld.com] which has some good tips for increasing speed with a PHP-driven site.
|I am going to have to look up what "minify" a JS file means |
|Minification is the practice of removing unnecessary characters from code to reduce its size thereby improving load times. When code is minified all comments are removed, as well as unneeded white space characters (space, newline, and tab). |
| 10:02 pm on Jan 13, 2008 (gmt 0)|
Rule 14 needs to be used with care.
The example uses an extra parameter on a URL to show the date the information was last changed. This could potentially lead to duplicate content issues if those URLs should ever be indexed.
Although eTags are set up for all files, I got an F for that too. Not sure why.
| 10:14 pm on Jan 13, 2008 (gmt 0)|
Agreed, g1 - in fact, ALL of these points need to be used as suggestions only. Implement them with intelligence and only where they make real sense in any specific website. But I must confess that many of these issues I never even think about a lot of the time. So just raising our awareness is already an important step.
I've seen cases, for instance, where using a second host for images actually hurt speed - for reasons that were difficult to address in that particular configuration. But just knowing about the issue and the options is a good thing. Getting a 40% improvement in website front end speed can be a major factor in online success, and such improvements are often well within reach.
| 10:26 pm on Jan 13, 2008 (gmt 0)|
Another point - in the video, Souders is not talking about changing the visual design at all but only working within how a given design is coded. But if you have the chance to work directly with designers, informing them of the constraints certain design elements force on a site, you can often get even bigger gains.
When a responsible designer understands that their design is more than commercial art, but can directly influence business success from a technical direction, they are often happy to contribute to the overall achievement. I had one such conversation with a designer, and the next version of the site abandoned such visual frills as rounded corners, gratutious gradients and the like. This made a real difference in load times and site stats altogether, and the site still looked really sharp.
(Interesting side note - on January 7, 2008
Steve Souders left Yahoo for Google [blog.wired.com].)
| 10:48 pm on Jan 13, 2008 (gmt 0)|
I need to go read more stuff. One site recommends turning off eTags not adding them.
I'm getting into some areas of Apache that I haven't meddled with before.
[edited by: tedster at 3:53 pm (utc) on Jan. 14, 2008]
| 11:06 am on Jan 14, 2008 (gmt 0)|
I am not sure if this point is covered here, but removing the all the returns on the html source code reduces a significant amount of size of the page. The entire html code would lose its coding structure and becomes barely readable, but it somehow was great in reducing the size.
| 11:15 am on Jan 14, 2008 (gmt 0)|
| 2:57 pm on Jan 14, 2008 (gmt 0)|
A big issue in all my pages is 'get a CDN' - now at which level is that really feasable? Are there any of you who are using a CDN - what are the costs?
| 4:07 pm on Jan 14, 2008 (gmt 0)|
|g1smd wrote: "One site recommends turning off eTags not adding them." |
The Yahoo help page also recommends turning off eTags in some situations, but not in others. The wording in the rule - "configure eTags" - is a bit ambiguous and further reading illustrates why.
|If you host your web site on just one server, this isn't a problem. But if you have multiple servers hosting your web site, and you're using Apache or IIS with the default ETag configuration, your users are getting slower pages, your servers have a higher load, you're consuming greater bandwidth, and proxies aren't caching your content efficiently. |
If you're not taking advantage of the flexible validation model that ETags provide, it's better to just remove the ETag altogether.
Also, using eTags does give you a lower "grade" with the YSlow tool.
| 5:51 pm on Jan 14, 2008 (gmt 0)|
this is excellent - but, forgive me, since I'm focused on conversion (visitors / action) and since virtually everything I've learned about SEO (here and elsewhere) focuses on increasing the numerator -- where is the thread that writes about best practices for the denominator?
| 5:55 pm on Jan 14, 2008 (gmt 0)|
|1. Make Fewer HTTP Requests |
Here's some impressive statistics...
Google - 2 http requests at 14,438k total.
WebmasterWorld - 4 http requests at 59,139k total.
Live - 5 http requests at 22,640k total.
And, not so impressive?
Yahoo! - 77 http requests at 353,113 total.
CNN - 262 http requests at 712,377k total.
For the CNN site, 175 of those requests are CSS background images.
| 6:23 pm on Jan 14, 2008 (gmt 0)|
|He focuses instead on the front end, the user's experience within their browser. |
Then Steve should be FIRED because he's failing miserably.
Likewise the new Yahoo Mail is slower than hell, reverted back to the original format, so on and so forth.
Didn't say the changes were neat, but they quickly made a still useful old Thinkpad next to useless where Yahoo is concerned.
Yup, I'll sit right down and waste an hour learning how I too can mess up my site the same way.
Thanks for the tip Tedster! ;)
| 11:07 pm on Jan 14, 2008 (gmt 0)|
Actually Bill, Souders says several times that he doesn't get involved in design, including decisions on functionality - his goal is to serve a given design as fast possible.
You shouldn't take Yahoo's abysmal speed as an indicator of Souder's expertise.
| 11:59 pm on Jan 14, 2008 (gmt 0)|
I have been using yslow for awhile now. I would say that it is accurate to about 99%. I however have hit a couple of sites that it didn't do a good job on.
| 12:23 am on Jan 15, 2008 (gmt 0)|
Yeah, I'm confused about eTags. The tool says:
These URLs have an eTag:
The only URLs that do not have the tag, are those for the various parts of the Google Custom Search Engine code embedded on that page.
| 4:28 am on Jan 15, 2008 (gmt 0)|
|his goal is to serve a given design as fast possible. |
So he serves up something so fast that it can start slowing you down even faster.
| 10:19 am on Jan 15, 2008 (gmt 0)|
Thanks for the link, interesting topic and an introduction to two new useful tools!
My biggest problem is with IE's caching of Ajax http requests... for the time being I am obliged to add a "dummy" timestamp variable to catalog pages to ensure that any updates get shown instead of the old version. No can-do for any improvement there.
| 11:00 am on Jan 15, 2008 (gmt 0)|
Removing the comments from a PHP file will increase the parse speed somewhat, but this is only slightly. Skipping over a comment block between /* and */ takes much less time than parsing the same amount of bytes containing variables and functions that have to be looked up, syntax checking taking place etc.
According to the video, page generation (the PHP part) takes in average only five percent of the total time the visitor has to wait before the whole page is rendered on his screen. So removing the comments may reduce that 5% to maybe 4.9%.
| 3:02 pm on Jan 15, 2008 (gmt 0)|
Respectfully... Yahoo are hardly the best at practicing what they preach. Neither are Google mind you, but Google Senior Engineer Aaron Hopkins also has an interesting piece called Optimizing Page Load Time [die.net], which has been around for a long time. It mentions a lot of the above, along with graphs pertaining to performance increases by using multiple hostnames.
| 3:44 pm on Jan 15, 2008 (gmt 0)|
I am surprised no one mentioned CSS sprites.
Definitely should check that out.
| 5:05 pm on Jan 15, 2008 (gmt 0)|
People are really getting diverted by how they feel about Yahoo! and discounting the video without even watching it because of that. There is some excellent research-based information in there. If you can't be bothered to watch the video, please don't be bothered to pass judgement on it.
>>no one mentioned CSS sprites.
#1. Reduce HTTP Requests. He specifically talks about sprites.
| 5:15 pm on Jan 15, 2008 (gmt 0)|
Sorry I meant in the discussion in the post :)
| 9:36 pm on Jan 15, 2008 (gmt 0)|
About spreading content over multiple domains... a few questions.
First off, what most concerned me was the "order of load" bit - this is not essential to many of my websites, but it would seem logical to keep all the (generated) html on the same domain to avoid conflict.
Lastly, what exactly does he mean by "domains"? Would sub-domains suffice as "alternate domains"?
| 9:46 pm on Jan 15, 2008 (gmt 0)|
Yeah, I'm wondering about moving the images to images.domain.com, and wonder what effect that has with things, and how that depends on whether the subdomain is on the same server, or on a different server.
| 10:20 pm on Jan 15, 2008 (gmt 0)|
I've experimented with that a little and haven't really noticed any difference - Sometimes its faster, sometimes its slower. But I probably dont have enough traffic volume to really gauge if it's helping or not.
| 10:43 pm on Jan 15, 2008 (gmt 0)|
From what I understand, the optimal way to move to load images is indeed to have them servered by a different server, but with certain prerequisites. For the most part, the real advantage comes from being able to use a stripped-down super-light HTTP server for the serving of static content (your images, CSS, JS files, etc..). In this way, the HTTP server can be pre-compiled without support for PHP, MySQL, Perl, mod_rewrite, etc., etc.. This gives the server a much smaller memory footprint and quick load-time. Naturally, your main Web server will retain such functionality. This all being in addition to the browser's parallel-loading advantage!
There's a few issues with having an images.domain.tld static file server though. If you have a single box with both your main HTTP server and your optimized static file server, you can't run both of them on port 80 on the same IP. One option is to re-port your static file server to another port, eg. 81. This is obviously a pain because your images will need to be referenced as images.domain.tld:81..., which can cause logistics problems down the road.
The better way to do it is to have a separate box (or the same box with 2 unique IP addresses). This way you can map your main domain to one IP, the static server which is the sub-domain to the other IP, and both can run on port 80!
It's quite an interesting subject that I've spent a bit of time on... To be honest though, I wouldn't recommend doing any of this unless you have a combination of servers under heavy load, along with an obvious problem in page-load times, but the load-speed increase is very slight in the majority of cases, to be honest. It really only matters with very large pages and very high traffic levels. Hope this helps.
| This 46 message thread spans 2 pages: 46 (  2 ) > > |