Reading Time: 9 minutes
If you were planning to race your car, you would want to make sure it could handle the road, right?
Imagine racing a car that is not ready for the surprises of the road. A road that is going to require you to twist and turn constantly, and react quickly to the elements.
You would find yourself on the side of the road in no time.
A well-outfitted car, on the other hand, is able to handle the onslaught of the road and, when the dust settles, reach the finish line.
Well, think of your website like the car and conversion optimization like the race. Too many companies jump into conversion optimization without preparing their website for the demands that come with testing.
Get the Technical Optimizer’s Checklist
Download and print off this checklist for your technical team. Check off each item and get prepared for smooth A/B testing ahead!
*
*
By entering your email, you’ll receive bi-weekly WiderFunnel Blog updates and other resources to help you become an optimization champion.
But proper technical preparation can mean a world of difference when you are trying to develop tests quickly, and with as few QA issues as possible. In the long-run, this leads to a better testing rhythm that yields results and insights.
With 2017 just around the corner, now is a good time to look ‘under the hood’ of your website and make sure it is testing-ready for the New Year. To make sure you have built your website to stand the tests to come, pun intended.
In order to test properly, and validate the great hypotheses you have, your site must be flexible and able to withstand changes on the fly.
With the help of the WiderFunnel web development team, I have put together a shortlist to help you get your website testing-ready. Follow these foundational steps and you’ll soon be racing through your testing roadmap with ease.
To make these digestible for your website’s mechanics, I have broken them down to three categories: back-end, front-end, and testing best practices.
Back-end setup a.k.a. ‘Under the hood’
Many websites were not built with conversion optimization in mind. So, it makes sense for you to revisit the building blocks of your website and make some key changes on the back-end that will make it much easier for you to test.
1) URL Structure
Just as having a fine-tuned transmission for your vehicle is important, so is having a well-written URL structure for your website. Good URL structure equals easier URL targeting. (‘Targeting’ is the feature you use to tell your testing tool where your tests will run on your website.) This makes targeting your tests much simpler and reduces the possibility of including the wrong pages in a test.
Let’s look at an example of two different URL targeting options that you might use. One is a RegEx, which in JavaScript is used for text-based pattern matching. The other is Substring match, which in this case is the category name with two slashes on each side.
RegEx Example
Products to include:
www.test.com/ab82
www.test.com/F42
www.test.com/september/sale98
Products to exclude:
www.test.com/F4255
Targeting:
RegEx: (ab82|F42|sale98)
Substring Example
Products to include:
www.test.com/products/engines/brandengine/
www.test.com/products/engines/v6turbo
www.test.com/products/sale/september/engines/v8
Products to exclude:
www.test.com/products/sale/september/wheel/alloy
Targeting:
Substring: /engines/
In the first example, the company assigned URLs for their product pages based on their in-house product numbers. While writing a targeting rule based on RegEx is not difficult (if you know JavaScript), it is still time consuming. In fact, the targeting on the first example is wrong. Tell us why in the comments!
On the other hand, the second example shows a company that structured all of their product URLs and categories. Targeting in this case uses a match for the substring “/engines/” and allows you to exclude other categories, such as ‘wheels’. Proper URL structure means smoother and faster testing.
2) Website load time or ‘Time to first paint’
‘Time to first paint‘ refers to the initial load of your page, or the moment your user sees that something is happening. Of course, today, people have very short attention spans and can get frustrated with slow load times. And when you are testing, ‘time to first paint’ can become even more of a concern with things like FOOC and even slower load times.
So, how do you reduce your website’s time to first paint? Glad you asked:
Within the HTML of your page:
Move any JavaScript that influences content below the fold to the bottom of the body, and make these sections load asynchronously (meaning these sections will execute after the code above it). This includes any external functionality that your development team is bringing from outside the basic HTML and CSS such as interactive calendars, sliders, etc.
Within the head tag, move the code snippet of your testing tool as high as you can―the higher the better.
Minify* your JS and CSS files so that they load into your visitor’s browser faster. Then, bring all JS and CSS into a single file for each type. This will allow your user’s browser to pull content from two files instead of having to refer to too many files for the instructions it needs. The difference is reading from 15 different documents or two condensed ones.
Use sprites for all your images. Loading in a sprite means you’re loading multiple images one time into the DOM*, as opposed to loading each image individually. If you did the latter, the DOM would have to load each image separately, slowing load time.
While these strategies are not exhaustive, if you do all of the above, you’ll be well on your way to reducing your site load time.
3) Make it easy to differentiate between logged-in and logged-out users
Many websites have logged-in and logged-out states. However, few websites make it easy to differentiate between these states in the browser. This can be problematic when you are testing, if you want to customize experiences for both sets of users.
The WiderFunnel development team recommends using a cookie or JavaScript method that returns True or False. E.g. when a user is logged-in, it would return ‘True’, and when a user is logged-out, ‘False’.
This will make it easier for you to customize experiences and implement variations for both sets of users. Not doing so will make the process more difficult for your testing tool and your developers. This strategy is particularly useful if you have an e-commerce website, which may have different views and sections for logged-in versus logged-out users.
4) Reduce clunkiness a.k.a. avoid complex elements
Here, I am referring to reducing the number of special elements and functionalities that you add to your website. Examples might include date-picking calendars, images brought in from social media, or an interactive slider.
While elements like these can be cool, they are difficult to work with when developing tests. For example, let’s say you want to test a modal on one of your pages, and have decided to use an external library which contains the code for the modal (among other things). By using an external library, you are adding extra code that makes your website more clunky. The better bet would be to create the modal yourself.
Front-end setup
The front-end of your website is not just the visuals that you see, but the code that executes behind the scenes in your user’s browser. The changes below are web development best practices that will help you increase the speed of developing tests, and reduce stress on you and your team.
1) Breakpoints – Keep ’em simple speed racer!
Assuming your website is responsive, it will respond to changes in screen sizes. Each point at which the layout of the page changes visually is known as a breakpoint. The most common breakpoints are:
Mobile – 320 pixels and 420 pixels
Desktop and Tablet – 768px, 992px, 1024px and 1200px
Making your website accessible to as many devices as possible is important. However, too many breakpoints can make it difficult to support your site going forward.
When you are testing, more breakpoints means you will need to spend more time QA-ing each major change to make sure it is compatible in each of the various breakpoints. The same applies to non-testing changes or additions you make to your website in the future.
Spending a few minutes looking under to hood at your analytics will give you an idea of the top devices and their breakpoints that are important for your users.
Above, you can see an example taken from the Google Analytics demo account: Only 2% of sessions are Tablet, so planning for a 9.5 inch screen may be a waste of this team’s time.
Use a standard, minimal number of breakpoints instead of many. You don’t need eight wheels, when four will easily get the job done. Follow the rule of “designing for probabilities not possibilities”.
2) Stop using images in place of text in your UI
Let’s say your website works in the many breakpoints and browsers you wish to target. However, you’re using images for your footer and main calls-to-action.
Problem 1: Your site may respond to each breakpoint, but the images you are using may blur.
Problem 2: If you need to add a link to your footer or change the text of your call-to-action, you have to create an entirely new image.
Use buttons instead of images for your calls-to-action, use SVGs instead of icons, use code to create UI elements instead of images. Only use images for content or UI that may be too technically difficult or impossible to write in code.
3) Keep your HTML and CSS simple:
Keep it simple: Stop putting CSS within your HTML. Use div tags sparingly. Pledge to not put everything in tables. Simplicity will save you in the long run!
Putting CSS in a separate file keeps your HTML clean, and you will know exactly where to look when you need to make CSS changes. Reducing the number of div tags, which are used to create sections in code, also cleans up your HTML.
These are general coding best practices, but they will also ensure you are able to create test variations faster by decreasing the time needed to read the code.
Tables, on the other hand, are just bad news when you are testing. They may make it easy to organize elements, but they increase the chance of something breaking when you are replacing elements using your testing tool. Use a table when you want to display information in a table. Avoid using tables when you want to lay out information while hiding borders.
Bonus tip: Avoid using iFrames* unless absolutely necessary. Putting a page within a page is difficult: don’t do it.
4) Have a standard for naming classes and IDs
Classes and IDs are the attributes you add to HTML tags to organize them. Once you have added Classes and IDs in your HTML, you can use these in your CSS as selectors, in order to make changes to groups of tags using the attributed Class or ID.
You should implement a company-wide standard for your HTML tags and their attributes. Add in standardized attribute names for Classes and IDs, even for list tags. Most importantly, do not use the same class names for elements that are unrelated!
Example:
Looking at the above example, let’s say I am having a sale on apples and want to make all apple-related text red to bring attention to apples. I can do that, by targeting the “wf-apples” class!
Not only is this a great decision for your website, it also makes targeting easier during tests. It’s like directions when you’re driving: you want to be able to tell the difference between the second and third right instead of just saying “Turn right”.
Technical testing ‘best practices’ for when you hit the road
We have written several articles on testing best practices, including one on the technical barriers to A/B testing. Below are a couple of extra tips that will improve your current testing flow without requiring you to make changes to your website.
1) If you can edit in CSS, then do it
See the Pen wf-css-not-js by Ash (@ashwf) on CodePen.
Above is an animation that WiderFunnel Developer Thomas Davis created. One tab shows you the code written as a stylesheet in CSS. The tab on the right shows the same animation written in JavaScript.
JavaScript is 4-wheel drive. Don’t turn it on unless you absolutely need to, ‘cause you’re going to get a lot more power than you need. CSS effects are smoother, easier to work with, and execute faster when you launch a test variation.
2) Don’t pull content from other pages while testing
When you are creating a variation, you want to avoid bringing in unnecessary elements from external pages. This approach requires more time in development and may not be worth. You have already spent time reducing the clunkiness of your code, and bringing in external content will reverse that.
The important question when you are running a test is the ‘why’ behind it, and the ‘what’ you want to get out of it. Sometimes, it is ok to test advanced elements to get an idea of whether your customers respond to them. My colleague Natasha expanded on this tactic in her article “Your growth strategy and the true potential of A/B testing”.
3) Finally, a short list of do’s and dont’s for your technical team
Don’t just override CSS or add CSS to an element, put it in the variation CSS file (don’t use !important)
Don’t just write code that acts as a ‘band-aid’ over the current code. Solve the problem, so there aren’t bugs that come up for unforeseen situations.
Do keep refactoring
Do use naming conventions
Glossary
DOM: The Document Object Model (DOM) is a cross-platform and language-independent convention for representing and interacting with objects in HTML, XHTML, and XML documents
iFrame: The iframe tag specifices and inline frame. An inline frame is used to embed another document within the current HTML document
Minification of files makes them smaller in size and therefore reduces the amount of time needed for downloading them.
What types of problems does your development team tackle when testing? Are there any strategies that make testing easier from a technical standpoint that are missing from this article? Let us know in the comments!
The post Get your website testing-ready with the Technical Optimizer’s Checklist appeared first on WiderFunnel Conversion Optimization.