Showing posts with label speed. Show all posts
Showing posts with label speed. Show all posts

Tuesday, October 30, 2018

What question are you really trying to answer?

Agile
Digital Transformation
Self-service technology
Faster delivery
<yawn>

Heard it all before? Yes, so have I... numerous times and across many different clients.
Each is craving to "move to become a digital organisation" or "reinvent their online proposition to embrace change" and other similar modern and (to be honest) pretty meaningless statements about themselves.

But I think they are approaching this the wrong way. 

On the basis that each company exists to provide a product or service to another (person or company)... why the heck are they not focusing on asking more questions about what their customers need? Or questioning what stops their valuable users buying/using/engaging more? And more fundamentally... why aren't more people tasked with trying to answer those questions with the creation of better products and services, increasingly delivered as software?

So rather than saying "we need to redevelop our website to improve our KPIs"...
You need to ask "why don't we make it easier for customers to convert?"

And rather than stating "we need to reduce the number of clicks in our online booking process".
You need to ask yourself "why do customers seem to have a problem getting past the 4th page?"

It is only then that you get to the creation of an insight-based hypothesis to change a process or product. 

Friday, January 29, 2016

Will One Line Of Code Help Your SEO?

There's been quite a lot of discussion online (and a little offline) about a recent blog article called: How I Sped Up My Site 68.35% With One Line of Code

I think the biggest buzz about this article has been in the SEO community, who suddenly got all excited about a magical way to speed up web pages. Mentioned by Moz (the organic optimisation industry's catnip) you could be fooled into thinking that one person had suddenly found a way to massively boost a site to the top of the results pages.
Note: For those who don't know, the speed a page downloads is cited as one of the numerous factors taken into consideration when search engines such as Google rank (judge) your site... having a much faster page load speed with just one little line of code would be fabulous.
But alas, that's not the case.

You see, I think this article is misleading as it explains how to use an HTML tag called "rel-prerender".

For those who don't know, the rel-prerender tag is used on a website to place into computer memory the next page the site developer expects the users to click on. For example, Google sometimes use it in their search engine results pages (SERPs) to make the experience of clicking on the first result much quicker.

To explain how this works on your own website, let's imagine you are on page 1 and want to automatically call-up page 2 behind the scenes (so that it appears very quickly). You therefore insert the "rel-prerender" tag in page 1 to call up page 2 before it is clicked on.

Where might you use this?
Well you might us it on a login-page (page 1) where the logged-in page (page 2) is usually the next step. You can even use it in an eCommerce site to pre-render the shopping cart I guess.... BTW: DO NOT DO THIS!

But as you would expect, there's a catch. Pre-rendering page 2 is the act of requesting a view of it in advance. So people arriving on page 1 can trigger a page 2 view without ever seeing it and in many cases they won't. This means that in some analytic packages this is recorded as a page impression (not in GA, it's clever like that) and ads on that page may be triggered even when nobody's there to see them. Plus it also adds load onto your servers whenever a page is requested, so don't tell your tech support person you're adding further load onto the system that may never be used.

So does it have an effect on SEO? Well I may be wrong.... but I really can't see how it helps organic site optimisation as you are not speeding up the render of the page you want to appear in the SERPs (Page 1). What you are actually doing is speeding up the potential delivery of the next page (page 2) you expect the user to see.  And that's not SEO, that's a caching strategy.

Sunday, October 25, 2015

This Shit Is Gonna Get Faster

The pace of digital and technological change has accelerated over the last couple of decades.  Since I started work in the late 1980's everything has changed:

  • There's no such thing as a job for life
  • Wearing a suit to work does not make you the most important person in the room (or indicate you're the highest paid)
  • More and more things (products) now exist as software: music players, cameras, audio/visual editing tools, etc.

To give you some idea of the speed of innovation, TechCrunch launched its Disrupt conference in 2011 where just 45 start-ups demonstrated their products & services. This year at the same conference.... there are 5,000 of them.

However it is my belief that this speed of change, although on an upward trajectory, is going to get faster.

How fast? I've no idea. But if I'm right, the tools for delivering better and more customer-focused products will only get more efficient and the competition to create new and improved services will only get stronger.

Things are going to get crazy and brilliant at the same time... and I'm looking forward to it. So maybe sometime soon that suit of mine will one day stay in the wardrobe and only get used for family events.

Friday, August 1, 2014

What factors affect your conversion?

Everyone who runs an eCommerce website is hooked on conversion as the vital key performance indicator to improve. And quite rightly…. It is the one metric that tells you how well your website it turning lookers into bookers (or browsers into buyers if you don’t like things rhyming and prefer alliteration instead.).
So what affects conversion? Well there are a number of factors that have an influence including:

  • Usability
    How easy your site is to navigate and transact with
  • Security
    How well your site conveys and actually take steps to ensure the safety of customer data
  • Content
    How well  the site text and imagery informs &  supports the sales process
  • Layout
    It’s not just how much you have on a page, it’s where you put it that counts
  • Speed
    How quickly your site appears & displays affects bounce & therefore conversion
  • Aesthetics
    How it looks also affects how it converts (try changing the colour of a few buttons if you don’t believe me)

All you have to do it find out what works for your customers.

Friday, August 23, 2013

Further musings about Meta tags

In a recent posting, I mentioned how the Meta Keywords tag is no longer used by search engines to rank websites. Even Google now officially states that they don't bother with it... so as a search engine optimisation technique, I wouldn't spend any time on them.


This therefore raises the question of whether you should even include it in your site or if you should remove it.

So here's some thoughts on the pros and cons of keeping this tag in your site.

Remove them:
  • Your site HTML code can easily be seen by viewing the source in your browser - PC's typically. This means the keywords always on display and can therefore give your competitors insight into the keywords you are targeting.
  • Although a lot of people are now on super-fast home broadband and work connection, there are still a number of users on slower download speeds ... including those on mobile devices. Although removing a line of HTML code isn't going to make your site noticeably quicker, as one UK supermarket slogan goes... every little helps.
Keep them:
  • HTML / Accessibility standards change and evolve from time to time. Therefore there is the chance that the Meta Keyword tag could be brought back into use (although very unlikely I guess).
  • Some on-site search mechanisms might still use them to classify pages on your own web presence 
  • If you're after throwing your competition off the scent of what keywords you're actually targeting, you could always put false ones in your meta tags... but then, that might be a little too much

Friday, December 14, 2012

UK finance comparison sites are pretty optimised

Today I did a check on the top four finance aggregator sites to see how they compare with each other. The results were found using the Firebug and Google page speed plugins for Firefox (in case you wondered) and make for interesting reading...

moneysupermarket.com
Homepage weight: 539.1K
Number of items: 47
Page Speed Score: 82/100

comparethemarket.com
Homepage weight: 488.9k
Number of items: 42
Page Speed Score: 84/100

confused.com
Homepage weight: 339.9k
Number of items: 63
Page Speed Score: 88/100

gocompare.com
Homepage weight: 800.4k
Number of items: 65
Page Speed Score: 87/100

It's good to see that as an industry matures and as companies within it fight for supremacy, they optimise their web presence in every way. The high page speed score shows they are all taking download / display time seriously, with perhaps only gocompare.com having a worrying page weight of over 800k

Tuesday, May 3, 2011

Is your website driving away customers?

Yes, that's right.... your website could be harming your business rather than helping it. How?

Well, did you know that 57% of visitors will abandon a site if it doesn't load in 3 seconds?

Yup! Although internet speeds have increased significantly over the last few years (my ISP is currently offering broadband at between 8mbps to 40mbps)..... modern websites tend to be full of complex code and large images. And to make matters worse... Internet users now expect websites to download faster than ever before.

So all that bloated script, photos and video (in a lot of cases), means those key pages that you're trying to drive users to take a long time to fully render in their browser. And all the time the user is waiting for this to happen.....they are only a click away from selecting another site.

Potentially your competition's.

Monday, April 18, 2011

Website Performance – Are you doing enough?

If you’ve read my earlier postings on the beneficial effects that webpage performance improvements can have on SEO (and this recent video where I also give a basic explanation of the eCommerce implications), then you will know I’m pretty keen on the subject of website performance optimisation. This perspective is all part of my overall view that a company’s website needs to work as hard as possible and at all times.

In my opinion, minimising the time that content takes to appear on the average user’s browser (or range of browsers) should have the same sort of priority as reducing call waiting times in a customer services centre or ensuring diners are quickly seated at a restaurant. In all three of these cases, a faster time to deliver the service is what matters.

Speed counts… and in the case of a site that transacts, speed can have a real impact on the bottom line.

So what’s a fast page response time and what’s a slow one? The complex answer to this question is “its complex”, but luckily the simple answer is “it’s simple, there are several online sources to help you”. Including: http://pagespeed.googlelabs.com/ This is the first place I would visit to measure the speed of your website pages. The performance from Google is scored and suggestions given to improve your page speed in: high, medium & low priority (as well as other best practice recommendations). For example the homepage of http://www.idealinterface.co.uk/ gets a score of 85/100 http://pagespeed.googlelabs.com/#url=http_3A_2F_2Fwww.idealinterface.co.uk&mobile=false Note: You can currently only use this site to measure one page at a time. It is not possible (as far as I am aware) to record a series of actions.... such as a user’s typical transaction process through your eCommerce site.

So don't dismiss the subject of website performance. You may find it could mean the difference between a good website and great one.

Monday, February 28, 2011

Why is it important to have an e-commerce website that loads quickly?



In this latest episode of online video interviews I set out why is it important to have an e-commerce website that loads quickly.

Here I talk about the current expectations in page download time and quote the popular book by Steve Krug "Don't Make Me Think".

Tuesday, November 17, 2009

Page response times

Our work at Ideal Interface leads us to speak with many different clients who want a leading ecommerce website. So whilst specifying this solution we try to define the functional requirements (such as what interactivity the page needs to provide) along with the non-functional requirements... such as what the page download / response times should be.

Now... in my experience this actually takes some explaining to define what you actually mean and how you going to measure it before you are likely to get agreement from the client.

Firstly, its important to understand that all things on the Internet are definitely not equal. Connection speeds (bandwidth), latency, the browser you are using and the speed of your device all contribute to the differences between one user's experience and another.

Q: So, what is an acceptable page download time?

A: This depends on who you ask

For a long time I have used the words of Jakob Neilson, the web's foremost usability expert, who has tackled this subject several years ago. He gives the timescale for user attention between 1 and 10 seconds, after that user flow is broken and users tend to leave the site:
http://www.useit.com/alertbox/timeframes.html

More recently, two seconds has been given by Akamai as the new average of an online shopper’s expectation for a web page to load:
http://www.businesswire.com/portal/site/google/?ndmViewId=news_view&newsId=20090914005141&newsLang=en
(I guess you would expect this from a company who provide fast Internet delivery services!)

However, there is no doubt in my mind that a user's expectation of page download times is gradually increasing. So just because bandwidth speeds are increasing, there is no reason for site owners to increase page size accordingly (or to provide complex or badly-written client-side code that takes ages to render in the browser).