Site Confidence

3 new reports available in the Management Reporting portal

2012-02-09T16:17:00.000Z

Onceagain, you asked and we listened.

We’vehad several requests over the last few months to add a few extra reports intothe Management Reporting portal and last week they cleared testing and werepushed live! They are as follows:

Uptime by URL (3 Monthly)
Forthose of you who like to produce your URL availability reports quarterly!

Uptime by Account (3 Monthly)
Sameidea as above but with account wide availability.

Availability and Performance Summary
Finallya rather clever summary report showing availability over time (with acorresponding trend) and some average performance figures.

Aswith all these things, if you want a more detailed demo then feel free to getin touch.

New GA Stats – Excluding Site Confidence monitoring from your user analytics

2012-02-07T16:42:00.000Z

Since Google have now updated the look and feel of theiranalytics portal (including the addition of some lovely new features!) we feltit was time to update the instructions on how to go about filtering oursynthetic visits from the GA portal.

Step 1) Open the Google Analytics account you wish toexclude the statistics from (note you’ll need to add a custom filter to eachprofile).

Step 2) Select theOptions ‘cog’ in the top right.

Step 3) Select the Filters tab.

Step 4) Select New Filter.

Step 5) Then select a Custom Filter and choose to ExcludeVisitor IP Address from the Filter Field.

In the Filter Pattern filed you’ll then need to add theRegex patterns which you can find within the monitoring portal (Support ->Service Information -> IP Ranges).

At this point you’ll need to split the regex string as GAwill (still) only accept a maximum string length of 255 characters. The Regex expressions areseparated with a “|” in the portal, so as long as the expression starts with a“^” and ends with a “$” you’ll be fine.

Save the profile and the rules will take effectstraight away!

Q4 performance report

2012-01-24T14:09:00.000Z

http://www.siteconfidence.com/media/news/article/12-01-10/Web_performance_is_for_life_not_just_for_Christmas.aspx

My main take-away from this article is that “Throughout 2011retailers had failed to meet a target of 6 seconds download speed (as measuredat 2 Mbps), but achieved it during Q4 with average speeds of 5.2 seconds. However the top ten e-tailers alone did far better, with average speeds of 4.33seconds”.

So they achieved a performance gain, even though their pagesizes are increasing (http://blog.siteconfidence.com/2012/01/page-sizes-are-increasing.html)!

Imagine what they can achieve if they started to decreasetheir page size and optimise…

Page sizes are increasing

2012-01-05T16:12:00.000Z

A few weeks ago the BBC ran an article (http://www.bbc.co.uk/news/technology-16300000)using data from Steve Souder’s HTTP Archive which suggested that page sizes hadincreased over the last year. Thisseemed to be in line with our own observations. After all we download over 1.2 Terabytes ofdata a day from over 2.44 million tests.

I wanted to see if this was the case using our own data so Itook the top 10 sites from the (current) Hitwise top 50 e-tailers over the last12 months (2011-01-01 to 2012-01-01) and plotted the recorded daily averagepage size.

What did we see?

In general, page sizes did increase over the 12 monthsstudied.

The normal patterns observed were either a continual andgradual increase over time or a sudden increase in page size as the Christmasrush started. For example, John Lewismaintained a home page of between 300KB and 400KB for most of the year but wethen recorded the start of a dramatic increase to a high of 1.2MB over thefollowing few days. Page size has sincestarted to decrease although it is still c. 820KB (well above the yearlymedian).

The Apple home page also varied considerably, noticeablysurrounding 2 significant product launches. On the 3^rd march the page size jumped from c. 665Kb to 980Kbfor the launch of the iPad2, and then dropped back to 308Kb on the 28^thApril.

This was followed by another large increase (from 471Kb to1.1Mb) on the 21^st July following the release of the Mac OS X LionOperating System.

What does this show?

That web sites in the main are becoming larger. This could be due to more flash / JS basedcontent, the BBC article specifically referenced that JS was largelyresponsible (source: http://www.httparchive.org/trends.php#bytesTotal&reqTotal).

This also shows that the average number of requests for JSobjects has also increased since the start of last year. This could indicate that pages are gettingmore dynamic / interactive but also that more 3^rd party tags arebeing used (for things like user behaviour tracking, advertising and social‘widgets’). The use of 3^rdparty tags needs to be closely monitored, given the SPOF (http://blog.patrickmeenan.com/2011/10/testing-for-frontend-spof.html)that they can introduce to pages.

Ultimately as we all know heavier pages will take longer toload (therefore reducing the end users experience) and cost site owners more toserve. Reducing page size where possibleis going to improve any costs associated with the site (bandwidth, resourceutilisation etc.) and will also help to ensure that users have a more pleasantbrowsing experience!

If you’re unsure how big your home page is right now, have alook at http://www.siteconfidence.com/test-your-site.aspx.

That’s a lot of throughput!

2011-12-02T17:45:00.001Z

In the run up to Christmas we’re seeing lots of customers(old and new) running some pretty large tests to ensure that their platformsare ready for either a) the Christmas rush or b) their big New Year sales.

We’re in the process of running a project for one of thesetests and hopefully in the coming weeks we’ll share some more specific detailsabout it but for now I wanted to share the most significant headline numberthat we’ve seen so far.

This week we ran a test that managed to generateapproximately 281,000 Page Impressions per Minute. That’s a fair amount of throughput! A quick (and dirty) extrapolation makes that nearly17,000,000 Page Impressions per Hour!!

These were full page downloads, including all image / cssand JS assets with full diagnostic capture (request / response header and html)on failed tests. Nothing was spared!

In total we downloaded c. 162 GB, which is a lot of content.

Not only was this incredibly useful for the customer, but italso served to highlight a few limitations within our platform. Some were quite minor (a few graphs weren’tproperly displaying the large numbers correctly – a quick and cheap fix) andone was a little more expensive… we needto buy some more memory for our injectors! Both can (and shortly will) be overcome and the platform is ready forthe next big(ger) test.

This was probably the biggest test that our newand improved load platform has seen so far, however I expect it to be beatenfairly shortly.

eBuyer is down - promotion proves too popular?

2011-11-28T14:57:00.001Z

So the eBuyer site has crashed under load after their £1 gadget offer. Yawn.

As of 14:00 this afternoon the site is still down, due in no small part to this offer. You can bet however that the vast amounts of traffic didn't come as a surprise to the teams who had spent months organizing and then promoting the deals.

So do we put the blame on Ops again? They will probably be first up in front of the firing squad but I propose a new tack. All those who have a vested interest, and have been involved with the planning need to take some responsibility. Put the marketing team on the same performance and availability bonuses that the ops teams are on, that'd ensure that everyone was paying attention!

Ops teams should always carry out capacity planning exercises, that’s a given. If nothing else it’s an ITIL requirement.

But the business cannot just leave this with IT to fix. Its everyone problem if it goes wrong, as eBuyer are currently experiencing. Everyone involved needs to ensure that systems have been tested, ask for the reports and ensure that they prove that the application can support well in excess of the anticipated levels of throughput that are expected.

Performance testing is only as good as the data provided for the test but it’s also only as good as the goals that are set.

Was there a breakdown in communication between the marketing functions (who may have had an idea of the expected traffic levels) and Ops, who were perhaps just asked to carry out *some*capacity planning. Perhaps they then treated this as a box ticking exercise and didn't report the achieved metrics back to the business? If the business had known that they couldn't handle any more than X page impressions per hour / transactions per second would they have gone ahead with the promotion?

We shall probably never know.

The one thing that we can be sure of is that history will repeat itself again, and other retailers will do exactly the same thing.

I don’t want this to be a plug for performance testing, I want it to be a plug for common sense!! If you expect more visitors to your site than normal, test it. If you're making a change to something, test it. If you haven’t tested it for a while, test it! Something will have changed and you'll always get value from it.

A practical example of the benefits of compression

2011-11-09T13:44:00.000Z

We all know that using GZIP compression can save bandwidth and improve performance of a website. But it’s interesting to see a real world example of the difference it makes. The graph you see here is the same website tested at exactly the same time by the Site Confidence monitoring agent. The only difference is that one monitor (in green) has compression of text-based objects enabled, whereas the red overlay does not. The difference is approximately 5 seconds, almost 50% slower!

Tested using the Site Confidence Monitoring Agent v8, at 512Kbps.

Manual vs Automated WPO

2011-09-14T16:08:00.000+01:00

There is an on-going debate between those in favour of manual WPO and automated WPO. But surely lessons should be learned from both?

Automated WPO by using a server module such as mod_pagespeed is an easy, fast and economical way to "optimise" your site, but will only give you part of the solution. More advanced products like Aptimize or Strangeloop do a lot more, but also cost a lot more, they also take time to configure, massage and get working at the optimum level.

Cloud based services such as Yottaa can sit in the middle of this divide perhaps, offering an automated service, with no capital outlay that will give a general, automated optimisation layer. But by passing your traffic through their network, you are relying on another set of SLAs that need to be met, another "link in the chain" if you will.

Manually optimising your site can give many advantages, it means that developers can learn the "tricks" and should work that way by default in future, helping to ensure the site stays as fast as it can be. Some optimisations simply have to be done by hand, like domain sharding or setting up a cookieless domain. You can put browser specific optimisations in place based on your customer base, why put an IE6 optimisation in place if you know that only 1% of your visitors are using that browser? It just means that everyone has to download a bit of JS that 99% of visitors will never execute.

Of course there is a cost implication in manually optimising, and it is not insignificant, and certainly should not be underestimated. However, the cost should be looked at as a capital investment and one that will pay off by encouraging cleaner, leaner code from your developers, reducing bandwidth usage and infrastructure capacity.

There are arduous tasks that need to be done as part of an optimisation programme and they can lead to maintainability issues, such as minifying JS and CSS, or image spriting. Perhaps these kinds of optimisation are better be done automatically from maintainable code bases, and optimised by automated modules or serviced on the fly.

So there is perhaps an argument for using a combination of manual and automated techniques but relying on automated appliances or services to optimise your code, images and page layout exclusively can allow developers continue producing code that relies on someone else to optimise, giving way to a generation of developers producing bloated, inefficient code.

Another exercise in poor capacity planning?

2011-09-07T14:18:00.000+01:00

A couple of weeks ago HP decided that they would be dropping their interest in WebOS devices, and with it they planned to get rid of a load of hardware (some of which they had only just launched) in a big fire sale. As you can imagine this generated a lot of interest in America (where the price drop was first announced) and both online and high street stores sold out of their available stock very quickly.

The UK quickly followed suit – The evening of the 22nd August saw the first few retailers begin their sale, with many others dropping their prices as soon as HP told them it was safe to do so.

What happened next was almost embarrassingly predictable – the majority of the retailers who dropped their prices (and some that hadn’t but still held a stock of Touchpads) saw their web sites fail under massive loads, as hordes of shoppers attempted to pick up a bargain. For the first few hours (while the web sites claimed that they had stock of the products) the sites were pretty unusable and any attempt to purchase items, whether related to the Touchpad or not, was bound to prove troublesome. I personally tried and failed many times, with most timeouts occurring at the basket steps which is when you least want your site to fall over (because in most cases you have logged in and reached the point of entering credit card details – a supposedly secure step which should be failure proof if only to give the customer peace of mind that their secure data is safe!).

But, do the retailers really care that much? They had a finite amount of stock to shift and presumably they sold it all in record time. They would probably have also captured some new accounts along the way, as new users tried in vain to pick up some Touchpads at knock down prices. The fact that other users would, for a period of time at least, had a poor experience may or may not have worried them too much.

This is similar to the phenomena of high profile ticket sales such as when Take That sold their tickets for their tour dates. In this example the artist announced that tickets would only be sold through a small selection of resellers. As soon as the tickets went on sale the websites of every single one of these resellers fell over – a state that they remained in for pretty much most of the day. A select few managed to pick themselves up for a few minutes, sell a few tickets and then fall back over again.

Again, did they care? As far as they were concerned, they had a finite number of tickets to sell and they knew that they would sell them all. If customers were looking to buy tickets on that day for a different artist they would probably have been very disappointed, but in all likelihood the resellers probably didn’t mind too much. They were going to sell a record number of tickets anyway, so could afford to lose a few additional sales. Is this the right attitude? From the consumers point of view definitely not – but from a business perspective (in the short term at least) it stacks up. Long term brand reputation is another issue.

Or is it? Are these instances unique events which attract a different breed of shopper? One that is less likely to be affected by problems like site outages? Ultimately, if my wife wants to buy tickets for Take That again she won’t care that the site was down last time, she’ll happily mash the F5 button all day until the tickets are safely ordered. I suspect that the retailers know this, and take the hit. Again that’s probably not the right attitude to take.

We’re constantly being reminded that the cloud is here to take away our capacity planning requirements. If you’re running out of resource, just spool up a new web / database / application layer right? Well, that assumes that the application has been written with scalability in mind. As we’re continually being reminded a move onto cloud based architecture isn’t a migration it’s a transformation, and it’s one that is slowly being adopted over here.

During the Take That sale Akamai were (anecdotally) pushing 3 Tbps! That’s an enormous amount of traffic, and something that most applications would struggle to cope with. One of our large retailers has a quite advanced queuing systems which sits in front of their web site on sale days. It welcomes the visitor, tells them that they are in a queue and tells them how long they have to wait before they will be let into the store. This achieves 2 very important things. 1) It allows the site owner to manage how many users are active on their application at any one time (so they won’t suffer any nasty surprises) and 2) it keeps the customer happy – they aren’t faced with an unresponsive site or nasty error messages.

I know that this retailer spends a lot of time testing the capacity of both their application and their queuing systems to ensure that both will function as expected when they are needed, and it seems like a very sensible approach to take. If you can’t scale your application on demand, you need to control how many people are using your application to ensure it remains within a controlled limit.

So, lessons learned? If you are a retailer and there is the possibility of large traffic spikes you absolutely *have* to plan for them. If nothing else, knowledge of the current maximum capacity of the application landscape is a must. Even if the resolution is to wheel in specialist hardware / systems for the big events then a dry run in a controlled environment is better than just crossing your fingers and hoping.

By the way, Site Confidence are about to launch a shiny new load testing platform, the first step of which is a portal refresh. If you’d like to take a look then drop us a line!

Ben

Written on my HP Touchpad

How to exclude page components using the monitoring portal

2011-06-22T17:21:00.000+01:00

A Quick HowTo...

If you're monitoring a page but don't want the hits from our agents to request certain objects (tracking beacons, ad components etc.) then follow these instructions.

Step 1) Login and open the monitoring portal.

Step 2) Select Settings

Step 3) Select Monitor Settings -> Page

Step 4) Edit the page

Step 5) Select Show Extra Files

Step 6) Select Mode "Exclude (Partial Match)" and enter part of the string / URL that you wish to remove

Step 7) Save

All done!

Filtering Site Confidence monitoring stats using Google Analytics

2011-06-15T17:05:00.000+01:00

Many of you use Google Analytics and we regularly get asked how to remove the Site Confidence monitoring tests from your results – particularly now that the latest Site Confidence agent is executing JavaScript by default.

I therefore thought it might be beneficial to provide a quick step-by-step guide, showing how quick and painless the task can be!

Step 1) Open Your Google Analytics portal and Edit the Profile on which you want to add the exclusion.

Step 2) Select Add Filter from Filters Applied to Profile.

Step 3) Select Custom filter.

At this point you’ll need to fill in a few pieces of information. Firstly, you’ll need to give your filter a name. Then select Visitor IP Address from the Filter Field drop-down.

Finally, you’ll need to enter the Filter Pattern. These Regular Expression (Regex) patterns can be retrieved through the monitoring portal (Support -> Service Information -> IP Ranges).

Note you will need to split the regex string as Google Analytics will only accept a maximum string length of 255 characters. The Regex expressions are separated with a “|” in the portal, so as long as the expression starts with a “^” and ends with a “$” you’ll be fine.

And that’s it! Save Changes and you’re all done.

Ben.

Discernible performance spike caused by mailshots

2011-03-31T12:18:00.000+01:00

A quick observation for everyone.

A prospect who is currently on trial (no names, no pack-drill) noticed a significant spike in their recent performance.

The (diligent as ever) Account Manager dug a little deeper into this and found that the prospect had sent out a mail shot last night. Can you guess when this might have taken place?

This report overlays Visits Per Hour taken from the prospect Google Analytics account against the traditional Speed Analysis report.

The significant spike in response time is DIRECTLY related to the huge increase in traffic volume caused by the mail shot.

We can also observe that the traffic volumes created a huge impact on the Data Start time for the home page.

The Data Start times jumped from a baseline of near zero (good) to above 8 seconds at its worst (VERY bad). This time represents the time it takes for the first byte of information to be returned from the server to the client (browser). During this period users would have spent a lot of time looking at a blank browser… this will never help those all-important conversion ratios!

Anyway, thought you might be interested – back to report writing for me!

Ben

What should an SLA contain...

2011-03-29T15:34:00.000+01:00

We were recently asked to help a customer define what an SLA should contain and thought it was worth sharing this with a wider audience.

DEFINE DOWNTIME:

Site unavailable – The site is telling the client it can’t get access or the client can’t find the site.

Taking too long – Decide a suitable download threshold at the point you believe a visitor might give up and leave. At this point the site might as well be down.

Lost functionality – This could be the homepage works fine but the login fails (and is needed to buy something for example). This is a little less clear cut.

Planned downtime – The argument should be that any type of downtime is downtime even when associated with maintenance. Some organisations makes a distinction between planned and unplanned downtime.

AGREE REASONABLE TARGETS:

Competitor analysis/benchmarking: See what the rest of the market aim for in terms of performance and availability. If 5 seconds at a particular testing speed is fast then what if all your competitors are at 4 seconds?

Customer expectations: What will your customers accept in terms of performance? If the site goes down will they come back? What if it goes down X times in a set period of time?

DEFINE DOWNTIME TESTING PARAMETERS:

Testing speed: If you are setting performance targets then they should be measured against a fixed and consistent testing speed.

Testing platform: If multiple servers are used to support testing then they should be the same and configured in the same way to ensure repeatability in testing.

Testing agent: Should perform in the same way as a real browser (like the SC agent) and should be consistent across servers.

If anyone thinks that we should add or amend anything then leave a comment!

London Web Performance Meetup

2011-01-06T16:31:00.001Z

Just a reminder that the first London Web Performance Meetup will be taking place on Wed 19th January!

http://www.meetup.com/London-Web-Performance-Group/calendar/15729259/?from=list&offset=0

The guys from Seatwave have kindly agreed to present a case study on their performance improvement project for www.seatwave.com.

Perry & Ged have some great "real world" information on what worked for them from a technical perspective and how they managed the project overall.

Please RSVP on meetup.com if you are going to attend!

See you there from 6pm.

Site Confidence website has had a facelift!

2010-12-14T15:24:00.001Z

The Site Confidence website (www.siteconfidence.com) has had a facelift today

The site has a new simplified site structure, information on our new products (such as Performance Analyser) and some great new whitepapers.

So head over to www.siteconfidence.com and let us know your feedback via the blog!

55 Killer Questions before you launch your new website!

2010-12-14T15:02:00.001Z

What does it take to get ready for the launch of your new website?

What are the key things you need to do to ensure that you don’t join the ranks of Nokia, Apple, Nectar, the French and UK governments, and even Carla Bruni in having very public and high-profile disasters when you “go live”?

Launching a modern transactional website is a complex project, one that is increasingly “not just a IT problem” as you have to co-ordinate activity across multiple functional areas of the business e.g. Sales, Marketing, Customer Services etc.

Furthermore, delivery of many of these elements might be outsourced to 3^rd parties – designers, software houses, hosting providers, digital marketing specialists etc – that might be located in different countries, with different languages, cultures and in different time zones.

In the same way that a NASA Flight Director “goes around the room” to get a “Go / No Go” decision from each highly-trained specialist area before making the ultimate decision to launch a Shuttle mission the E-commerce Director has to try and co-ordinate these different areas prior to the website launch.

Unlike the NASA Flight Director however the E-Commerce Director might not have the luxury of years of experience, thousands of man hours of rehearsal, clear lines of communication, complete confidence in the technical skill of their staff nor in fact even have the ultimate authority to make that “Go / No Go” decision.
Wouldn’t it be great if someone gave you a list of things to check before “launch day” to ask each team to test if they are “All Systems Go?

The goal of this document is exactly that – an easy to understand checklist of the 55 “killer questions” things you need to do to ensure that your next website launch is a roaring success.

You can download a copy of the whitepaper here

The face of Velocity 2011…

2010-12-07T15:04:00.001Z

The latest banner advert for Velocity 2011 caused much mirth here in SC Towers… because the gentleman in the blue shirt facing away from camera is none other than Site Confidence’s Mark Sweeting!

Mark is one of our performance technical consultants and came back from Velocity with lots of great performance optimisation tips & tricks.

The hunt is now on to identify who is the mystery woman he is talking to in the picture?

Does anyone know who the other face of Velocity 2011 is?

Performance Analyser is live – Site-wide cross-browser performance analysis.

2010-11-29T14:02:00.001Z

Site Confidence’s new Performance Analyser tool has gone live today (and we are all pretty excited to finally launch it!).

Performance Analyser automates your website performance analysis by giving you detailed performance metrics on your web pages simultaneously in IE6/7/8 and Firefox 2/3/3.6!

What’s more, Performance Analyser can crawl your website, in the browser of your choice, to help you quickly identify the slowest loading, slowest rendering and just plain not working pages in your site.

So you can see the performance curve across your site and compare loading time to page size to look for anomalies (as you can see in the example below).

You can, of course, get the classic waterfall chart, complete with render start, DOM ready and other detailed timings at the page and object level.

If you want to know more, see a demo or have a trial please contact us!

New “Portal Tweaks” Release now live…

2010-10-06T12:21:00.001+01:00

The October release of the Site Confidence monitoring portal has gone live this morning (albeit with a few hiccups).

A bug in IE6 got through testing and we are working to patch that at the moment. Our apologies and sincere sympathies to anyone still using IE6…

A few people have had styling issues because they haven’t picked up the new CSS but a control-F5 will fix that. We are going to be moving to versioned file names in the future but we didn’t have that in this release.

Anyway – more about the great new features in the post below from our Development Manager, Feras:

This release is the culmination of a significant period of research and development which delivers a number of new and exciting features to the portal. We are happy to announce the launch of over 30 enhancements with the emphasis on making navigation more intuitive as well as providing additional reports and adding more functionality to existing ones.

Summary details of this release are below, but we are always happy to offer advice and support should you need further details on any of the new features. We hope you like the changes we've made and would welcome your feedback on which areas we should focus our attention on for future releases!

New Navigation Menu

Our biggest change is a new navigational menu which should make finding your way around the portal much easier.

Our orange highlighting will show you exactly which headline section you are in (Reports, Settings, Tools, Support) and which report you are currently viewing. This is consistent from the highest level of the navigation right down to the individual reports. Furthermore we have underlined all links within data tables to make it immediately apparent which information can be clicked for further info. Several other tweaks have been made around the various sections of the portal to make key functionality more noticeable.

Speed Analysis - New Interactive Graph with Zoom!

We have massively enhanced our Speed Analysis graph in both the Pages and User Journey sections. You will now be able to expand the standard “Speed by Time” and the “Speed v Time Component” reports into full screen where an interactive graph will be opened in a new browser window.

The “Scroll & Click” icon will allow you to drag sideways and move focus to earlier or later results then click on any single test to pop open the Page Analysis (waterfall) report for this test. You can open multiple Page Analysis reports allowing quick easy comparison of multiple test results. “Zoom In” and “Zoom Out” work in conjunction with the “Autoscale” tick box. If ticked the Y-Axis will autoscale to always display the full bar, if un-ticked you can hold and drag the pointer to select a specific zone to zoom in on. At any point you can reset the graph back to its original scale.

Page Analysis - New pie charts and email feature

We have added functionality to allow you to email any Page Analysis report to any email address. Look for the envelope icon with the report to utilise this feature. The email will contain details of the test (Page Name, URL, Date & Time of the test) with the CSV Export datasheet and the waterfall graph attached.
We've further enhanced the Page Analysis report to include two new pie charts to show the source domains / hosts of the objects captured and total bytes transferred from each.

Both pie charts can be located in a new tab added to the Page Analysis report labelled “Domain Requests Breakdown”

The first pie chart, “Requests per Domain”, shows the number of objects obtained from each domain or host within the page. Tooltips will also give you this breakdown by percentage. The colour for each section will map directly to the second pie chart described below.

The second pie chart, “Bytes Transferred per Domain” shows the total downloaded bytes per domain or host. Tooltips will give you the total bytes transferred.
As mentioned above the colour maps directly between the two charts so you can easily determine which domain is providing the largest amount of content by request and by actual bytes transferred.

In the example above we can see that the https://secure.shared.live.com domain (purple) only delivers 2 objects (or 25% of the total requests) but accounts for 84.43% of the total bytes downloaded. As one of our new reports we would be very keen to get your feedback and suggestions. Please contact us if you have any questions on the enhanced Page Analysis report or any other new feature using the details in the footer of this email.

Speed Histogram - New Report

Another brand new report launched today is the Speed Histogram. This Graph gives you a view of the range of speeds your test results cover broken down by time intervals. The graph will automatically start at your quickest test and continue in auto-scaled intervals until it reaches your slowest test.

This report gives a clear indication of the distribution of your tests by speed and allows you further control in the Customise View. You can exclude re-tests, adjust the starting point of the x-axis, define a date range and change the time intervals of the histogram

Many More Enhancements

With over 20 other changes included in this release we thought we'd give you a few more below so you can refer back and check what else is new at a later time.

Our Testing Summary graph has been changed so you can click through on each coloured section and view the list of test results it comprises of. It also auto-calculates the start of the x-axis so you have maximum space to aim for when clicking on the yellow, red and black sections.
The Settings Section has had an overhaul to highlight the number and types of monitors currently in your account. Administrators can also request to buy more monitors easily at the touch of a button.
The Alerts Profile Overview (also in Settings) has had a change of style. Gone are the ticks replaced with a much clearer green and red blocks display so you can easily and quickly identify your alerting coverage.
We've updated the Portal Hub to add links to the new Raise Tickets functionality and our Blog, Facebook and Twitter pages. We hope you'll follow us!
Our Overview Page now displays more details on open and recently closed errors including the User Journey name.
The CSV Export on the Errors Report in the User Journey section has been updated to include the User Journey name, Error Classification and any associated Notes.

We hope you will spend a few minutes on the Web Portal to check out some of the new features above. We certainly feel that most areas covered have been greatly improved. We hope you'll agree and we'd love to hear your opinions.

If you have any questions, please let your account manager or technical account manager know or you can email us at customer.support@siteconfidence.co.uk

How 100ms latency can become 5 seconds page download delay…

2010-08-19T15:22:00.001+01:00

We came across an interesting example of the impact of latency on page download speeds when reviewing a customer’s data from the Site Confidence portal the other day.

Site Confidence “round robin’s” its testing across monitoring agents connected to 3 different Tier-1 ISP’s to ensure that any failures detected represent a real failure of the customer’s hosts and not any intermediate networks (as well as for redundancy purposes).

The pattern we saw was this – tests from agents connected to one network were 5 seconds slower than tests from the agents on the other two networks.

The difference was about 5 seconds averaging 18.5s versus 13.7s (for a 1.2Mb page @ 512MB/s DSL speed).

Looking at the Connect and Data Start times you are see from the table that the “slow” tests have connection times of about 100ms, versus ~4-20ms for the “fast” tests.

Using the TraceRoute tools available in the monitoring portal we tracked it down to one “hop” that was adding ~100ms latency to the journey (see first traceroute below).

You can see by comparing that to the Traceroute from another agent that, despite taking a “longer route”, that it only took 5msec.

The page in question has about 90 elements loaded from the destination domain, and the cumulative impact of these “tenth of a second” delays is the consistent 5 second delay in page loading.

Whether this delay is introduced via a network problem (as in this case), distance (ie “real” latency introduced by geographic issues) or “server latency” on data start time by a server taking a long time to respond to a GET request it shows clearly how tiny delays can add up to a massive impact!

“Fastest tab” beats Google rank?

2010-08-06T15:40:00.001+01:00

We had an interesting conversion here at SC Towers this week about user behaviour, performance and tabbed browsers.

The key insight was about how we use the “Open Link in New Tab” feature when looking at Google results or any other search/comparison engine results list.

Most of us then do a quick “Open Link in New Tab” on about 4 or 5 entries on the results list that look interesting or are “at the right price” and then CLICK ON THE TAB THAT LOADS FIRST.

So, in effect, the “fastest tab” wins, REGARDLESS of the order that they may have been returned in the Google or comparison engine ranking.

Yes, the higher ranking entry is most likely to be the one that you “Open Link in New Tab” first and hence gets a “head start” whilst you move your mouse down and do the next right click to launch the next tab but that time delay is usually quite small.

If the first site is a second or two slower than the next opened tab it is quite possible that it will be bypassed as the user interacts with the first available tab.

Most of us also agreed that if the first available tab has what we wanted (the right product at the right price or the information we were looking for) we might never even look at the other tab.

So whilst the other sites’ analytics still might register a visit it never actually had one… and all because someone else's site was just faster enough to snag the user’s attention first.

The real question is how representative are our browsing habits of the wider population?

Do you use your tabbed browser in the same way?

Marie Claire talking about Boot’s website crash?

2010-07-19T09:55:00.001+01:00

Following on from our earlier post about even tabloid newspapers talking about website performance, now even Marie Claire is getting in on the act, talking about the Boot’s website crashing under the load generated by a new “must have” beauty product - http://style.uk.msn.com/beauty/marie-claire/articles.aspx?cp-documentid=154142397&ocid=today

Voice alerting from XML monitoring feed

2010-07-01T14:38:00.001+01:00

For those of you that use the XML monitoring feed from Site Confidence here is a little fun script that you might enjoy (and scare the heck out of your colleagues the next time you have a problem on your website!).

The script will “speak” out a warning message for any URL that has a “not OK” status code (ResultCode<>1) in your XML feed.

What you need is:

Windows Powershell v2 (if your PC is patched up to date you should have this already)
set Powershell to allow local unsigned scripts to run (at the Powershell prompt type “Set-ExecutionPolicy RemoteSigned”. You can check the status with “Get-ExecutionPolicy”. )
Cut & paste the script below
Edit the script to update the feed URL, proxy URL, credentials etc using the Powershell_ise (or notepad but in the ISE you can test it quickly)
save it as VoiceAlerts.ps1
create a scheduled task to run it every minute to check your feed (you can use the command “powershell –file %pathtofile%\voicealerts.ps1” to run the file)

The script….

# .NET class
# create the voice object
$voice= new-object -com sapi.spVoice

#create the webclient object to get the XML feed
$webClient = new-object System.Net.WebClient

# if you have an internal proxy server specify your proxy address and port
$proxy = new-object System.Net.WebProxy http://yourproxyserver:8080
# replace your credential by your domain, username, and pasword and un-comment the line below
# $proxy.Credentials = New-Object System.Net.NetworkCredential("domain\userid", "password")

# or just use the default credentials of the logged-in user
$proxy.UseDefaultCredentials = $true

#set the proxy
$webclient.proxy=$proxy

# File to download - change the URL to your XML file
$url = http://portal.siteconfidence.co.uk/xml/xml/yourfeedURL”

# Download the XML doc
[xml]$xml=$Webclient.DownloadString($url)

ForEach($node in $xml.GetElementsByTagName("Data"))
{
# if the result code is not equal to 1 - there is a problem
if ($node.page.result.resultcode -ne 1) {

    # create the string from the page.url (which is actually the monitor description)

    $errorstring = "Warning, there is an error on your website! " + $node.page.URL + " has a problem"

    $SpeakRC = $voice.speak($errorstring)

    # write out the values as well, so you can see
    $node.page.URL , $node.page.result.resultcode
   }
}

I hope you enjoy this bit of fun!

Website performance makes “The Sun”

2010-06-30T10:45:00.001+01:00

For those not familiar with the UK newspaper market “The Sun” is a mass-market tabloid newspaper best known for its topless girls on page three.

So it is an interesting measure of how “mainstream” web performance is becoming that there was an article about it last week (albeit with a “celebrity” hook).

Site Confidence is hiring!

2010-06-21T17:01:00.001+01:00

If you are interesting in working the the UK’s #1 web monitoring and load-testing company then you are in luck – Site Confidence is hiring!

We currently have vacancies for:

Systems administrator (LAMP stack)
New Business Sales person
Technical Consultant (Pre & post sales role)

All the roles will be based down here in sunny (today at least!) Dorking, Surrey which is easily accessible by mainline rail from Waterloo or Victoria or take Junction 9 from the M25 (for Leatherhead and Dorking).

If you are interested and want more information just drop us a line (blog@siteconfidence.com). Sorry, no agencies please!