How Fast Are My Web Pages?

Share this on:

57th blog post of 100

Website rendering speeds

In a previous post I checked out what Google's PageSpeed Insight tool told me about how fast my web pages rendered.

In that test I did the front page of my site. Today I re-ran the test on the page and got different results:


  • speed: 59/100
  • user experience: 93/100


  • 83/100

That was a lot lower for speed on mobile than last time, and desktop experience was down by 10%.

The error messages have three levels red, orange and green. The colours have different significances:

  • Red: 'Should Fix'
  • Orange: 'Consider Fixing'
  • Green: 'Passed Rules'

The first time I tested the site the scores where fairly high and I had no red warnings, green for desktop and orange for mobile, so I was happy at that point.

But this time I had a low score for mobile 59 and a orange 'Should Fix' warning: "Get rid of render blocking javascript and CSS"

So I have for a long time hated carousels, those images sliders you see on most web agencies web sites. I had one, because everyone else had one and I thought any prospective clients would expect me to have one too. I was using the jQuery library for the carousel and this was one of the blocking files, so now I had my excuse to get rid of it and the associated carousel.

But I was also using jQuery for the drop down menu for the site when being viewed on mobile. So I had a bit of a closer look at the code and worked out that I didn't need jQuery at all and could use just a few characters of javascript:

So I removed jQuery and dumped the carousel.

I also added the asynchronous Google Analytics code as I was using the old synchronous code.

The hardest thing I had to deal with though was the font I use from Google which I liked and was determined to keep. PageSpeed was complaining about it.

So rather than have it as a linked file I worked out how to embed it in the document. Which, in the end, I'm not sure is such a good idea as it's making every page bigger and every page gets downloaded with the same embedded font rather than just being downloaded as a separate file and cached for every page to use.

But PageSpeed seemed to prefer it that way... (I might need to go and double check that)

Anyway the process to do that was:

  1. Downloaded the font from Google. Yes, they let you download all their fonts ( Add your font to your Collections then go to the little down pointing arrow at the top right and select "Download the font families in your Collection as a .zip file")
  2. Then convert the font it to base64 at
  3. Then embedded it in some style tags at the head of the page like this:
  4. <style>
    @font-face{font-family:'Fjalla';src:url(data:font/tff;base64,AAEAANV....0I4gY2FyZWZ1bGx5IGF) format('truetype')}
  5. The font I used is called 'Fjalla One' and I had it as 'Fjalla+One' but it didn't work like that so I changed the name of the font to just Fjalla (and so had to change it in the CSS also)
And finally I also minified the css at the website:

After all those changes I had score of:


  • speed: 85/100
  • user experience:100/100


  • 95/100

So, improved scores and got rid of the red 'Should Fix' warnings. And 100 for user experience on mobile.

There are still 'Consider Fixing' warnings, I'm still getting "Eliminate render-blocking JavaScript and CSS in above-the-fold content" and it tells me it's my css file (there is no javascript now). But, what exactly? I don't know, I shall leave that for another day. As long as I don't have any red warnings I can live with that.

What about other pages?

Other pages should have also benefitted from the changes I made on the front page as the pages on my site share templates that they are built from.

So next I try in the PageSpeed tool.

It has a red notice "Should Fix" message: "Size tap targets appropriately" for user experience and scores:


  • speed: 84/100
  • user experience: 87/100


  • 93/100

Using CSS I increase the font sizes of all the links on the page so that they will get bigger when the site resizes for mobiles, this gets rid of the red warnings and I now have a score of:


  • speed: 84/100
  • user experience: 94/100

desktop: 93/100

That does the trick and gets rid of the red warnings, I'm happy.

Now what about my actual articles in the journal as I still have the social media plugins, which I suspect will be doing a lot of blocking to the rendering as they dynamically add javascript and elements

So I test one of the journal pages: and get a score:


  • speed: 70/100
  • user experience: 75/100

desktop: 87/100

That's low compared to my new scores for the other pages, and with mobile getting two red "Should Fix" warnings.

And as I suspected it is the social media icons I add to every blog post using the addthis widget.

OK, I've just checked and no-one has used the social media buttons on any of my last 56 posts so i may as well go for a stripped down site that passes the PageSpeed Insight tests.

I can look into other ways of adding social enablers that are less 'blocking' at a future date.

So I removed the addThis social shares widget and the PageSpeed Insight's got worse!


  • speed: 57/100
  • user experience: 75/100

desktop: 81/100

Now with a red "Should Fix" on the Desktop page too!!!

Some of this relates to the 'recaptcha' on my comments, I have used other ways to block spam bots before so I can get rid of that, lets try that and see what happens.

OK, that's done, which will probably leave me open to a cascade of automated spam, as my blog is using Articles (a MODX plugin), which unlike Formit (another MODX plugin), doesn't have alternative spam measures, which is what I was thinking about before. ( Unless Articles uses Formit, I'm not sure, but it doesn't seem to make the Formit options available )

So lets deal with some of the other issues to see if we can get rid of those red warnings.

I use jQuery again in the journal for code highlighting were there are code examples, but I have the library on every page, even though there is no code, that is a bit unnecessary, I can make it a TV (MODX Template Variable) and just added it the appropriate pages

OK removed the code highlighter but, and still not quite there yet...

OK, I've taken drastic measures I've removed the code highlighting, though now my code doesn't look as pretty it's still readable. My site can cope without it, and there's probably a leaner way to do it with css. And small snippets of code look OK anyway in just a monospaced font, they are still readable.

I had previously put the code in <pre> tags, a requirement of highlighter, and this causes the width to be as wide as the line of text with no wrapping to fit with other objects on the page, which is not conducive to responsive design, so I've changed the <pre> tag to a <bockqoute> but with a class="code" and set to a monospace font.

This was the last red warning I was getting on from PageSpeed, it got to the point that it was saying the screen was too wide because I had a long string of text in a url which wouldn't wrap to 320 pixels wide so I just had to put some white spaces in it to break it apart and make it wrap.

I may have to check every page on the site!

There are still improvements to be made, but that will do for now, the last score for is:


  • speed: 85/100
  • user experience: 99/100

desktop: 95/100

Which looks pretty good to me for now.

Share this on:
Mike Nuttall

Author: Mike Nuttall

Mike has been web designing, programming and building web applications in Leeds for many years. He founded Onsitenow in 2009 and has been helping clients turn business ideas into on-line reality ever since. Mike can be followed on Twitter and has a profile on Google+.