Test a site

Before shifting traffic to a new site, make sure the site is working as expected, and that it is as performant and secure as possible. In general, continuous performance checks should occur during development on a non-production environment, but tests on a production environment just before launch are also recommended.

Test the front end of a site (desktop and mobile browsers) as well as the back end (server and WordPress Admin) functionality to ensure the site functions as expected. If anything appears broken or is not working as expected, utilize the browser’s inspector tools and VIP’s debugging resources to determine which errors or warnings need to be addressed.

Basic testing

Before a site launches, or when new code is introduced to a site, a standard list of tests should be run. This list should be created by a customer based on features that a site’s team will use on a regular basis such as WP Admin dashboard tools, added plugins, and custom theme features.

At a minimum, these basic functions should be included in a site test to verify that they work as expected:

• Create a post as a user with the “editor” role
• Create a post as a user with the “author” role
• Upload an image to the media library
• Add that image to a post
• Edit a post
• Delete a post
• Create a new user, and log in as that user
• Delete a user
• Change a user’s role
• Add a widget
• Modify a widget
• Ensure search results work as expected
• Verify settings are correct for external services like Google Analytics, Twitter, Facebook, etc.
• Verify that third party plugins work as expected.
• Verify any custom features of your editorial workflow
• If 301 redirects are set up on a site, verify that they work as expected.
• Ensure that the browser is loading pages in a reasonable time and that images are not being resized from very large to small (this wastes user bandwidth and affects their experience)
• Ensure ads, tracking beacons, and other important but less-visible features on the browser work as expected. Verify there are no JavaScript console errors or warnings that should be addressed.

Load testing

The VIP Platform is designed to scale its resources under most conditions, making it generally unnecessary to load test a site. Prior to initiating any load or stress testing, notify VIP by creating a Support ticket and outline the objectives and planned methodology of the load test.

VIP recommends analyzing a site’s performance in New Relic prior to launching the site, then again after real traffic is reaching the site and make adjustments where needed. Portions of application code that may not perform well under load can be identified by looking at individual requests or a history of activity.

Make use of front-end analysis tools in a browser, or via webpagetest.org, to identify potential browser performance issues.

General guidelines for load testing

• If implementing and testing changes, a baseline test should be run before and after those changes are made.
• Tests should be stopped as soon as the fail threshold has been achieved.
• Traffic should be increased gradually (ramped-up) and take into account that URLs that have been saved to the edge cache will have a much faster load time for future requests (hits).
• When determining the number of concurrent users/second to test with, take into account that on average only 1/10th of the user requests would reach the origin datacenter. To make the test more realistic, use the total number of requests which should reach the origin datacenter.
• The most critical aspects of site resilience and performance are cache hit rate and the speed of page generation for origin requests (i.e. uncached requests). Do not intentionally use cache-busting query parameters, non-GET requests, or requests with cookies that might invalidate the caching at edge.
• Ideally, tests should come from different locations.