Why Your Site Is Slow

Last week at MidCamp in Chicago, I presented a session called “Why Your Site Is Slow.”

In this presentation, I review some of the common answers to the question of why a site is slow. Surface-level technical issues like slow queries and redundant JavaScript files are often blamed when a site is slow, although there are numerous factors that can affect performance. In practice, web teams need to ask “why” repeatedly in order to get to the root cause.

Caching With Clarity

Caching helps a slow site when the team building the site has a clear understanding of what is causing the slowness. The first answer to “why” is often “too many queries.” By asking “why” a few more times, a developer might find that the high number of queries is related to the number of content items loaded on the page. Knowing the specific reason for the high number of queries can help find the best caching layer to mitigate the problem. In Drupal you might use Entity Cache module along with Redis to avoid fully querying for every node.

Make Your Team Faster, Make Your Site Faster

When a developer finds the specific source of slowness, it can be tempting to write a custom fix. Said developer might want to write a custom module to handle the Redis integration. Doing so is (usually) a bad idea. A custom Redis integration module has the chance to make a site faster. But the time spent writing and maintaining it will almost certainly make a team slower. In January I wrote about how inefficient teams are likely to make inefficient sites. Try to define problems in ways that make community maintained modules the solution.

Adding New Features Is Easy, Removing Them Is Hard

A common answer to the question “Why is this site slow?” is simply that adding new features is easier than removing old ones. Keeping a site fast for years after launch is very hard to do. Often the inertia of website management means that a site only gets slower and slower until it is significantly overhauled or replaced. Usually there are few members of a team strongly incentivized to keep a site fast. A site owner is under pressure from numerous stakeholders to include a multitude of features. A project manager may not want to prioritize refactoring for speed when some features still sit in a backlog unbuilt. And developers may not even want to bring up performance draining features because doing so can be misinterpreted as admitting the feature was built incorrectly in the first place. In this environment a “tragedy of the commons” can play out. Ensuring a fast site can be everyone’s job and no one’s job at the same time.

Define “Slow”

A team can make performance more maintainable by defining “slow” upfront and embedding performance measurement throughout their process. Even for fully built sites, it is never too late to establish performance benchmarks and stop further performance degradation. By building up a process around performance, a team can treat it like every other question that has to be answered for a site:

• Is it secure?

• Is it accessible?

• Does it behave as expect?

• Do we know who uses it?

• Is it performant?

When the team knows the answer to one of these questions is “no”, it is easier to take the time to fix it. Clearly defining what “fast” means for a site empowers each team member, project manager, QA tester and stakeholder to raise an alarm when the site slows down. Treat slowness like a bug, and it can be fixed like any other bug.

Integrate Pantheon with your favorite apps and services for the ultimate workflow. Learn more about our Cloud Integration Tools.