Analyze requests and application code for performance

When analyzing a site’s performance, specific types of site requests and the pages that receive the largest amount of traffic should be the subjects for analysis. The application’s codebase should also be regularly scanned for opportunities to improve performance.

Request types

The performance of the most frequently used pages and their templates—including the homepage, major landing pages, the single page/post templates, and category/archive templates—should be analyzed most often and most thoroughly.

As an example, the performance of these requests should be analyzed with performance benchmarks for improvement such as:

• Requests should take less than 500ms to generate a result 99% of the time.
• Uncached requests should respond as quickly as possible.

Additional request types and templates

Additional request types that should be analyzed for improved performance:

• Uncached templates that can suddenly receive a high level of traffic from bots or users. This includes the 404 template, sitemaps, any search functionality, infinite scrolling, or AJAX-generated requests.
• AJAX requests to /wp-admin/admin-ajax.php. These requests are never cached and should therefore be used sparingly on the frontend and optimized for speed in all instances.
• Verify that the 404 template does not make any database queries or remote requests, especially any based on the request URL, aside from the core queries needed to determine that the URL is not found. Optimally, the 404 template is the fastest route on a site and handles requests in less than 250ms, because 404 status responses are not cached for as long as a normal URL; they are cached for a very brief time.
• Confirm that frontend, consumer-originated requests—whether from browsers or mobile apps—do not routinely result in database writes or remote requests.
• Reduce the occurrence of front end requests that result in database writes whenever possible. Subsequent database reads to prior written tables will always be handled by the primary database. If this occurs, it may negatively affect site performance during moderate to high traffic events.
• Ensure that database queries and remote requests follow best practices, are performant and cached, and items used across many pages avoid cache stampedes.
• Remote requests should have a reasonable timeout and retry setting. Add defensive code that will ensure that if an endpoint that is accessed to fetch data becomes unresponsive, it will not negatively impact the site’s performance.
• Ensure that API requests and consumer-originated AJAX requests perform quickly.

Application code

The code added by the customer to an application’s wpcomvip GitHub repository—both custom and third-party—should be regularly scanned, tested, and updated in order to improve a site’s performance and resiliency.

Code that is added to a WordPress application’s repository in a pull request will automatically be scanned and receive feedback from the VIP Code Analysis Bot. Customers should address as many errors and warnings reported by the VIP Code Analysis Bot scan as possible.

The performance of application code will benefit from occasional manual review as well. Focus especially on the places in code where remote requests and queries are defined.

Third-party plugins and themes

It is possible for third-party plugins and themes to negatively affect a site’s performance. During their development, third-party plugins and themes are not often tested under high traffic conditions or with sites that have extremely large databases. On sites with large databases, even some WordPress Core functions can be slow if they are not optimized.

When third-party code is active on a site, use available resources to identify performance issues.

Review the performance of a plugin in New Relic to ensure that it is performing quickly. Any frequently slow portions of traces related to the plugin should be reviewed in detail.

Ensure that a site’s plugins are:

• Not throwing warnings and/or errors
• Not making front-end database writes
• Completing queries or filesystem operations within a reasonable amount of time.