Posting on behalf of Usr.Web.Speed -
My previous job had been to architect and develop websites for various customers. During that time my team and I have architected and developed various web applications mainly for enterprises. (But below info is not restricted to enterprises)
Other than the usual development and testing tasks involved, our focus area was to abide by multiple SLAs. One of the primary SLAs was to provide the users of our websites a very low (usually subsecond) response time (or page load time).
To adhere to this SLA, we did multiple activities, in code, process as well as infrastructure. These include (but not limit to) -
After the development is complete, but before deploying it to PROD (production environment), we deployed code to a sanitized PROD-like environment. And load tests were executed using tools (such as - Visual Studio load test or ApacheBench).
My previous job had been to architect and develop websites for various customers. During that time my team and I have architected and developed various web applications mainly for enterprises. (But below info is not restricted to enterprises)
Other than the usual development and testing tasks involved, our focus area was to abide by multiple SLAs. One of the primary SLAs was to provide the users of our websites a very low (usually subsecond) response time (or page load time).
To adhere to this SLA, we did multiple activities, in code, process as well as infrastructure. These include (but not limit to) -
- Using best practices including (http://developer.yahoo.com/performance/rules.html)
- Determining the optimum number of calls to the databases, open connections, etc.
- Providing the fastest mechanisms to download associated content (such as stylesheets, JS files, etc. over CDN)
- And debugging the reason for the slowness of the websites, when we find any.
After the development is complete, but before deploying it to PROD (production environment), we deployed code to a sanitized PROD-like environment. And load tests were executed using tools (such as - Visual Studio load test or ApacheBench).
Once the tests are executed, it was then deployed to PROD.
But the question we always had was "is this enough". What we realized was that we do not have any mechanisms to continue monitoring the speed of the web pages after deployment.
The reasons for continuing monitoring is many including -
But the question we always had was "is this enough". What we realized was that we do not have any mechanisms to continue monitoring the speed of the web pages after deployment.
The reasons for continuing monitoring is many including -
- We executed the load tests making certain assumptions (how users use the application, that all users are the same, and there are no other problems) - but in practice, we know that most of these assumptions are theoretical.
- The web pages load up other dependent resources from other servers, (not under your control) - when was the last time you added a FB like button on your page? - and do they have an SLA ?
How Usr.Web.Speed. can help you -
When you sign-up for Usr.Web.Speed, we provide you a one-liner JavaScript code snippet. This snippet should be added to the HEAD tag of your website.
Once this is done, the script will automatically log the speeds of your pages as and when users open your website.
Also captured is data on how much time it takes to download and load the dependent
- JS files
- CSS files
- Images
- your AJAX calls
Once captured, Usr.Web.Speed processes these logs and provides your insights to the speed of the performance of your application via a dashboard and graphs.
And the best part of all this - it is FREE during the beta period. So what are you waiting for ? SIGN UP, now.
And remember - do provide some feedback or new feature requests
Comments