Help interpreting site index results

Hi Patrick,

Hope all’s well.

I’d really appreciate your help & sorry for the long thread.

Mainly I’m trying to get my head around interpreting the Google speed index score and how it correlates with other site metric scores.

Having read your link to information about Google’s speed index score,

Q1. Am I correct in thinking Google’s speed index score is the most important metric? Perceived site speed being most important?

However speed index scores doesn’t always seem logical. I’ll try to explain. I sometimes see results with a:

Low speed index score BUT with relatively slow / high general site metrics speeds
vs
High speed index score with relatively quick / low site metrics speeds

Some examples to illustrate below:

MY LIVE SITE RESULTS
Main mirror in Amsterdam, provided these results:

http://www.webpagetest.org/result/150814_GD_GCG/

Speed index: 1754
Start render: 1.628s
Visually complete: 7.000s
Doc complete: 4.683s

Most of these stats seem to be good. I understand a speed index score <2000 is good. But visually complete in 7 seconds doesn’t seem good. I thought this would correlate with a higher speed index score.

However thinking about perceived experience, I can see the end user starts seeing the page begin to build at 1.6 seconds. Is seeing a page build early good perceived experience?

Q2. start render have more weight over visually complete times? Does this explain why the Google speed index score is a low 1754?

DEV SITE COMPARISION
When I test my dev site (cheap server setup) with a new Genesis WP theme all the stats seem better, some much better. But speed index 2641 is much higher, see test link below. I don’t understand this.

http://www.webpagetest.org/result/150813_AZ_17DA/

I also repeated the test & got these freakishly good stats but the Google speed index score 1526 is only marginally better than my live site result.

Speed index: 1526
Start render: 0.611s
Visually complete: 2.300s
Doc complete: 0.861s

http://www.webpagetest.org/result/150814_XA_HH6/

Q3. So is the Google’s speed index always accurate?

Q4. Which metric is most important when measuring perceived site speed? Is it (in order):

  1. Google speed
  2. TTFB
  3. Start render
  4. Visually complete
  5. Document complete (load time)
  6. Fully loaded

Q5. Is it normal for visually complete to always lag behind load time?

Thanks for looking.
Kevin

Q1. Am I correct in thinking Google’s speed index score is the most important metric? Perceived site speed being most important?

For the visitor - Yes and yes.
Though do not make it the sole point of attention.
Time to interaction is also very important.

SI: 1754 not too bad. <= 1000 best.
Visually complete: 7s is dreadful, but that’s the whole page.
Even so I’d work on lazy-loading anything unseen in the initial viewport.

Try to get everything that paints to the visible area of the display down the pipe first, according to Google preferably inside the first 14kb.
And yes it’s possible, though a major struggle.

Is seeing a page build early good perceived experience?

Yes, unless it’s jumping around as layout changes, or if the user cannot interact with it.

Q3. So is the Google’s speed index always accurate?

Nothing is 100% accurate, but it’s a very strong indicator.

Q4. Personally I agree, but with minor caveats. I could be wrong.

Q5. Is it normal for visually complete to always lag behind load time?

My personal opinion is no, though there are always exceptions.
Some of the assets loaded last are changing the window content.
Try to move those earlier in the load sequence, or have them affect the display on-scroll instead.

Looking at the waterfall reducing the number of assets would go a long way to improving the overall timing.
Combine the files downloaded before document ready.
Maybe try Googles page speed mod?

Regards

Mike

Hi Mike,

Thanks for your help!

I had a strong hunch that speed index was the ‘big daddy’ metric but as you say all other metrics tend to support a low or high score.

I’m not happy with my current site speed hence a rebuild in dev which early progress shows is much better. Still lots to do. I’m not a developer so all the hardcore technical stuff is pretty heavy reading.

You raise a good point, “Time to interaction is also very important.”

Q1. How do you measure time to interaction? Is it document complete?

The killer question still up for grabs, which I didn’t pose well initially is:

Q2. Why is speed index lower & better with these results: http://www.webpagetest.org/result/150814_GD_GCG/

Speed index: 1754
Start render: 1.628s
Visually complete: 7.000s
Doc complete: 4.683s

than these results: http://www.webpagetest.org/result/150813_AZ_17DA/

Speed index: 2641
Start render: 1.517s
Visually complete: 3.100s
Doc complete: 1.690s

I’ve also found this (I think) amazing WP plugin Plugin Organizer – WordPress plugin | WordPress.org that allows plugins to be disabled per page. Which means I can deactivate all e-commerce related plugins on my homepage.

Again, thanks for your help.

Speed Index is the best metric, but understanding how it’s arrived at is crucial.

Q1. How do you measure time to interaction? Is it document complete?

Probably too technical for you right now but it’s:
Time to interaction = performance.timing.loadEventEnd - performance.timing.connectEnd

Q2. Why is speed index lower & better with these results:

130 assets loaded versus 48 assets.
Which do you think would complete first?

[EDIT]

I only scanned and got it wrong, sorry.
It’s the time-to-first-byte that was the specific issue.
Page had to wait an inordinate length of time until the server started to send data.

[/EDIT]

The reduction of assets should be your primary goal.
Google’s Pagespeed test should help, it has clearer documentation:

https://developers.google.com/speed/pagespeed/insights/

Resolve those issues before taking on too much from this tool.

There’s a Wordpress plugin which may help.

Though I’ve never used it.

Mike

Hey Mike,

Thanks for clearing that up, the difference in TTFB makes sense.

I’ve got a clearer understanding of the approach & what to look for when building my next site, much appreciated.

Kevin