Welcome to Website Speed is a Ranking Factor: Step Up Your Speed from Snail to Cheetah, part three. In part two we looked at how files are transferred between the browser and website. Now it’s time to see what’s inside the machines used to view the web.
Ever since Steve Jobs started the portables revolution, the number of different kinds of devices connecting to the internet has exploded:
Along with these innovations come tremendous improvements in operating systems, screen technology, the amount of memory, storage capacity, and processor core count.
The number of possible variations in what your blog audience members are using to read your write-ups is enormous.
How do you make design decisions to ensure people are having a positive experience?
Even with all these differences the fundamentals haven’t changed. The speed of an Internet-enabled device comes down to two things:
A good analogy for how these work is a man in a factory working on the contents of various boxes.
He can reach into any box, fiddle with what’s inside, and put it back into another box. The more boxes he has the more complex tasks he is able to manage, and the faster he works the faster the tasks are completed.
In this story the man is your processor and the boxes are memory.
We use the word memory in various ways. We say “How much memory does your flash drive have?” but also “This phone has 500 megabytes of memory”.
Strictly speaking, this isn’t the same thing.
The memory on your phone is called RAM. These are black chips welded onto a green circuit board that holds all the main components of your electronics together.
It’s both very expensive and very fast – about a hundred times more expensive per unit of memory and around a thousand times faster than the hard drive.
The point I’m trying to make is that it’s all the same thing; hard drives, RAM and your flash drive. There’s this common joke among techies that the middle-aged keep asking how much memory their hard drive has on it.
This is bad grammar since you’re supposed to say “how much space”. But really the word is right.
The space on your hard drive allows for more information to be accessible to your processor, hence it is memory. It’s just built differently.
Hard drives are black boxes containing a metal disc that spins like a record. This makes them cheap to make but slow to read. And this is the important difference between them and RAM.
Those black chips sitting on the green board allow your processor to manipulate the contents of boxes thousands of times faster than with a hard drive.
Imagine you are working at your desk and you need to refer to a book that’s on your bookshelf.
First, you’d have to get up from your chair and walk over to the shelf. Then you’d have to find the book, pick it up and bring it back to your desk.
This may seem a strange story to lay out but it’s actually an excellent analogy for how a processor works.
You see, the desk is the processor and the shelf is RAM. Since the shelf is nearby you needn’t travel far to get it.
Now imagine what it would take to get something from the local library. You’d have to get up from your desk, walk out the office, down the stairs, out the building, walk to the main road, hail a taxi, drive to the library … You get the idea.
This is what it’s like for a processor to get information from your hard drive compared to RAM ‑ it’s that much slower.
And as I mentioned, the speed comes for a price. That’s why your 16GB flash drive costs a few dollars while Apple makes a big deal of the 1GB RAM on your four hundred dollar iPhone.
The processor, the man doing all the work with the boxes around his desk, can also be either fast or slow; not nearly as pronounced as the speed variations between different kinds of RAM though.
The iPhone 6’s A8 chip is may be twice as fast as the one in the iPhone 5’s A7. What does this mean to us?
It means that once all the downloading has finished everything else that is left to do will be quicker.
The boxes have been filled and now it’s time to arrange them:
How this affects responsiveness is more subtle than one might suppose. Remember our discussion about compression. If you send a compressed file to someone, the transfer speed is increased.
However, before you can put it up on screen the processor has to do many calculations in order to decompress it.
This takes time, and depending on the processor it could be more time than you saved during transfer. Thus, in theory, compressing a file could slow your site down for some people!
So compression isn’t a magic solution, because decompression uses the processor.
It will improve download rates, yes, but there’s a trade-off.
For instance, you may find that if you compress your images on your site using a better algorithm (making them smaller) your iPhone 6 users will feel things are quicker while your iPhone 5 clients will actually experience a slowdown.
This makes designing for speed very difficult. Remember the two ideas that form all of computing?
In part one and two we looked at the first part, transfer, and showed how you can optimize for speed just by focusing on making things smaller. There is a clear strategy for that – but not so with the second part, processing (i.e. the device).
Because there are no standard device configurations, and because of the complex interplay between things like compression, processor speed and download size, there is no single approach one could develop to optimize your site for any and all devices.
The only workable solution I’ve seen is monitoring:
I’ll cover how one might do this in the next part of this series. First it might be worth laying out my argument again.
Once again, the overall picture consists of these two things: moving files across the net, and the receiving device that pulls these files together to display the site.
You don’t know what kind of connection your users are going to have. They could be on a fixed broadband line with a stable throughput, or they could be on a 3G cellphone line with fluctuating connectivity.
Therefore the only way you can increase your likelihood of them having a good experience is by making the size of your site (in terms of how much they need to download) as small as possible. But …
This seems to contradict the previous point. However you should cut as much crust as you can.
Be strict about what you leave in your site and what you don’t.
Size really is the most reliable way to make things faster. But you need to work it with a two-pronged approach, which is why …
Because each device is different, and because the connection between download rates and processor speed is not simple, you cannot take a disconnected approach to designing a quick site.
Though you should try to make things better from an isolated standpoint, you also need to have a strategy in place where you are watching what is actually happening – what your user experience is like and why.
We’ll talk about how we can do this in part four.
I suppose I could make another statement about Yin and Yang – it seems apt. We need to have a structured, top-down approach to designing our site (using philosophies like “make it as small as possible”), but that isn’t enough.
We also have to listen to what is happening and make adjustments as needed. Be smart up front, but don’t think you have all the answers.