| 1:07 pm on Sep 25, 2013 (gmt 0)|
Went from shared hosting with a respons time of 5000ms to a VPS with a response time of 180ms....no change in ranking. This was with 6 months of data.
| 2:41 pm on Sep 25, 2013 (gmt 0)|
My experience is essentially the same as chalkywhite's. Fast is good, but don't expect it to help your rankings.
| 3:18 pm on Sep 25, 2013 (gmt 0)|
doesn't do squat for rankings in my experience even a site that scores 99% on both mobile and desktop!
| 8:00 pm on Sep 25, 2013 (gmt 0)|
Does it improve ranking indirectly from better user usage signal such as pageviews and less bounce rate, increased usage and loyalties?
I personally like speed as I stop visiting sites that loads slow myself. Which means that I would not CTR through SERP is I had experiences with a site prior knowing that it loads slowly. And there are other choices on the SERP.
Ranking aside, does anyone experience higher interactions from their users or traffic (pageview) increases after they boosted their site speed? How did you measure it and was it a clear picture?
I myself is having a hard time getting measureable metrics to support the assumption. There are simply too much noise when dealing with the data...I am not going to A/B test by routing half of my visitors to a slower site -.-.
I have upgraded my hosting only in faith that it will improve my traffic over time. Which my traffic and income have. Is it blind faith or just convenient accident?
| 8:07 pm on Sep 25, 2013 (gmt 0)|
Hosting is often not a primary speed factor. Things like image size and the number of http calls affect loading time a lot more.
IMO, speed is a negative factor when you have a painfully slow site... definitely when it's slow enough to cause visitors to bail and return to serps. On Pandalized sites, I often see it as a problem along with other factors, but I've never isolated it out to see if fixing loading time alone would help. I just fix it.
I don't think that shaving milliseconds off of a fast loading site, though, will directly improve rankings... it's not that kind of a race... albeit I believe that the improved user experience in the long run can help you.
| 8:11 pm on Sep 25, 2013 (gmt 0)|
I don't think it can help you, but having a slow site can probably hurt you, if for no other reason than the user interaction might tip Google off that this is not the best user experience going.
| 9:42 pm on Sep 25, 2013 (gmt 0)|
fwiw page load speed has been reported in GWT for a long time.
| 10:05 pm on Sep 25, 2013 (gmt 0)|
Not a ranking factor but I suspect the benefit of a fast loading page for Google and for site owners is more ads viewed.
| 10:24 pm on Sep 25, 2013 (gmt 0)|
you can't rank if you're not crawled and page speed could have a significant impact on crawl budget for many sites.
| 11:24 pm on Sep 25, 2013 (gmt 0)|
Just noticed this from Matt Cutts on speed " if all other sites are equal" : [youtube.com...]
| 11:38 pm on Sep 25, 2013 (gmt 0)|
If nothing else this is a great tool from google, I learned a lot of stuff (that I probably should have already known) in a very short amount of time. Following the info was able to make a noticeable difference in site speed in less than an hour.
I agree with Netmeg and others here, not sure if a faster site can "help directly" with ranking but I'd be willing to bet that a slow site will have a negative affect on ranking.
| 11:56 pm on Sep 25, 2013 (gmt 0)|
I did some more digging and came up with this, back in 2010 :
|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. |
Posted by Amit Singhal, Google Fellow and Matt Cutts, Principal Engineer, Google Search Quality Team
Note, Amit Singhal who's role is heading up search quality [ I believe ] is a signatory and the blog post talks about the introduction of a "new signal". It makes me wonder if it became an indirect contributing factor to Panda's QA considerations.
How do folks think about this in the context of all other factors between sites being equal?
| 12:25 am on Sep 26, 2013 (gmt 0)|
We increased our pages last month from mid 70s to the 90s and it did not do a thing for ranking.
| 12:50 am on Sep 26, 2013 (gmt 0)|
|I did some more digging and came up with this, back in 2010 : |
matt cutts started speaking about this publicly at PubCon in november, 2009, so this has been developing for almost 4 years now.
'Speed of Site' May Become Ranking Factor in 2010:
| 1:57 am on Sep 26, 2013 (gmt 0)|
The question Matt Cutts answers in the recent video was phrased as a question about mobile, but Matt expanded it to cover a range of considerations....
Is page speed a more important factor for mobile sites?
Matt Cutts - Aug 21, 2013 - trt 1:39
Matt talks about performance within regions (recognizing that networks and sites in different parts of the world, eg, have different capabilites), and indicates that, because of these differences, Google now tends to look at "outliers", performers significantly below the norm. So, right now, "really, really slow" sites do suffer in rankings... pretty much what I'd noted above. Matt says that while the question was about mobile, the current speed signals apply across the board to all sites.
If you listen to the answer closely, Matt suggests that Google is also paying attention to certain performance factors that might particularly affect the mobile experience. If the effects become significant enough, Google may, over time, start applying those mobile speed signals to ranking.
So, Google clearly is paying attention to quality signals over time, which leads into your second question, about the Amit Singhal blog post from early April, 2010...
|...the blog post talks about the introduction of a "new signal". It makes me wonder if it became an indirect contributing factor to Panda's QA considerations. |
The post was published several weeks before the MayDay update around the first of May, 2010. MayDay, IMO, was precursor to Panda... and yes, I'm sure that site speed was one of the early quality signals that Google's seed sets were evaluating for what I see as a continuum of updates. At this point, I'm not sure exactly what was blended in when... but all of these factors continue to be signals that Google pays attention to.
| 2:21 am on Sep 26, 2013 (gmt 0)|
PS to the above, and thanks phranque for the last reference.
In the progression of Google's updates, the continuity of it all becomes striking. I've been including, for a while now in notes to myself, article titles, dates, and author references, because I find them helpful (if not necessary) to follow what's going on.
It's probably also helpful to do so when posting links or references about the evolution of the algorithm, so we know all know what we're talking about.
In the long run, "just noticed this" isn't likely to be helpful in reading over a thread, though it may save the poster some time at the moment of posting. Nothing mandatory about this, but I'm just sayin' that some detail about where a link goes is helpful in reading a discussion.
| 2:32 am on Sep 26, 2013 (gmt 0)|
|Googler Matt Cutts has recently said in an interview that the company may start putting weightage on the speed at which the site loads as a ranking factor moving ahead in 2010. |
@phranque - thanks , there's some powerful insights in the mix coming from the OP/thread above.
But there's a lot of way's to measure speed, I suppose, and the most relevant correlation when ranking sites is probably in the measurement of user satisfaction. That's why server response times are, in isolation, likely irrelevant.
Simply, a good user experience will likely result in more conversions.
"Time To First Byte" ( TTFB ) is mentioned in a few online studies that I've read and being of no relevance to user satisfaction, whereas the time to render a page fully would play into optimizing the user experience.
And the quality of that rendering also becomes part of that speed equation to put you ahead of the algo.
| 4:41 am on Sep 26, 2013 (gmt 0)|
|There's a lot of help from both Google Page Speed and Y! Slow that goes beyond image compression and database optimization. Rather than resist, I suggest at least reading the help files. |
For my entire online career I've felt that page speed is an important and almost secret weapon. Now it's becoming an open secret, apparently. I'll bet lots of people will still ignore it.
- tedster Nov 17, 2009
PageSpeed Insights appears to be Google's replacement for Page Speed.
(http://code.google.com/speed/page-speed/ redirects to https://developers.google.com/speed/pagespeed/)
the About PageSpeed Insights Google Developers page [developers.google.com] describes how they measure time to above-the-fold load as well as time to full load.
also measured by PageSpeed Insights — Server Response Time:
|Server response time measures how long it takes to load the necessary HTML to begin rendering the page from your server, subtracting out the network latency between Google and your server. |
You should reduce your server response time under 200ms.