Performance matters
Performance matters to your users and your customers. A fast website generates more money, reduces bounce rate, generates more clicks, ensures better ranking in organic search, increases conversions, and is a key factor to make sure users come back. Again and again.
Speed affects...
Revenue
If your site makes € 1000 per day, a 1 second improvement in page speed brings €70 extra, every day.
Sales life cycle
79% of customers who report dissatisfaction with website performance are less likely to buy from that same site again.
Customer experience
47% of customers expect a webpage to load in 2 seconds or less.
Speed impacts search ranking, mobile visitor happiness, conversion, page views, visit length, bounce rate and many more things… Take your pick!
Time is money
How much is 1 second worth to you?
Science shows that a one second delay, makes conversions drop by 7%.
€
1 second faster load time increase your revenue with
€ 70 every day
The basics of web performance
To have a fast loading web site, every page needs to be delivered to the browser as fast as possible. When the browser has received the data, it needs to be able use this data as fast as possible. These are the key elements of web performance.
Migrate to Servebolt, or just try it for free, and experience loading speeds you have never seen before.
Experience our speed in a couple of easy steps.
First step is sign up for a free account
Sign up today!
Response time
The browser needs to get the HTML. Rendering can not start before the browser has the HTML, and knows what to do next. This is why the response time of the first request is critical for performance. The hosting and code of your website is what impacts the server response time.
Transfer time
The HTML, images and other elements on the webpage need to be transferred from the server to the browser. The distance and the total size of all the assets is what impacts the transfer time.
Render time
When the browser has received the HTML and elements, it has to interpret the code and then make the visual presentation of the webpage. The complexity of the HTML, scripts and stylesheets, and the amount of other assets, is what determines how fast it is possible to do this.
The laws of Physics
Physical truths from the real world also apply to websites
It’s easy to think of computers, networking and internet as something magical. But let there be no doubt, the laws of physics, about time, size and distance apply in this domain too. To give you a quick reminder of what we’re facing:
Distance
It takes more time to move data over longer distances than shorter distances
Size
It takes more time to move large assets than small assets
Volume
Many items are harder to keep track of than few items
Resources
The amount of resources are given, which means they are limited.
NB! Remember that everything uses time
The example of a single page load
1. User clicks on a link
The user clicks on a link, and the browser checks the IP of the domain in DNS, and then sends the request for the page to the server. If the link uses SSL, the client and server negotiate a secure link before the request is completed.
2. Server makes the page
The server receives the request, and runs the code of your website. The website queries the database and file system for all the required bits and pieces and compiles the HTML page.
3. HTML is sent to the browser
When the HTML is made, the server sends it back to the browser over the internet.
4. The browser requests assets
The browser receives the HTML, reads the code, and figures out it needs many more assets. The assets can come from the same server, or other servers that require new DNS lookups and SSL connections.
5. The browser renders the page
While still collecting the assets, the browser starts putting together html, stylesheets, fonts, images and scripts piece by piece.
6. Display a first version
When the browser has received and put together the part of the page that will be visible, it makes the first contentful paint and displays it. Because the page is not finished loading, the user can not interact with the page yet.
7. Make it ready for interaction
More of the page needs to be put together before the user can start interacting, clicking or scrolling.
8. Page is ready to use
When all assets have completed loading, and all scripts have completed their setup tasks, the page is finally ready to use.
So what does this mean in the context of web performance?
Server response time
The response time of HTML, or the time to first byte, is what has the single largest impact on the user experience. If this first request is slow, all other steps in viewing the web page will be delayed.
There are two options for challenging the response time. You can either make the server do the same amount of work faster, or you can reduce the amount of work that needs to be done.
The workload can be reduced by reducing the complexity, make fewer databse requests, and increase the quality of code. Server speed can be increased by changing to faster hosting, or by optimizing the existing hosting stack. Adding more servers will not make it faster.
Network transfer time
The time it takes to transport something from A to B depends on two things. The amount of data and the distance it needs to travel.
Think of internet packages as a DHL delivery lorry. If the packages are more than what can fit in the lorry, it has to ride another round trip for the remaining packages.
Packages will arrive fast if delivery is just down the road, and delivery will be even faster if everything can be transported in one go. Transport will take much longer if the delivery is in a neighbouring city, and even longer if it has to ride multiple times.
So to speed up a web page, you need to make sure to make as few packages as possible, and make sure that the distance from the average website visitor to the server is as short as possible.
Browser render time
The time it takes to render a page is defined by the quality and complexity of the code that needs to be interpreted, the amount of elements and their size, and the speed of the device that runs the browser.
The speed of devices vary a lot, and is not something we can change. To make render time faster, the workload must be reduced for the browser. The less work the browser has to do, the faster it will render.
A webpage becomes fast when the HTML, CSS and scripts are bug, error and warning free. Error free code will also render nicer, and more consistently across different devices.
To further reduce the workload, unused assets should be removed, and the size of others must be reduced.
Experience the difference
Try out different loading speeds
Load complete in 250ms
Load complete in seconds
Philosophy
Less is more for web performance
The simplest way to make a fast performing website is to reduce the amount of work that needs to be done. This is true for response time, transfer time and render time. It makes the server work faster, the network transfers the webpage faster, and the client renders the page faster.
The reward for implementing the philosophical concept of less is more, in addition to making it faster, is that it will be easier to maintain, less prone to errors and more secure. It will likely make your site so fast, that you do not need to spend any additional time optimizing it. It will be fast by default.
Looking for
- Fast response times
- Fast render times
- Scalable sites
- Simple control panel
- Fast database interactions
Then you’ve come to the right place!
Sign up for a free testing account and experience it yourself
Sign up today!Explained
Scalability versus performance
“The server response time for the HTML itself is often the biggest problem, and the hardest one to solve.”
– Patrick Meenan, Web Performance Engineer at Cloudflare, Former web performance engineer at Google, Creator of webpagetest.org
Curious to learn how fast the server response time on Servebolt hosting is?
That’s easy! Create a free test account, and have us migrate your site to our platform so you can test. And enjoy our performance, of course!
Start by signing up today!
Start free trialThe concepts of scalability and performance can easily be explained using cars as an example. A car to get as fast as possible from A to B. If you own a Toyota Yaris, you will not get any faster from A to B if you buy one more. Buying one more Toyota – is what we call scalability. It will only make it possible for you get from A to B with more people. But if you want to get from A to B faster, you should sell the Toyota, and replace it with a Tesla – that’s performance.
Scalability
Scaling is the term we use about a websites ability to handle more visitors at the same time, also referred to as concurrency. This means that there is a difference between serving ten visitors at the same time, than serving hundred or thousand.
The scalability of a website is determined by how much resources it uses, and the amount of resources that are available.
An interesting thing to note, is that the ability to scale usually comes at the cost of performance. This means that you can expect the speed of your website to decrease, if you want to increase the number of visitors you are able to serve at the same time.
Performance
Performance is the term we use to explain the time it takes for a webpage to display. The speed of a website is the time it takes from you click on a link, until the page displays and is ready for you to navigate and use.
There are a whole lot of technical metrics that relate that are used to describe and measure speed, such as time to first byte (TTFB), First Paint, First Meaningful Paint, Time to Interactive and tens, if not hundreds more.
What is slow, and what is fast?
Making your list of 1000 things to fix
Modern hardware uses less power, is more environmentally friendly, and performs faster.
The CPU, with its clock frequency, is essential for performance. When the server delivers a web page, it can only use a single CPU core. Therefore the speed of the CPU core is important. If you have multiple cores, they will be used to serve different page views and run additional server services.
The speed of databases is one of the most common reasons for holding real-time performance back. The web page cannot be delivered to the visitor before database queries are finished processing. Therefore, the speed at which this happens is essential. The speed of databases can be measured in database queries per second.
PHP usually accounts for the largest amount of a webpage’s time to first byte. Newer versions of PHP 7 are a lot faster than its predecessors, so upgrading to newer versions is a very effective way to make a website faster.
Standard hosting stacks are available in operating systems, and they are generally configured for general workloads. An optimized hosting stack does the same amount of work much faster and better. This is hard to do yourself, and you might want to look into providers that deliver managed hosting.
Single computer setups are generally faster than multi-computer or cluster setups. In addition, the cost of maintaining, updating, and operating a multi-machine hosting setup is high. Cluster setups also make deployment and work for developers inherently harder.
Virtualization is a technique used to split up one computer into multiple smaller virtual computers. This process has an overhead compared to running a system without virtualization on a “bare metal” server.
Using as few WordPress plugins as possible, is an effective way to maintain a fast website. Plugins are made of PHP code and add functionality and database queries. When the number of plugins increases, the speed of your website goes down. More plugins also mean more bugs and potentially more security holes.
Poorly coded themes are the most common reason for slow web performance. The most flexible themes with the most configurations and options are often also the slowest.
External network requests are always slow compared to local requests to the file system. Make sure that public web pages do not query external resources in real-time before delivering the web page to a visitor. External requests are best made asynchronously using Javascript.
Webservers log errors to an error log for a reason. For a webserver, handling errors, warnings, and notices takes extra resources. Bugs are logged because they should be fixed. A clean log file with few errors will also make it faster to solve real problems when they happen.
They may seem unimportant, but requests for assets that don’t exist take up a lot of resources. 404 requests can not be cached, meaning the server will have to run code every time a 404 is requested instead of delivering an asset directly from the cache. These resources are better used for scaling.
Oversized images take a long time to load, especially for visitors on mobile devices and slow networks. Images should be correctly sized and compressed, and doing so will improve the overall user experience.
Keep the size of your web site, and the number of assets to a minimum. They all have to be transported from the server to the visitor, and the fewer network roundtrips (RTT) that are necessary, the faster the page will load for the visitor.
The time it takes to download something from a server increases exponentially with the distance to the server. Host your website on the same continent as the majority of your visitors.
Content Delivery Networks can shorten the network distance for visitors to your website and therefore make it load faster.
JavaScript accounts for a large amount of what makes web pages slow on the visitor’s devices. Reducing the amount of JavaScript will always result in faster loading and a faster time to interactive.
Many scripts make external requests. This adds additional DNS lookups and connection to other servers. The connection to your server is open and ready to use, and will serve the scripts much faster than forcing the browser to make external requests.
Libraries like jQuery are slow by design, and add a lot of additional weight to a webpage. Writing vanilla JavaScript will speed your website up considerably.
Every redirect adds an extra network roundtrip for the visitor. Even though a redirect is trivial, like redirecting from /path-to-my-page to /path-to-my-page/ – that roundtrip can be saved by linking directly to the latter.
Loading code that is not used takes time and resources. Keeping the amount of bloat to a minimum will increase the performance of your webpage.
Performance First
The workflow for making faster websites
The core web performance problem
Computers are super fast, and can do millions of operations per second. The speed of computers is not what is holding web performance back, it is the people that make websites that is the main problem.
The Performance First workflow
Performance First is a workflow that is designed to address the core web performance problem. The workflow gives any person working with a website a set of tools to make the right decisions, in favor of web performance, while building a website.
Frequently asked questions
About web performance and site speed
The amount of memory does not affect the speed of your website.
If your website does not have enough RAM, “out of memory” errors will be logged in the servers error logs and the visitor to a web page that exhausts RAM will get a 500 error or the white screen of death. Adding more RAM does not have any effect on how fast your webpage loads.
The number of cores does not affect the speed of your website as long as there are free cores available to handle requests. If the number of cores is the performance bottleneck, you will experience that your website gets temporarily slower.
Yes. The CPU Ghz determines how many calculations the processor can do per second. A CPU that can do more computations per second, will deliver your website at a faster speed.
It’s worth noting that this is not necessarily true across different computers, because the speed of a computer is determined by how fast the computer works as a whole system (motherboard, memory, processor, and storage).
No, quite the contrary. If you split up your website to run across more servers (like Google Cloud or AWS Cloud), you can expect your website to run slower. More servers may increase your site’s ability to scale, but it will not make it faster.
No. The only exception is if bandwidth of the network connection is the bottleneck. A normal webpage does not need more than 10Mbit to be delivered at maximum speed over the network.