Three Things Every Drupal Site Needs to Kick Ass

You’ve built a beautiful Drupal site, but will it stand the test of time? If it’s slow, hacked, or unmaintainable, it may not be the success that you hoped for.

One of the services we offer our clients is a Lullabot Best Practices Audit. As a part of that audit, we look closely at three areas of your site: Security, Performance, and Stability. In this article, I will discuss some of the questions we ask and the tools we use to grade how well your site performs.

You’re no doubt already aware of these three areas. The reason they become a focus in our audit is that they are often the neglected parts of our sites. It's easy to get in a pattern of prioritizing cosmetics, features, and bug fixes without realizing how all of those affect the foundation the site is built on. When that happens, you risk losing customers, damaging your reputation, leaking sensitive information, or perpetuating broken processes, all of which—whether you like to admit it or not—ultimately cost money.

Security

Security is not a deliverable, it's a discipline. That means that having a secure website is not something we ever complete, but is an ongoing process to adhere to and improve. The costs of ignoring that process can be severe.

The security of your site and infrastructure is only as good as your security process. Here are a few questions we might ask about your Drupal security process as a portion of the audit:

1. Is your security process well documented and followed?
2. Who is monitoring Drupal Security Advisories and announcements? How?
3. How often are security updates applied?
4. What is the process in place for Zero-day vulnerabilities?
5. How regular are security audits performed? 1. Are you using any automated tools to scan new work for common security vulnerabilities?
6. Is HTTPS in use? Everywhere?

If you don't have good answers to those questions, it could mean your site and infrastructure are vulnerable to attack. In fact, it might have already been compromised without your knowledge.

Helpful tools to consider

There are some helpful tools out there to aid in performing your own audit of the security of your Drupal site.

1. Security Review Module provides a status page on your Drupal site and Drush command to check for common security vulnerabilities such as file system permissions, XSS vulnerabilities, protection against arbitrary code execution, etc.  
2. Hacked Module performs an audit of all core and contributed code to see if there have been modifications. 
3. Coder Module does some basic checks to ensure that text is properly sanitized In addition to checking that coding standards are being followed.
4. Qualys SSL Server Test is a free service that will perform a thorough analysis of a public SSL certificate and provide you with a graded result.

Some of these tools come with command line versions. By combining those with a continuous integration tool, you could set up regular and ongoing security testing of your code and configuration.

Performance

We all want fast sites. Among other things, a fast site means happier users and higher search engine rankings. If your site makes you or your organization money, having a slow site means higher page abandonment, and ultimately lost revenue.

None of us have slow sites on purpose. Performance issues can arise gradually over time without an obvious reason for how and when they began. Spending time or money to investigate and fix performance issues can be deemed less important than more desirable or “measurable” initiatives.

Here are a few questions we might ask as a part of an audit:

1. Are frontend and backend performance being monitored? With what?
2. What sort of caching layers are in place?
3. Do you have analytics that show traffic patterns, such as country of origin, graphs of throughput over time, and the like?
4. Have you had any recent site outages that you suspect are performance issues?
5. Are you aware of slow pages or interactions on the site?
6. Have users complained about any slowness?
7. Are there any libraries or methods used to increase frontend performance?
8. What sort of image optimizations are being done?
9. Are there ways that you optimize performance for different screen sizes (mobile/tablet/desktop)?

Helpful tools to consider

There are some helpful tools out there to aid in performing your own audit of performance.

1. XHProf or the Tideways PHP Profiler: PHP profiling tools that can help you identify bottlenecks on specific pages. XHProf works with PHP 5.6 and below, whereas the Tideways PHP profiler is compatible with PHP 7 and below, and can act as an XHProf replacement. There is an associated Drupal module that I recommend (along with this patch if you have a lot of AJAX interactions), or you can use either with xhgui. Tip: look at exclusive wall time to find the functions that are the slowest on a page.
2. New Relic or similar: We love New Relic for being able to monitor traffic and performance in real time, create alerts for specific events, and dive deep into function traces to isolate bottlenecks. In addition, it gives you the ability to create customized dashboards to display pretty charts and graphs from performance data on your site. New Relic can monitor browser, application, server performance, and more. There are New Relic alternatives that likely offer similar features. Choose a tool and use it.
3. Google's PageSpeed Insights, YSlow, or similar: Tools that give you practical advice on how to improve the front-end performance for your users. It may suggest reducing the number of requests by using image sprites or combining JavaScript files, or it might recommend simplifying the DOM to reduce the number of elements the browser needs to parse. It goes through a whole set of tests and gives you practical suggestions that can sometimes lead to easy performance gains.

Stability

When we investigate the stability of your site, we look at the architecture of the site, the breadth, and depth of developer documentation, the quality of the site's code, and the process by which that code gets written and deployed to production. When best practices aren't followed in these areas, it can result in a platform with a slow development cycle, fragile releases that require everyone to be present in case anything goes wrong, and vendor lock-in, forcing you to work with only developers that understand the unique complexities of your site. Even if nothing brings the site down during a release, that is a very expensive process, and optimizing it can save your organization time, money, and heartache.

Here are a few questions we might ask as a part of an audit:

1. What documentation exists on the site architecture, development process, and deployment process? How well is it maintained? Who has access to it? 
2. Does the development team have agreed upon coding standards?
3. Do the developers peer review each other's code?
4. Is there automated testing or human testing as a part of the development and deployment process? Does that testing happen before or after the code is merged in?
5. How much of the release process is scripted or automated?
6. How many people are typically present for a release?
7. Does the site go down often? If so, are root cause analysis (RCA) documents provided by the development or infrastructure team?
8. Does your team have a well-documented rollback procedure?
9. How does your team deal with technical debt?

Helpful tools to consider 

Here are some tools we use that help us sleep at night.

1. Linting tools can get all of your developers in agreement on code formatting, which helps tremendously in the peer review process, and ultimately in the stability of your site. EditorConfig is a nice emerging format that can be used to enforce agreed upon standards in your developer’s actual text editors or IDEs. In addition, Drupal Code Sniffer (which is a part of Coder module) can be used in those same text editors to ensure that Drupal code is following Drupal coding standards. While having your developers use these linting tools in their editors is fantastic, ideally they should also be a part of an automated test that runs on every pull request.
2. Automated Testing using PHPUnit, Behat, Nightwatch, or other mixture of functional and unit testing tools can improve the stability of the platform immensely. While the initial investment may seem costly at first, the money saved over time is significant, and the peace of mind is priceless.
3. Tugboat or another continuous integration tool can build complete working websites for new features or bug fixes before they get merged. That means your QA team or stakeholders can sign off on things before they ever make it into your codebase. In addition, it can run the linting and automated tests you implemented above and report the results back to the developer before that code gets reviewed or merged. Saved time is saved money.

Your website's success

Security, performance, and stability are the unsung heroes of your website's success. When they are neglected, it can cost dearly. Whether it's a damaged reputation, customers lost, services hacked, or just plain stress from the platform, these all ultimately mean lost revenue. Take some time to invest in your website's success by performing a Best Practices audit on your site.

Next steps

The above is a sample of some of the things we might investigate as a part of a Best Practices audit, but your website and needs are unique. We hope this article serves as either a blueprint to design your own audit, or the start of a conversation to get some help where you need it. We collaborate with you on our Best Practices audits to best fit your project’s needs.

If you're thinking of performing your own Best Practices Audit, let us know in the comments below. If you'd like some help from Lullabot, reach out—we'd love to partner with you in writing your website's success story.