1. Final results analysis aimed at CI build pass/fail. Results can trigger build failure for example.
2. Immediately raise awareness in the team for front end performance issues. The builds break until the front end hits its targets.
3. Graphical representation of browser cached and uncached performance, build by build
4. Click through from Jenkins workspace to log of test run results, step by step
5. Click through to detailed xml data from webPageTest
6. Click through to detailed test analysis presented in webPageTest front end, including Google page speed like analysis for example.
7. Highly configurable test runs, using webPageTest scripting engine to suit many and varied projects
8. Ability to set up CI to test in different browsers
9. Ability to set up different CI test scenarios, using webPageTest scripts. For example testing with / without 3rd party content
10. Ability to set up CI front end testing on different client hardware. Perhaps best case / worst case.
11. Ability to set CI front end testing internally and externally. This can give a different perspective to your development team. For example I run a CI build pointing to my own external machine with a private instance of webPageTest. Results give a very different picture from the enterprise monitoring solutions that we are signed up with (keynote for example). We can see the realistic impact of 3rd party content right out to the final home desktop connection, for example, rather than to a backbone dedicated monitoring solution.
12. Ability to set CI front end testing to check for single points of failure, where your site is broken by dependencies that fail. Finding these early on can save a lot of time later. Scroll to the bottom of this page for details: wP Input
13. New feature just added: monitor specific page assets: asset monitor