Page Load Timeouts
What is a Timeout in RapidSpike?
A timeout occurs if a page is unable to render in full after 30 seconds. This is because one or more elements (resources that make up the page, such as images, fonts, JavaScript files, etc.) have failed to complete loading within the 30-second timeout limit. In the screenshot automatically captured during the failure, the page may look like it has completed loading, but there may be non-visible elements, such as marketing or analytical plugins, that have failed to load.
Bot Detection
Something which deserves a mention is to be aware of any bot detection on the site you are monitoring. If you safelist our IP’s or user custom headers this may be the cause of failures should they fail or have issues with configuration. Most bot detection providers will provide a page clearly stating a check is taking place however sometimes you may just be presented with a blank screen.
You can double-check our IP’s in use via your RapidSpike account by going to this page.
Investigation Steps
To analyse the test we recommend following these steps. Starting at the easiest to solve timeout to the more complex causes.
1. Failure Analysis / Visual
Go to the failing test either through the alert, wallboard or the monitor directly. Under Test result click the Failure Analysis tab which will compare a passing result to the failure. By default, the first screen will display all screenshots and videos captured during the test.
You will likely see one of three scenarios:
- A blank screen potentially suggesting a connection or load issue
- Some of the page has loaded however there are clearly elements missing
- The page looks completely fine and as expected
If you can see a blank screen or partially loaded page you should hopefully be able to pinpoint the issue whereas a fully loaded page might need some investigation. The next step will be to identify a cause of the failure.
2. Failure Analysis (Test Result) / Waterfall / Third Parties / Other
The next step is either switching to ‘Waterfall’ in the failure analysis tab or viewing the waterfall of that test result. It may be worth comparing both tests and proceeding to the test result for a better view.
There are a few things to look for here:
Slow Loading Elements – Hovering over an element in the timeline you will see Connect, Blocked, Wait, DOM, Render and more information on how that element has loaded in. If you see an element clearly holding up the page and increasing wait time this may be contributing to a timeout. If you see the overall page load time is around 30 seconds the cause probably either be an element midway through the waterfall or having issues at the end.
We can only detect slow-loading elements if the initial request has been completed before the timeout, otherwise, we have no record of it. If this is the case, open the website in your browser and use the network inspector tool to watch the page load. Wait for it to fully load (this may take over a minute), any elements that take longer than 30 seconds to load are ones that will cause the Journey to fail.
You cannot always identify one element as the cause of failures – if all the elements on your page are slow, then you may have to go through all the elements on your page and identify how to improve your page load.
We recommend looking at the elements list as well as the core web vitals monitor to look at areas for improvement
Error Codes – No Response, 404, 400 errors and anything unexpected are highlighted in the waterfall. Some you may be expecting however failure to load specific scripts or elements could be causing the test to fail.
Third Parties – You will see third parties in this view however we would recommend switching to the ‘Third Parties’ tab next. The majority of the time, third parties will be out of your control and are often the cause of site issues. It is important to ensure third parties are loading well and functioning as expected.
3. Browser Test / Dev Tools (VPN Optional)
Now you have run through the previous steps and are still not certain what the issue could be it is best to check you can see the issue in your own browser. RapidSpike’s User Journeys use a real browser to load the page like a real user would; however, it is very beneficial to replicate the problem on your own machine. You can test on any browser however as the tests run from Chrome we would recommend testing via Chrome.
If you are running a test in a different country to your own we would recommend using a VPN to generate better data on your browser. This is not essential however if the problem is occurring is a specific region you may need to use a VPN to catch the problem.
You can test your site in a few simple steps:
- Open your browser and then Dev Tools. If you are investigating a timeout, start on the ‘Network’ tab.
- Go to the site / page you are wanting to test. You will see the Network tab starts to populate. If you forget to open the tab before going to the page, a refresh will trigger the data to repopulate.
The important metrics to look out for here are the total load time, in particular elements that are taking a long time to load and anything taking it over the 30 second mark. You should see the problem element(s) in this view, very similar to the RapidSpike waterfall to confirm it is a genuine issue.
4. Third Parties
If you have gone through the other steps and still have questions about why a monitor has failed due to a timeout of another non-scripting issue, we would highly recommend investigating your third parties once again. Within RapidSpike, compare the third parties of a passing test to a failing test to identify discrepancies. If you are having a site-wide issue it may be beneficial to check the ‘Third Parties’ dashboard which pulls in all third-party data from your different monitors.
An important thing to remember is third parties regularly have issues despite what they sometimes say. A very quick and simple way of finding this out is by checking their status page or even contacting them directly if you feel it is appropriate. Third parties will be unique to your site however here are a few common examples:
It is rare that RapidSpike has downtime or any major issues however you can also check our status page here.
5. Contact RapidSpike
Now that you have investigated the test and third parties and made checks to the site in your own browser, you can contact us via live chat or email.
We recommend this as a last resort as you will likely be able to spot issues easier on your own site and reduce the time taken to come to a conclusion.
Solutions
The best solution is to fix the problem with the element that is causing it to load slowly (or not at all) or contact the third party who own the element and let them know it’s not working. Hopefully they can resolve the issue.
This could be a good opportunity to review if the element is even needed and remove it from your site.
If the element is needed, and it can’t be fixed, there are workarounds that can be used until the element is stable:
- Adjust the Page Load Strategy. We will still fail the test if the Journey is unable to complete an action, but we will no longer be able to warn you about potential issues with elements.
- Add the element to the Block List. This is not recommended because if the element later causes genuine issues for your customers, we are unable to detect the problem.