What did i do wrong Pat?
edit: through playing about i have been able to work out its something to do with the number of navigate steps. What is the max number of allowable navigate steps in a script?
The hard limit is 20 navigations in a single script right now. It’s mostly in there because there were cases where spammers were using multiple navigations to cause a bunch of fake page views and bypass some of the other abuse protections on the public instance.
Would be nice to be possible to configure max number of test steps for private instances.
Hello there if anyone else has this problem for private instance i found a workaround for it just open runtest.php and find :
if( !$ok )
$error = “Invalid Script (make sure there is at least one navigate command and that the commands are tab-delimited). Please contact us if you need help with your test script.”;
else if( $navigateCount > 20 )
$error = “Sorry, your test has been blocked. Please contact us if you have any questions”;
just change the $navigateCount > 50,100 or whatever value you want the max to be
Out of curiosity, what is there to gain by doing many navigations in a single test? I never visit more than two pages in my tests to keep things simple. If I need more page coverage, I run more tests.
I’ve seen people do crazy things to authenticate their session before starting the test. If you’re navigating to a sign-in page and doing elaborate form filling in the script, consider setting a session cookie instead. That allows you to navigate directly to the test page without unnecessarily warming up the cache.
But warming up the cache in a realistic way is the main reason for doing many navigates in a single script (even more realistic would be to navigate via exec/execAndWait and javascript). It can make a huge difference to load the same page after just one other page than after a couple of pages. Pat is really good in clearing all the browser and os caches before first view so first pages in the script really have a hard time 
If you measure different (maybe longer) customer journeys with WebPagetest you will be able to load all of your important page types as entry pages and as follow up pages with a browser cache filled in a realistic way. Using OpenSpeedMonitor you can calculate a customer satisfaction index (CSI) representing all the measured page types weigted according to the weight you give them (see Weights CSI page here).
Testing multiple pages in sequence to warm up the cache is fine. I just think more than one or two warm-up pages is overkill.
Let’s say the user journey is between pages A > B > C > X. The page you’re trying to test is X, and users typically visit pages A, B, and C in that order before visiting page X. Page X contains resources a, b, c, and x that are only ever used once before on their respective pages. So the only way to replicate the cache state after an A > B > C > X flow is to perform the full journey. Otherwise, for example, if you just did C > X, resources a and b would not be cached.
I get that. You want to set up your tests to be as realistic as possible. Why bother testing C > X if the cache state is unrealistic? Well, I would argue that there’s still a lot to learn from that test. At worst, you’re testing a heavier site with resources a and b unnecessarily downloaded. But by optimizing that experience (C > X), the full version without the unnecessary downloads (A > B > C > X) will be all the faster for it. In other words, if you can make the first-view fast, the repeat-view can only be faster.
One could also argue that C is never an entry page so it’s unrealistic to test from C to X. While that may be true, I think it’s important to keep in mind that we’re testing X and not C. The degree to which X is affected by not loading A and B first would only be significant in very narrowly defined and contrived scenarios. And the thing about synthetic testing is that you can only test one scenario at a time, so it makes the most sense to focus on the most popular use cases. I would guess that there are bigger fish to fry ahead of tackling a 4-page flow. If X is the last of 4 in a series of critical pages, for example a signup flow, I think you’ve got bigger UX issues (abandonment) than performance issues.
But what I’ve heard earlier in this thread is not just three warmup pages, but more than 20. We’d have to exhaust the entire alphabet just to denote each unique page and corresponding resource. I can’t imagine a valid scenario where 20 or more pages are necessary before loading a test page. Surely you can cut most of those out and still get a reasonably accurate and representative test.
You are right: If you are optimizing an entry page same page loaded as follow up later in the journey won’t become slower (it will probably become faster, too). So, if you are doing some ad hoc tests to find out where to start with optimizations you are probably right with your suggestion not to complicate the scripts too much.
As a developer of OpenSpeedMonitor I mostly think of synthetic measurements as a continuous monitoring rather than single ad hoc tests. To get a view of the overall performance of a whole web application we recommend to use scripts for the most common of your customer journeys. These should contain your most important entry pages as entry pages. Same applies for follow up pages.
What I should add is that we use this WebPagetest fork with wpt server and agents capable of multistep measurements. So if we use scripts for a whole customer journey we measure all the single pages. No preceding, warm up page is loaded just to warm the cache. All loaded pages get measured. Here you can see an example where we measure a complete journey on a Nexus smartphone.
In OpenSpeedMonitor you can also build an index to represent the overall performance of your application or single page types of it. You can weight the measurements of each page type differently within this index. So if, for example, your homepage gets visited as an entry page in 60 percent of your real world page impressions you can represent that 60/40 distribution in your page weights. For another page type the distribution entry page/follow up might be totally different.
That’s not an unreasonable use case, as long as you’re comfortable using the forked private instance. But for the majority of users of the public instance or unmodified private instances, I’d advocate for breaking up large multi-navigation scripts into distinct tests. Otherwise if people don’t need test results for each link in the navigation chain, I’d recommend simplifying the script down to one or two navigations. Rinse and repeat for as many pages as necessary.
@bojankacarski I am also facing the same. I read in the forum that “just change the $navigateCount > 50,100 or whatever value you want the max to be” would work but even after changing the count in runtest.php it did not worked. I may missing anything I also restart my wpt server machine after changing the count