Showing posts with label download. Show all posts
Showing posts with label download. Show all posts

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.

Tuesday, June 14, 2011

Retail website homepage weights – why are they so bloated?

I have been working on client eCommerce sites recently and noticed that some competitive ones were very slow to download. Assuming my Internet connection was the problem I looked to stop any other online services that might be running (e.g. Skype, downloads, etc.)… Only to find I didn’t have anything else downloading.

So I loaded-up Firebug (a brilliant and free debugging tool that plugs into Firefox) and checked the size of the homepages I was looking at.

Here’s what I found:

Site: http://www.johnlewis.com/
Total file size: 573k
Onload time*: 7.55s

Site: http://www.marksandspencer.com/
Total file size: 1.5Mb
Onload time*: 13.63s

Site: http://www.hsamuel.co.uk/
Total file size: 1.3Mb
Onload time*: 16.28s

Site: http://www.debenhams.com/
Total file size: 1.1Mb
Onload time*: 8.16s

Site: http://www.goldsmiths.co.uk/
Total file size: 1.1Mb
Onload time*: 7.44s

Site: http://www.bhs.co.uk/
Total file size: 720kb
Onload time*: 7.39s

Site: http://www.morrisons.co.uk/
Total file size: 1.1Mb
Onload time*: 7.22s

Site: http://asda.co.uk/
Total file size: 866k
Onload time*: 9.33s

Note: This isn’t an exactly scientific test, being conducted once on a PC with network traffic. But even as indicators of total file size and download time, they do start to paint a pretty interesting picture.

However these figures pale into mere insignificance when compared with the weight of the George Style Blog http://georgestyle.george.com/ set up to accompany their support of Graduate Fashion Week. This homepage tops the scales at a whopping 2.8Mb (or to put it another way, not just one but two entire old HD floppy drives from the past!).

You really have to ask why this sort of bloated homepage shenanigans is still going on in this age of web page optimisation…. and whether any of these UK retailers are aware that an increase in page delivery speed can significantly improve conversion.



*Onload time is approximately the time taken for the page to start to display. Other elements are still downloading and the entire page might take much longer to fully render.

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, 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).