5 Tips to Optimize Your Synthetic Monitoring
Synthetic monitoring is a useful tool that ensures your site is both UP and performs well, and configuration matters. Optimized synthetic monitoring looks for necessary elements along a focused goal pathway. A poorly configured check can add precious seconds to a Transaction and trigger unwanted Global Timeout errors.
Today, we’re going to do a deep dive on tips and tricks used by Uptime.com Support and Development teams to improve and optimize the Transaction checks we use everyday.
Before You Start, Some Tips on Synthetic Monitoring
There are a few preliminary steps we recommend before you start setting up any Transaction check with Uptime.com. Take a moment to make sure you’ve got these basics covered.
If your site has a login process, provide your check with credentials that utilize the minimal permissions necessary to monitor the login flow. For security purposes mainly, but it’s also important to keep the check as focused as possible. There’s no need for a full permission user who can wander all over your UI.
Document or otherwise spec out the steps you plan for your check to make. Doing so will help keep your check on track, and can be useful if you need to troubleshoot.
Start using “Wait for element” instead of “Wait 1 second”. Wait 1 second is a useful step when you’re testing out a Transaction check and an element is loading slowly, but Wait for element offers more precise reporting on timeouts. Get used to using it first instead of Wait 1 second and you will find your checks easier to build over time.
Use Unique Selectors
Selectors are elements within your site that are clickable, detectable, or otherwise interactive. And they can make or break your check, quite literally.
Some examples include images, text in a headline, an input form, and a clickable button.
Good selectors are:
- Accurate: They point to the exact element you need.
- Unique: They don’t point to anything you don’t need.
- Simple: They should be human readable and easy to work with.
- Independent: They should remain relevant if the UI or design changes.
Generally speaking, name and ID are your best elements to use when finding a selector. A bad selector looks something like this:
li.has-mega-menu:nth-child(3) > div:nth-child(2) > div:nth-child(2) > span:nth-child(1) > div:nth-child(1) > ul:nth-child(1) > li:nth-child(1) > ul:nth-child(2) > li:nth-child(1) > a:nth-child(1)
This selector is nested within other elements. If any of those elements change, such as adding an item to a menu, the transaction check using this selector would break. It’s also not a very clear indication of the element the check should interact with, which can cause trouble later if you or a teammate need to edit your check.
Here is an example of a more accurate selector, using XPath:
Like the above, you want to aim for a selector that is both readable and unique.
Both XPath and CSS are valid when you’re hunting for selectors, so use the syntax that best fits your use case. Your dev team can also help here with selectors that are coded with unique IDs or attributes.
Minimize Unnecessary Steps
It is easy to overlook the load time for a URL when you’re building a five or ten step transaction check, but user actions are rarely so simple. Poorly optimized synthetic monitoring usually contain a number of unnecessary steps that could negatively impact performance. These steps are easy to eliminate from longer, more complex checks.
For example, rather than clicking login and proceeding to a login page, use an HTTP(S) check for the home page uptime, and begin your Transaction check on the login page
Wait for or Validator steps are useful, but you don’t need to use them every time. A Validator step is best used when you need to verify some element exists, contains text, or when an event has occurred that alters the element.
Wait for is important when you navigate to a new page and need to load a specific element on that page. Typically, we suggest waiting for elements like form fields, or buttons you need to click.
Optimize Synthetic Monitoring With Our New Tools
Recent releases have seriously beefed up the strength of our synthetic monitoring, and give you greater control over navigation and performance.
Login portals usually have a number of trackers, scripts, and other assets that slow performance unintentionally during a user’s first site visit. Our Transaction check always functions like a first-time visitor, but you can control when your check will move onto the next steps.
Use the waterfall and browser console for insights into load time and performance. The improved Browser Console offers greater insight into steps, requests, and responses from the server. Much like the Uptime.com Speed Test, the waterfall analyzes each request and provides a visual indication when requests are lagging so you can take action on your site.
Waiting for Navigation
Navigation, by default, adds 1.2 seconds to each action (such as Click) to allow for it to occur. However, longer and more complex checks often require more Click steps.
This time adds up fast, so navigation steps like Click and Go to URL now include an option to skip navigation entirely and move onto the next step. When using this option, consider using Wait for element to make sure the check gives the next step a chance to load.
Dealing with Special Use Cases
Send HTTP Header data with each request if necessary. HTTP Headers are primarily used for specifying content type or for authorization. Certain sites also have required HTTP headers that each request must include.
You can also validate HTTP Headers with a validator step that checks for specific text. Specify the header’s name, and then enter the text you want to find.
Use the Is Mobile option in the Authorization and Settings step to run your check as though it is using a mobile device. If you need to monitor touch actions, or specify a screen size, you can use the viewport option to adjust the resolution and responsiveness of the check.
Avoid Global Timeouts and Measure Performance Accurately
Poorly optimized transaction checks aren’t much better than a HTTP(s) check. A properly configured Transaction check gives you greater control over what the check does, how it executes its steps, and ultimately provides a deeper measure of performance.
Don’t forget to try the Chrome-based Recorder! The Recorder renders your site in an iFrame, so be aware that it can encounter issues with sites that don’t behave normally within an iFrame, but it can be useful to automatically record your actions. It also helps to identify elements and selectors with ease.
If you’re ready to get started with your synthetic monitoring, start a 14-day free trial today with Uptime.com.
Minute-by-minute Uptime checks.
Start your 14-day free trial with no credit card required at Uptime.com.