Do you know how long it takes for your organization’s website to load? If the load time is longer than the time it takes to read this sentence, you’re losing potential customers.
That’s because the industry benchmark is 2 seconds. Even 3 seconds load time is problematic. Data shows that bounce rates increase dramatically when page load times are between 2 and 3 seconds—from 6% to 11%. That’s double the bounce rate for a 1 second difference!
Each second more increases bounce rate until data plateaus around 8 seconds and a 60% average bounce rate. That’s powerful evidence that your website’s load time is important.
You might ask what your website’s speed has to do with optimization. The answer is everything.
Why website speed matters
Quite simply, speed has immediate impact on both user experience and SEO ranking.
It’s intuitive when you consider that a slow website delivers a fundamentally poor user experience. One way you can measure this is bounce rate: if a customer loads your site and it’s slow, they’re going to leave quickly.
Why does it impact SEO ranking, though? Quite simply, Google (et al.) wants to deliver a great user experience just like you do. Google doesn’t want to send customers to slow websites because research shows users don’t like slow websites.
That’s why the tech giant intentionally adjusts its algorithm to help users find information more quickly.
Your target should be a 1- to 2-second page load. Anything beyond 2 seconds really starts to impact engagement and traction.
How to improve page speed
Fortunately, page speed can be improved in a number of ways. Unfortunately, most of them come with drawbacks or implementation issues. This is where we take a turn into the really technical.
Getting a page from the server to the browser, so that your customer can use it, involves several elements. Each of these elements provides a potential opportunity to speed up your site and improve your user’s experience.
Let’s explore each of them.
- DNS: When you ask for “teamddm.com”—for example—DNS is the system that tells your computer where specifically “teamddm.com” is located. Think of it as the phone book.
- Web server hardware: Once you connect, the speed of the server hardware provides an upper limit on how fast the page can render and transfer over the network.
- Web server software: The application that runs on the hardware, listening for requests and finding the relevant files, is the web server software.
- CMS: The code that represents your website’s content, theme, plugins, and administration panel is your content management system.
- Database: Most content management systems reference a database of some kind to store and retrieve page content for display and user profiles for managing logins.
DNS
The domain name system (DNS) is a network of servers that reference each other in order to determine where a given domain name (such as teamddm.com) lives on the internet (IP address).
Your computer needs the IP address in order to communicate with the website and show a user the website’s pages and data.
Regarding speed, the first thing to look for is the time to live (TTL). This is how long a given entry in the DNS system should be considered still accurate; a lookup that happens after the TTL expires will re-lookup the domain name just to make sure it’s still in the same place.
This behavior allows two things: websites can move to different IP addresses when needed (moving servers, for example), and your computer can “remember” a given domain name for a while so it doesn’t have to look it up every time. That’s a huge help because each lookup can take more than 1 second.
Ask your tech team: “What is the TTL in DNS set to?”
Some people set it to around 5 minutes, which is great if you’re moving servers frequently. But most websites don’t move that often. You could easily set your TTL to a higher value like 8 hours or even 24 hours.
There is a tradeoff to a longer TTL though. If your disaster recovery system needs to change the IP address, a longer TTL slows down availability of your site for anybody who has recently looked it up in DNS. Their systems will potentially think the old IP address is still valid.
Web server hardware
The hardware your web server runs on is critical to website speed. If it is bottlenecked, your site might run just fine during periods of low traffic, but slow to a crawl when you get a larger number of visitors.
There are a few things to consider with regard to hardware, but generally you want to look for the component that’s running at its maximum in periods of high stress.
Ask your tech team: “Is our hardware bottlenecked?”
Does it have enough processing power (CPU) or is it running out of memory (RAM)? Does it have a big enough connection to the internet (bandwidth)?
For each of those components, the team can usually find a way to increase the scarce resource and improve the speed of the server overall. However, this comes with added cost, and usually, making a change will involve some amount of downtime while the adjustments are being made.
Web server software
Another way to address hardware concerns is to improve the software that it’s running. If you can make efficiency improvements here, you’ll serve pages faster and make better use of the hardware you have. You need to take a holistic approach: look at both hardware and software to find the lowest hanging fruit.
At this point, we should talk about caching. Caching saves any information that takes time to generate somewhere pre-assembled so that it doesn’t need to be generated frequently.
Ask your tech team: “Are we utilizing caching on our web server? Are we measuring how often it is utilized?”
Like each performance question, caching comes with downsides. If you have a dynamic page that changes frequently, caching will effectively slow down how often that page changes for your end users. It will continue to show the “saved” version of the page, instead of regenerating it from the source data. To use it appropriately, your team must be aware of these cases and tune the cache appropriately.
However, many webpages can go days or weeks without changes, so a high-level page cache can substantially improve performance with very little trade-off.
CMS
Your content management system is also an area where you can make use of caching. The CMS itself may generate its own cache, which can be beneficial because the CMS knows which elements of a page are more dynamic than others; this gives it the ability to cache pages that change infrequently while generating pages that change often. The questions above about caching also apply to your CMS’ caching system.
However, CMS software often is able to be extended with plugins or modules.
Here’s another opportunity to ask a questions of your team: “How many plugins or modules are we using on our site? Do we need all of them, i.e., are they all still in use?”
Reducing the number of plugins your site uses can have a dramatic impact on the performance of the site. A poorly written plugin may run code that does a lot of intensive work that simply isn’t necessary on every page load. Even just loading the plugin code itself takes time and, depending on the system, it may have to load the code each time a page is viewed.
Plugins are fantastic ways to augment your website’s capabilities—but make sure you need them and review what you have regularly so you can remove what you don’t use.
Database
Finally, the database. Tuning a database is a whole separate complex topic. However, there are almost always some things that your team can do to improve performance.
Here’s what to look for: “Do we log slow queries? Do we see any patterns in our logs that we should address to speed things up?”
When the CMS asks for data from the database, that’s a “query.” Rendering a webpage can range from 10 or 20 queries up into the hundreds. Most of these queries are extremely simple and fast—but sometimes a poorly written query will make your database do a lot more work. When that happens, it’s called a slow query, and the database software can log that and help your team see and isolate the code that’s creating the query.
The only downside is that it will take time and effort to find the culprit. Database issues tend to be the kinds of things that show up after some time. As your website grows, the data in the database grows as well and queries that used to run quickly become slower over time. Regular monitoring and maintenance will help keep these issues in check.
Where to go from here?
It might feel like the above is a priority list, but, in reality, all of these components of your site need to be working together. Many of the questions posed above will have unique answers for your site. Work with your team to understand how these components work for you. Each of them can potentially impact the other, so take a holistic approach to the problem.
Support your team by making sure they have the time to set up and utilize monitoring tools. Understand that many of the answers to the above questions will have history and context attached, but supporting your team in making changes will help them understand that speed is a priority.
No one wants a frustrated website user. If they leave, they may never come back.