Group items tagged

When people say"page load time" for a website, they usually mean one of two measurements: "document complete" time or "fully rendered" time. Think of document complete time as the time it takes a page to load before you can start clicking or entering data. All the content might not be there yet, but you can interact with the page. Think of fully rendered time as the time it takes to download and display all images, advertisements, and analytic trackers. This is all the "background stuff" you see fill in as you're scrolling through a page.

Since Google was not clear on what page load time means, we examined both the effects of both document complete and fully rendered on search rankings. However our biggest surprise came from the lack of correlation of two key metrics! We expected, if anything, these 2 metrics would clearly have an impact on search ranking. However, our data shows no clear correlation between document complete or fully rendered times with search engine rank, as you can see in the graph below:

With no correlation between search ranking and what is traditionally thought of a "page load time" we expanded our search to the Time to First Byte (TTFB). This metric captures how long it takes your browser to receive the first byte of a response from a web server when you request a particular URL. In other words, this metric encompasses the network latency of sending your request to the web server, the amount of time the web server spent processing and generating a response, and amount of time it took to send the first byte of that response back from the server to your browser.

The TTFB result was surprising in a clear correlation was identified between decreasing search rank and increasing time to first byte. Sites that have a lower TTFB respond faster and have higher search result rankings than slower sites with a higher TTFB. Of all the data we captured, the TTFB metric had the strongest correlation effect, implying a high likelihood of some level of influence on search ranking.

The surprising result here was with the the median size of each web page, in bytes, relative to the search ranking position. By "page size," we mean all of the bytes that were downloaded to fully render the page, including all the images, ads, third party widgets, and fonts. When we graphed the median page size for each search rank position, we found a counterintuitive correlation of decreasing page size to decreasing page rank, with an anomalous dip in the top 3 ranks.

We suspect over time, though, that page rendering time will also factor into rankings due to the high indication of the importance of user experience.

our data shows there is a correlation between lower time-to-first-byte (TTFB) metrics and higher search engine rankings. Websites with servers and back-end infrastructure that could quickly deliver web content had a higher search ranking than those that were slower. This means that, despite conventional wisdom, it is back-end website performance and not front-end website performance that directly impacts a website's search engine ranking.

Our data shows there is no correlation between "page load time" (either document complete or fully rendered) and ranking on Google's search results page. This is true not only for generic searches (one or two keywords) but also for "long tail" searches (4 or 5 keywords) as well. We did not see websites with faster page load times ranking higher than websites with slower page load times in any consistent fashion. If Page Load Time is a factor in search engine rankings, it is being lost in the noise of other factors. We had hoped to see some correlation especially for generic one- or two-word queries. Our belief was that the high competition for generic searches would make smaller factors like page speed stand out more.

TTFB is affected by 3 factors: The network latency between a visitor and the server. How heavily loaded the web server is. How quickly the website's back end can generate the content.

Websites can lower network latency by utilizing Content Distribution Networks (CDNs). CDNs can quickly deliver content to all visitors, often regardless of geographic location, in a greatly accelerated manner.

Do these websites rank highly because they have better back-end infrastructure than other sites? Or do they need better back-end infrastructure to handle the load of ALREADY being ranked higher? While both are possible, our conclusion is that sites with faster back ends receive a higher rank, and not the other way around.

The back-end performance of a website directly impacts search engine ranking. The back end includes the web servers, their network connections, the use of CDNs, and the back-end application and database servers. Website owners should explore ways to improve their TTFB. This includes using CDNs, optimizing your application code, optimizing database queries, and ensuring you have fast and responsive web servers.

Fast websites have more visitors, who visit more pages, for longer period of times, who come back more often, and are more likely to purchase products or click ads. In short, faster websites make users happy, and happy users promote your website through linking and sharing. All of these things contribute to improving search engine rankings.

A whopping 804 KB per page is comprised of images. Three years ago, images comprised just 372 KB of a page’s total payload.

images are one of the single greatest impediments to front-end performance. All too often, they’re either in the wrong format or they’re uncompressed or they’re not optimized to load progressively — or all of the above.

Today, 38% of pages use Flash, compared to 52% in 2010. This is a good thing. Nothing against Flash, per se, but if Apple has no plans ever to support it, its obsolescence is inevitable in our increasingly mobile-first world.

use of custom fonts has exploded — from 1% in 2010 to 33% today.

But custom fonts have a dark side: they can incur a significant performance penalty.

These days, images on the web have to work hard. They need to be high-res enough to satisfy users with retina displays, and they also need to be small enough in size that they don’t blow your mobile data cap in one fell swoop. Responsive web design attempts to navigate this tricky terrain, with varying degrees of success.

Google published findings, based on Google Analytics data, which suggest that load times have gotten marginally faster for desktop users, and up to 30% faster for mobile users.

Here at Strangeloop/Radware, we’ve found the opposite. Using WebPagetest, we’ve been testing the same 2,000 top Alexa-ranked ecommerce sites since 2010, and our data tells us that top ecommerce pages have gotten 22% slower in the past year.

This quick-and-dirty case study illustrates how network speed doesn’t directly correlate to load time. For example, download bandwidth increases 333% from DSL (1.5Mbps) to cable (5Mbps), yet the performance gain is only 12%.

Move scripts to the bottom of the page

It’s better to move scripts from the top to as low in the page as possible. One reason is to enable progressive rendering, but another is to achieve greater download parallelization.

Make JavaScript and CSS external

If users on your site have multiple page views per session and many of your pages re-use the same scripts and stylesheets, you could potentially benefit from cached external files. Pages that have few (perhaps only one) page view per session may find that inlining JavaScript and CSS results in faster end-user response times.

Reduce DNS lookups

Minify JavaScript

In addition to minifying external scripts, you can also minify inlined script blocks. Even if you’re already gzipping your scripts, minifying them will still reduce the size by at least 5%.

In 2012, the average worldwide RTT to Google is still ~100ms, and ~50-60ms within the US.

Fiber-to-the-home services provided 17 milliseconds (ms) round-trip latency on average, while cable-based

That's 17-44ms of latency just to the closest measuring node within your ISP, before your packet hits any internet backbone.

depending on your network, quality of signal, and time of day, then just traversing your way to the internet backbone can take anywhere from 50 to 200ms+. From there, add backbone time and multiply by two: we are looking at 100-1000ms RTT range on mobile.

the only way to improve the situation is to move the bits closer: place your servers closers to your users, leverage CDN's, reuse connections where possible (TCP slow start), and of course, no bit is faster than no bit - send fewer bits.

"High speed" connectivity is not all about bandwidth, unlike what many of our ISPs would like to promote.

Gzip page components

Everything Gzipped 24% 44%

Put stylesheets at the top

A CDN helps in some situations, but not all.

Compression still helps. A lot.