P.S. There is something to think about in that the first time I tried to post this comment, there was a problem loading the page. HN is actually one of the slowest sites I put up with--great quality is worth the wait, but not the quality of most websites.
agreed, specifically about HN. it seems to have gotten much worse as of late. probably attracting a larger crowd nowadays, since more people are migrating here.
Agreed about the policy, but what's that about HN being slow? It's loads incredibly fast for me, much faster than other news aggregators (Reddit, etc.)
Interestingly, they appear to count loading times of third party stuff (which doesn't affect the display of the main body of content, e.g. the blog post body) as part of the site load time.
This means that if you use Disqus and a few badges from Reddit and the like, even if you set them up so that they don't slow down your main content, Google will hold it against you. That's a little... not great.
How do you know that? Are you going by the webmasters tool performance page? I'd imagine that view is a very simplified perspective on the actual metrics that search uses for ranking.
weebmaster tools reports 10-20x grater response time than it actually is for one of the pages I maintain (haven't checked the others). So I would also conclude that it measures the time until every last CSS,JS and iframe is loaded. And that is just not right. Ok, I understand that they take CSS into account. But my pages work without JS, and I only use iframe-s to display ads. The point is that my page is readable long before JS files and ads are loaded.
I'd also like to know if they take caching of CSS,JS and image files into account.
Even though I couldn't find out if they do in the Webmaster Tools Report; the Page Speed Analyzer (Firefox Add-on from Google) does take it into account (as does YSlow, another Speed Testing Add-on from Yahoo).
I would think that Google would take it into account because checking if something is cachable is easy; and I don't think Google is stupid enough to not check that.
They reportedly said that they would use both the time to get HTML from Googlebot (presumably what Webmaster Tools shows) as well as the time to load the whole page, as measured by people with the Google toolbar. http://searchengineland.com/google-now-counts-site-speed-as-...
1. How fast the server responds and how quickly the page contents (HTML, CSS, JS, etc) are downloaded.
2. How long the rendering of the contents takes. Using blocking JS will slow this down. Using horribly complex CSS selectors would also affect the rendering.
Google Analytics moved to non-blocking loading recently (it's different JS code), which I think is part of a bigger push within Google. Other services should do the same.
Our load time is penalized on that graph by loading some images asynchronously via javascript. It's a slideshow gallery, so loading them serially this way allows it to start playing faster.
I have two concerns here.(well 3, but swombat covered that one)
1. If you are going to penalize sites for being "slow" then how about you tell us what slow is? Is a site loading in 10 seconds "slow"? is a site with a 5mb index page that loads in 15 seconds "slow"? How about some metrics so that we can optimize properly?
And what will that do to a lot of content rich sites? If you have a lot of images/flash/javascript it sounds like you are going to get screwed for trying to make a better looking user experience.
2. Of course Google search results experiment would affect user satisfaction. You are looking for results, and you want to do a lot of searches. BUT when you are clicking to see the result you like, I think most people would be willing to wait 2 seconds extra to load the more relevant information.
Sounds like this is yet another attempt at boosting big sites, where large sites like eHow and Mahalo get preference in results just because they can afford faster servers.
Some of the very worst offenders are big sites, eg. cnn.com takes about 2.5 seconds to load close to 100 external resources. Mahalo takes about 2 seconds for about 40 external resources.
As for metrics - as a user, I can say that 10 seconds is too slow. So is a 5M index page that loads in 15 seconds (what the hell do you need 5 megs of data on your index page for? That's like a 5 minute YouTube video). I want to see results within 1-2 seconds of clicking on a page; otherwise, you've broken my train of thought and I need to mentally context-switch each time I visit a page.
You do need faster server to serve more people, but you don't (necessarily) need faster server to make faster sites. There are some exceptions. If you have a site that takes 10 seconds to load even with low traffic, something is wrong with your configuration.
Not pleased. It can cost a lot of money to have a fast site.
If you're a neighborhood blog trying to make a go of it, you can't afford a developer to optimize your site and cache the crap out of it. Meanwhile, the local newspaper site, running a tag archive page for your neighborhood powered by Outside.in or some other McLocal scraper app, can do that. You lose every time on the speed front, despite having original content.
If your end users want a fast site (I would imagine most do), then the faster sites are going to win anyway, with everything else being equal.
At worst, Google is just reflecting that reality (in ~1% of searches where it changes the results).
Personally, I would prefer to compete in a world where everything relevant is "up for competition". You can compete on content, speed, price, or a myriad of other factors. If your complaint is that you want to compete on all of those things EXCEPT speed because that metric is unfair in your opinion, I don't have sympathy for that point of view.
FWIW, I just visited your link and with a cold cache it took ~5 seconds the status bar to report every asset was downloaded. Definitely not a scientific measurement by any means, but I thought you might like to know.
I also ran the site through http://www.webpageanalyzer.com/ (one of many such services), and it said on a T1 it would take approximately 6.5 seconds to load. It also provides a number of improvements to cut down the page size, and improve rendering speed.
“Quality should still be the first and foremost concern [for site owners],” Cutts says. “This change affects outliers; we estimate that fewer than 1% of queries will be impacted. If you’re the best resource, you’ll probably still come up.”
Unless your site is taking 10 seconds to respond, it probably won't affect you. Google has said this change will affect only 1% of queries, so there's a 99% chance you're fine.
Most popular sites use iframe to (either) asynchronously load javascript ads or load it on a separate page so that it doesn't effect your initial site speed. Most popular ad platforms also offer iframe specific codes you just have to ask for them (I know adify does). If they don't offer iframe codes, ask if it against their policy to load codes on iframe, they might make exceptions for high traffic sites (Arstechnica loads all ads on iframe).
For general optimization, yahoo has an excellent resource page: http://developer.yahoo.com/performance/rules.html I was able to bring my site from ~8-9s loading time to ~2-3s running on a not too powerful server.
Three optimizations that worked great for me.
- CDN for static files (maxCDN has a great cheap introductory offer of 1tb for $9.99 and offers PULL)
- Minify and Gzip CSS and js files and then fetch them from CDN.
The absolute best thing you can do to reduce page loading time is to cut the number of requests the browser has to make. Each request requires a round-trip to the server, with all the latency of a cross-country or cross-continent trip. It requires overhead for TCP/IP and HTTP headers. And most browsers limit concurrent open connections to 2-6, so the bulk of these requests are serialized and block further loading of the page.
Sprite all your images, so that it takes one request to get the whole chrome rather than one per image. If you have multiple JavaScript files, concatenate them together. Same with your CSS. Obviously, gzip them and push them to a CDN if possible, and cache them aggressively. And consider using data: urls to inline images directly into the page: the time saved on requests more than makes up for the added bytes from b64ing the data.
Thanks for the tips. Most of these I am already aware of. You are very much right about reducing the number of requests to bare minimum. I was able to cut down from 28 to 12, but the last few are tricky because some connections are external files (ads, analytics, disqus). Also I don't think its as much as the number of the connection thats the problem but the number of DNS lookup that will cause more delay. So if you have 12 file thats spread around 3 different locations, its better than having 5 files spread around 5 different locations.
Concatenate is also a good idea, but in some cases it breaks some JavaScripts for me.
Personally I am happy with ~2s avg load time, just trying to see how far I can push that number.
What if the page you're looking for just happens to contain a lot of content / images / etc?
Adding speed to Google's ranking algorithms is only useful for searches where there are several equally good search results (in which case the fastest would be the one you would want). But in the event that you're actually searching for a lot of information, having fast (but less informative) sites propagate to the top would be detrimental.
Speed is only one factor in their ranking. If a site is notably better than other sites for a query, they said in the article that it will still rank first for that query.
“Google also cautions web site owners not to sacrifice relevance in the name of faster web pages, and even says this new ranking factor will impact very few queries.”
If it is true that non-HTML resources are a factor based on Google Toolbar reporting, that's scary. On high confidence sites -- more than 1000 datapoints, in Google Webmaster terms -- average speed seems stable and correlated with other performance measures. This is not true in my experience with medium confidence sites, 100 to 1000 Toolbar datapoints.
who uses google toolbar besides old IE users that need popup blockers? Seems like super high variance data depending on the end users connection, perhaps they get info from chrome usage statistics?
P.S. There is something to think about in that the first time I tried to post this comment, there was a problem loading the page. HN is actually one of the slowest sites I put up with--great quality is worth the wait, but not the quality of most websites.