There's no shortage of generic web performance optimization advice out there. You probably have a checklist of things to do to speed up your site. Maybe your hosting company sent you a list of performance best practices. Or maybe you use an automated recommendation service.

You've gone through all the checklist compliance work, but haven't seen any change in your site's speed. What's going on here? You added a CDN. You optimized your image sizes. You removed unused code. You even turned off database logging on your Drupal site and no one can read the logs anymore! But it should be worth it, right? You followed best practice recommendations, so why don't you see an improvement?

Here are three reasons why generic performance checklists don't usually help, and what really does.

1. Micro-Optimizations

Generic performance recommendations don't provide you with a sense of scale for how effective they'll be, so how do you know if they're worth doing?

People will say, "Well, if it's an improvement, it's an improvement, and we should do it. You're not against improvements are you?" This logic only works if you have infinite time or money. You wouldn't spend $2000 to make changes you knew would only save 1ms time on a 10s current page load.

Long performance checklists are usually full of well-meaning suggestions that turn out to be micro-optimizations on your specific site. It makes for an impressive list. We fall for it because it plays into our desire for completion. We think, "ROI be damned! There's an item on this list and we have got to do it."

Just try to remember: ABP. Always Be Prioritizing.

You don't have to tackle every item on the list just for completion's sake. You need to measure optimizations to determine whether you're adding a micro-optimization or slaying a serious bottleneck.

2. Redundant Caching

In security, the advice is to add more layers of protection. In caching, not so much. Adding redundant caching will often have little to no effect on your page load time.

Caching lets your process take a shortcut the majority of the time. Imagine a kid who takes a shortcut on her walk to school. She cuts through her neighbor's backyard instead of going around the block. One in 10,000 times, there's a rabid squirrel in the yard, so she takes the long way. Her entrepreneurial friend offers to sell her a map to a new shortcut. It's a best practice! It cuts off time from the original full route that she almost never uses but it's longer than her usual shortcut. It will save her a little time on rabid squirrel days. Is it worth the price?

The benefit of a redundancy like this is marginal, but if there's a significant time or cost investment it’s probably not worth it. It's better to focus on getting the most bang for your buck. Keep in mind that the time involved to add caching includes making sure that new caches invalidate properly so that your site does not show stale content (and leave your editors calling support to report a problem when their new post does not appear promptly.)

3. Bottlenecks or Bust

Simply speaking, page load time consists of two main layers. First there is the server-side (back-end) which creates the HTML for a web page. Next, the client-side (front-end) renders it, adding the images, CSS, and JavaScript in your web browser.

The first step to effective performance optimization is to determine which layer is slow. It may be both. Developers tend to optimize the layer of their expertise and ignore the other one. It's common to focus efforts on the wrong layer.

Now on the back-end, a lot of the process occurs in series. One thing happens, and then another. First the web server routes a request. Then a PHP function runs. And another. It calls the database with a query. One task completes and then the next one begins. If you decrease the time of any of the tasks, the total time will decrease. If you do enough micro-optimizations, they can actually add up to something perceptible.

But the front-end, generally speaking, is different. The browser tries to do many things all at the same time (in parallel). This changes the game completely.

Imagine you and your brother start a company called Speedy Car Cleaning. You want your customers to get the fastest car cleaning possible, so you decide that while you wash a car, your brother will vacuum at the same time. One step doesn't rely on the other to be completed first, so you'll work in parallel. It takes you five minutes to wash a car, and it takes your brother two minutes to vacuum it. Total time to clean a car? Five minutes. You want to speed things up even more, so your brother buys a more powerful vacuum and now it only takes him one minute. What's the new total time to clean a car?

If you said five minutes, you are correct. When processes run in parallel, the slowest process is the only one that impacts total time.

This is a lesson of factory optimization as well. A factory has many machines and stations running in parallel, so if you speed up the process at any point that is not the bottleneck, you'll have no impact on the throughput. Not a small impact - no impact.

Ok, then what can we do?

So is it worthless to follow best practices to optimize your speed? No. You might get lucky, and those optimizations will make a big impact. They have their place, especially if you have a fairly typical site.

But if you don't see results from following guesses about why your site is slow, there's only one sure way to speed things up.

You have to find out what's really going on.

Establish a benchmark of current performance. Determine which layer contributes the most to the total time. Use profiling tools to find where the big costs are on the back-end and the bottlenecks on the front-end. Measure the effects of your improvements.

If your site's performance is an issue, ask an expert for a performance audit. Make sure they have expertise with your server infrastructure, your CMS or framework, and front-end performance. With methodical analysis and profiling measurements, they'll get to the bottom of it. And don't sweat those 'best practice' checklists.