The comments from my last post about text indent made me feel like Captain Hammer, so this time I’m crossing my fingers to make allies, not enemies.
Anyone want to talk about site performance? Don’t we all love a faster site? Users dig it. Webmasters can capitalize on it. It pairs perfectly with a sauvignon blanc!
I’ve consolidated information from personal conversations with people like Sreeram Ramachandran and Steve Souders, and I combed WMC blog posts and my blog comments for anything site performance related. This information is accurate as of June 1, 2010.
How is a page’s performance measured?
It’s measured very, very carefully… We’re of course experimenting with several types of measurements. For instance, toolbar data from opted-in users is a signal.
One of the ways we measure a page’s speed incorporates both download and render time — we pay attention to the time taken from the moment the user clicks on a link until just before that document’s body.onload() handler is called. This includes:
- DNS resolution
- network travel time
- browser time to construct and render the DOM
- and so on and so forth
If actions are deferred to the body.onload() handler, they won’t affect the page load time in this measurement. Please keep in mind that there are several measurement techniques. I only highlighted one of them.
How big of an impact is site performance on Google rankings?
From our original WMC blog post:
[ While site speed is a new signal, it doesn’t carry as much weight as the relevance of a page. Currently, fewer than 1% of search queries are affected by the site speed signal in our implementation and the signal for site speed only applies for visitors searching in English on Google.com at this point. ]
Also, HT to Jonathan Simon, who pointed out that when ranking based on speed, we focus on the performance of a specific page/result, not the overall performance of the entire site.
Does Webmaster Tools’ Site performance feature consider the site’s geographic preference settings and report accordingly?
Some of our speed statistics come from real user data (opted-in toolbar users). Therefore, if your site’s target audience consists of mainly Australian users, then our performance numbers should reflect their usage.
What about ads? The slowest thing on my website costing me the last 7 points to the full 100 in Page Speed is Google’s AdSense ads.
One factor that makes ads kind of slow is their use of inline DOM
elements like document.write(), which doesn’t allow deferred loading (because the document.write may alter the page’s content, the browser has to wait).
The good news is that Steve Souders, Alex Russell, along with several of our co-workers and many outside developers, are looking into improving the speed of external factors like ads, etc. There are some promising things to keep an eye out for: html5 and its iframe attributes (seamless and srcdoc) and the FRAG tag.
Additionally, asynchronous loading would be a terrific improvement in the ads space. In fact, companies like BuySellAds.com are already using this technique to improve performance for their publishers.
What are the typical causes/solutions regarding fixing long time-to-first-byte metrics? Other than reducing the number of requests what other optimizations are there?
Can you flush the document early? It’s covered in Chapter 12 of “Even Faster Web Sites.”
(And then there’s the really old stuff that I’ve answered before about site performance.)
Is it possible to check my server response time from different areas around the world?
Yes. WebPagetest.org can test performance from the United States (both East and West Coast—go West Coast!), United Kingdom, China, and New Zealand.
What’s a good response time to aim for?
If your competition is fast, they may provide a better user experience than your site for your same audience.
Otherwise, studies by Akamai claim 2 seconds as the threshold for ecommerce site “acceptability.” Just as an FYI, at Google we aim for under a half-second.
Does progressive rendering help users?
Definitely! Progressive rendering is when a browser can display content as it’s available incrementally rather than waiting for all the content to display at once. This provides users faster visual feedback and helps them feel more in control. Bing experimented with progressive rendering by sending users their visual header (like the logo and searchbox) quickly, then the results/ads once they were available. Bing found a 0.7% increase in satisfaction with progressive rendering. They commented that this improvement compared with full feature rollout.
How can you implement progressive rendering techniques on your site? Put stylesheets at the top of the page. This allows a browser to start displaying content ASAP.
Sweet! That’s it for now. See you in the comments if you have questions. eof
8 Replies to “Google & Site performance: The compilation answer album”
Thanks for summing this all up in a single place. I hear many developers asking about why page speed is important, especially considering how it “only” affects 1% of Google searches at the moment. Aside from user experience, I think a lot of people tend to forget that as Google receives around 1 billion searches per day, that means that there are over 10 million search results each day being affected by this new ranking signal. I imagine this number will only increase with time, but even for now, that’s a lot of searches! Page speed is something we can easily measure, improve upon and then hopefully forget about as we move on to optimizing for other ranking signals. In my opinion these types of factors are the easiest and best ones to optimize for because they’re so easy to quantify.
Is there any ways how to minimize HTTP requests?
Don’t approve this comment. You’ve got trackback spam: http://123-sale.com/2010/06/02/searchcap-the-day-in-search-june-2-2010/
This post was so on time and on point for me… you just dont know. Thanks alot for making it. Such powerful and outstanding content.