Mobile Page Bounce Rates and New Benchmarks

[engine]

How does your page stack up against the new benchmarks?

Google published some new statistics showing that load time can significantly affect bounce rates.



[thinkwithgoogle.com...]
Article:

https://www.thinkwithgoogle.com/articles/mobile-page-speed-new-industry-benchmarks.html

You can test your site from this link, please copy and paste to use.

https://testmysite.thinkwithgoogle.com/

It was also interesting to learn that Google discovered that 70% of pages were more than 1 MB, 36% over 2MB, and 12% were over 4MB.





[edited by: not2easy at 3:53 am (utc) on Feb 28, 2017]

[edited by: Robert_Charlton at 11:19 am (utc) on Mar 2, 2017]
[edit reason] typo/link [/edit]

[Wilburforce]

Looks like a typo (no colon after https) for the second link.

This works: [testmysite.thinkwithgoogle.com ]

[aristotle]

It was also interesting to learn that Google discovered that 70% of pages were more than 1 MB, 36% over 2MB, and 12% were over 4MB.

Is this due to code bloat, failure to efficiently compress images, or what? Think of all the wasted bandwidth, people's waiting time and frustration.

I don't understand it.

Some of these sites deserve a high bounce rate if their creators do such a lousy job

[MrSavage]

That's a really terrific tool. Like what has been offered before, but to me this is like version 2.0 and more useful/trustworthy.

[engine]

I wonder if there's another issue here, which may not seem obvious, and that's AMP. Typically, an AMP page will be a stripped down page, but it's also served from Google's servers. Google's proving that a super lightweight page suits mobile users. It has the stats available so i'm inclined to believe the figures.

[JAB Creations]

Hm, my scores have dropped recently:

Business Website: 100/100, 100/100, 97/100
Personal Website: 100/100, 91/100, 97/100

John

[Dimitri]

I am also score 100/100 for mobile friendliness, and above 95% of the other values. It's always pleasant to be able to measure the impact of our work. I hope Google values our hard work.

Now, if you check big sites, and especially e-commerce sites, their score are so bad! I wonder how it's impacting their sales from mobiles. This is a criteria, when I decided which site to promote through affiliate links. If the landing page of an affiliate link is taking too long to load on a mobile device, I am not promoting it, considering that most people will give up before the page loads.

[smilie]

>> @Dimitri: if you check big sites, and especially e-commerce sites, their score are so bad! I wonder how it's impacting their sales from mobiles.

Not by much. Mobile traffic is, essentially, two-fold: look but not buy, and "fake users" bots.

Google is heavy in mobile for three reasons:
1) their employees are young so everyone around them is on mobile phone - and it seems to them that everyone else is

2) they make billions from real mobile visitors from a Web 2.0 .com bubble sites, the 200 unicorn mobile startups who's fantasy market caps are ranked in billions $, and 5000 that are "ranked" in millions. Right now they are plundering the investor money. It is blowing up very shortly as 1.0 .com bubble did, as investors will shortly be squeezed and will realize that paying $1-$4 per download of some app so you can make advertising money on it is a mathematically guaranteed failure of the majority of the apps as it is a PONZI pyramid scheme.

3) they make billions from mobile botnets that are much harder to identify from desktop botnets, because of migrating pools of mobile IPs.

Big ecommerce sites, however, know exactly what their users want. If they are not thinly mobile at 100/100 it means that they could not yet make it properly work. And it's been 10 years ("By the end of 2007, there were 295 million subscribers on 3G networks worldwide" - wiki), so it is not very likely that it's easily possible.

[aristotle]

I wonder if there's another issue here, which may not seem obvious, and that's AMP.

I haven't created any AMP pages for my sites because they're not needed. All of my pages are already mobile-friendly and load in a fraction of a second on desktop, tablet, and phones.

It was also interesting to learn that Google discovered that 70% of pages were more than 1 MB, 36% over 2MB, and 12% were over 4MB.

I'm still waiting for an answer to my earlier question about why these pages need to load so much data. Is it code bloat, or inefficient compression of image files, just plain bad design, or what?

[Wilburforce]

All of my pages are already mobile-friendly and load in a fraction of a second on desktop, tablet, and phones.

As do mine, but I still get a lower score on Google's test because they want to "eliminate render-blocking JavaScript and CSS in above-the-fold content". It doesn't "block" rendering: it is rendering. There are pages out there that load the css after the page, so you get the irritating flash of unformatted page (how mobile-friendly is that?) before the css kicks in, but I have no idea how or why Google thinks this enhances the user-experience. OK, visually impaired users might gain a couple of milliseconds, but for the rest of us the page isn't rendered until it is formatted. If default styles were any good, we wouldn't need css at all.

The test doesn't measure speed, it evaluates factors that contribute to speed. A page with massive graphics content that takes forever to load will still get 100% as long as the graphics are in a single optimised file and use css sprites, while a page with a footprint of a few KB will only get 80% if the browser has to load a stylesheet before you look at it.

As for average page size, I personally see many pages with high-resolution video backgrounds or scrolling images, embedded audio, animations, and largely unnecessary bloat that add massively to the payload. If 12% of pages are over 4MB, the global mean would be 480K if the remaining 88% of pages were zero.

There is an obvious trade-off between load-speed and visual wizardry, and as connection and processing speeds have improved, the shift to visual wizardry has increased. For those of us whose main focus is on written content this may look like a distraction, but in evolutionary terms we are dinosaurs.

[engine]

I'm still waiting for an answer to my earlier question about why these pages need to load so much data. Is it code bloat, or inefficient compression of image files, just plain bad design, or what?

Only the site owners can answer that. There are still lots of sites out there that have web devs that don't place importance on low overheads. Some of that comes from the pressure by a client to add stuff, of course.

[keyplyr]

I still get a lower score on Google's test because they want to "eliminate render-blocking JavaScript and CSS in above-the-fold content". It doesn't "block" rendering: it is rendering

Agreed.

Also, the tool doesn't recognize I do use compression and I do use browser caching and they are done correctly :)

What does always fail Google's speed tests is Google Adsense code.

[robzilla]

There's a common plug-and-play mentality that is behind much of the page bloat we see today. Install WordPress, pick a theme you like and a few plug-ins and often you're already looking at a dozen Javascript and CSS files. Also, since time is money, many developers just use a bunch of libraries to get stuff done quickly for their clients (either because of time pressure or laziness and easy money) rather than figure out and code the most efficient solution.

[keyplyr]

Well that's true robzilla but a speed tool won't change any of that. The site owners are oblivious & the developers have been paid and moved on.

Many site owners think their pages load great because they always use the same browser loading cached files. If they do by chance stumble on the fact their pages load slow, instead of addressesing the actual cause, they'll turn to a CDN.

If site owners do discover the slow loading

[ChanandlerBong]

all my problems are caused by AdSense and GA code

oh the irony

[Wilburforce]

instead of addressesing the actual cause, they'll turn to a CDN

At least Google's tool doesn't require one: Yslow gives you a lower score if you don't use a CDN. My server is in my nearest city, and most of my work is within a 30-mile radius of it, so apart from affecting my Yslow score a CDN would be virtually worthless. However, it would be interesting to know how much weight is or will be attached to speed scores by search engines.

Bounce-rates - as per the OP - can obviously make a difference, but is this a signal from Google that based on the predictive value of page-speed they will use (or already use?) speed scores as a direct weighting? Along with mobile friendliness - the other (and primary) focus of the new tool - it has been creeping up in Google's direction of our attention for a few years.

[robzilla]

Yslow gives you a lower score if you don't use a CDN

Just goes to show you shouldn't take these tools too literally or seriously. They're just bundles of best practices that give you a quick indication of how you're doing. In the end, you know what's best for your site and your users, and it would be foolish to aim for the highest possible score in every tool available. As you say, a CDN may only slow you down (or at least increase your costs), even if your score might go up.

[Wilburforce]

it would be foolish to aim for the highest possible score in every tool available

I completely agree, but what if the score in a specific tool (e.g. Google) becomes (or is already) a ranking factor?

[robzilla]

what if the score in a specific tool (e.g. Google) becomes (or is already) a ranking factor?

In regards to page speed tools, that's not going to happen, simply because a 50/100 scoring site can be faster than a 100/100 site. I've also not seen any evidence of Google rendering pages during a crawl. However, it would make sense for them to use the things that go into the mobile friendliness score (and possibly more) to determine whether a friendly page should get an edge over a non-friendly page in the mobile SERPs. And I think this test doesn't require them to fully render pages either; I suspect they can simulate a mobile view using the HTML and CSS.

[engine]

I've been using this test for a few days now and randomly testing sites. It's very interesting to pick site that rank well and to run them through the tester.

I've come to the conclusion that it's a guide only, and flawed.

If the score is really poor, then you'd expect a poor result on, for example, mobile. If it's median, it's going to be ok.

What I read from this is that as web developers we should be enhancing the sites as much as possible for the best user experience.

Use this as a guide, and not as a de-facto rule, and I think you'll be fine.

[Wilburforce]

Out or interest, has anyone requested a free report?

[Wilburforce]

Incidentally, when I tried moving my js menu to the the bottom of the html (still at the top of the viewed page, obviously) it cleared the "render-blocking" message, so it clearly objects to js more than it does to css.

What I hadn't seen, until then, is the message you get when everything is OK (Keep up the good work. Read “25 Principles of Mobile Site Design."), and for anyone who hasn't yet seen it, the 25 Principles of Mobile Site Design is worth reading:

[static.googleusercontent.com ]