Implement your Automated Web Page Design Analysis

In recent years, static websites completely disappeared and with the rise of technology, companies provide their services more and more online. The former latent web pages were replaced with content-rich and dynamic websites. Frequent changes in content and website layout can have a high impact on end to end response times.

In this post, I will give you a simple approach how to implement an automated web page design analysis based on open source tools PhantomJS and Yslow.

Setup Details

The good thing is that all components required for this automated web page design analysis are open source and for free. You will need the following tools:

  • PhantomJS – a headless Webkit and automation solution
  • YSlow – page design best practices
  • Atom – a powerful editor for easy scripting and test execution

First of all, install PhantomJS on your environment. There is a detailed installation description on their website which you can use right away.

Secondly, download Yslow for phantomJS and customize the yslow.js file. Open the yslow.js file in any editor, add the line var system = require(‘system’); to the top of this file and replace all phantomjs.args with system.args in this file.

Thirdly, install Atom editor and enable the run command. Atom is an extremely powerful editor with tons of plugins. I used it’s run command to execute command line scripts.

Finally, test the installation with the given command below. You can use Atom after you enabled the run command, open a new window, insert the command phantomjs yslow.js –help and click ctrl-r.

Run the Analysis

PhantomJS and Yslow are powerful tools and provide many features which you can use right away for your automated web page design analysis. Personally speaking, I recommend starting with the basic command and work your way through the more advanced features.

Basic

In this mode, you will get a high-level page design analysis which consists of the size of your page, the overall score, the number of requests and the page load time. Execute the command below on your machine configured before.

phantomjs yslow.js -info basic -format plain http://focusaps.com

The picture below contains the output of this command. It shows that the given website has an overall page design score of 76 out of 100, has a size of 1.5 MB and a load time of 3.2 seconds.

yslow basic plain

Detailed

The detailed mode provides more insights to the weak areas of your website. It supports also predefined thresholds and supports the TAP output format which is supported by many tools such as Jenkins. Run the command below on your machine.

phantomjs yslow.js -info grade -format tap – threshold C http://focusaps.com

You will get the following output including relevant tuning hints which you can share with your developers.

yslow grade tap output.jpeg

I believe that you have now many integration ideas for the page design analysis. Automation is that easy. Add the automated checks to your build process, testing procedures and daily checks on your productive environments. You will see that this really helps to identify deviations in a proactive way.

Advertisements

Web Page Design Analysis is not a one-off Exercise

Small things matter most, and this is not only true for day to day activities. Minor changes in application configuration can have a significant impact on end to end user experience. In this post, I will give you insights into the nature of such changes and some simple steps towards proactive detection of speed degradations.

Changes and their Impact

Frequent modifications in the look and feel of websites are very much appreciated. Nowadays, websites are not only used for advertisement or gain commercial revenue. Companies try to stand out of the crowd and design websites which underline their image. Navigation has become easier since web designer understood that the number of clicks required to buy products is essential for their business.

Very common web page design failures are the absence of compression, large images, blocking java scripts and videos in auto play mode. Software test professionals are extremely familiar with those nasty pitfalls. They detect and eliminate those during QA stages. However, once the new business application has been deployed at production, nobody cares about the impact of this minor changes and slowly the speed of the former quick loading website is gone. Suddenly, frustrated users drop their shopping trip on your side, and financial revenue declines.

Automated detection of slow downs

You can avoid this frustrating scenario above. It’s not a rocket science and eventually easier than you could imagine. Quality assurance does not end post deployment of the new website on production. You won’t have a test plan for your live system, but an automated health and performance monitoring solution with significant test cases is required.

There are great cloud-based or locally hosted monitoring platforms out there which you can use. Replace the reactivity with a proactive health monitoring solution. Automation is a great feature when it comes doing repetitive things such as periodically execution of your monitoring test cases. Setup the performance and availability boundaries and let alerts flow out if your website slows down for whatever reason.

It’s good to now that the speed of a website is below expectations, but this helps you nothing if nobody is there who dives deeper, understands the cause and fix this issue. As already mentioned above there are those minor adjustments which could impact the end-to-end response time. Based on my experience, a good way to detect the real problem behind a slowdown is to implement QA checks used on testing stages also on production.

Actionable insights

As a performance engineer, I verify page design of new applications on pre-production. Google and Yahoo provide powerful tools which make this analysis quite easy. The good thing is that those solution detects issues and provide more insights to the actual root-cause such as disabled caching, large images or blocking java scripts. It makes much sense that your health monitoring solution also checks the page speed score of your web pages on a regular basis.

Recently, during some research for another paper, I became aware that automated page design analysis is almost for free. In my next post, I will outline how you could implement your self-made automated page design monitoring solution based on PhantomJS, Netsniff.js, and Yslow.

Spotlight on the Top 3 Performance Test Types

Performance testing is meanwhile a fundamental step in many software development projects. Test early and repeat often is also true for load and performance testing. It’s not a one-time shot and there are some pitfalls involved. In this post, I will outline the three most frequently used performance test varieties.

Component Speed Tests

In recent years software development methods have moved in the agile direction. Short release sprints are essential. Developers and test engineers automate their quality assurance and performance checks. Typically, they implement service based performance tests on the protocol level, or they simulate real browser-based performance checks to compare end-to-end response times with agreed performance boundaries.

Objectives
+ Repeatability
+ Automated interface and end-to-end performance checks
+ Compare response times with agreed thresholds

Load Tests

Load tests are the ideal setting when it comes to verification of non-functional requirements. One being that response times can be verified under reproducible conditions. Another on being that those tests allow verification of speed thresholds. Realistic response time measurement is essential in load test scenarios. Therefore, test engineers use headless or real browser-based user simulation for their load test settings.

Objectives
+ Reproducible load simulation
+ Verification of response time thresholds
+ Identify bottlenecks under production like load conditions
+ Realistic end-to-end test scenarios

Stress Tests

Consider a stress test if you have to proof reliability of your application under peak load conditions. In this type of test, you specify mainly the max number of users and the time over which the ramp up and the steady state load should be on your application. The goal is to identify the breaking points of your application under test. Often this type of inspections are not 1:1 reproducible because the simulated load varies based on the actual response time of the application under test.

Objectives
+ Proof scalability and stability
+ Simulate peak load conditions
+ Exact reproducibility is not relevant

Choosing the wrong type of performance test can be mission critical and put your trustworthiness at risk. I highly recommend reviewing the goal of your performance test before you start with it’s implementation.

Guideline for Choosing the Optimal User Simulation Approach

Testing and Monitoring platforms provide a broad range of user simulation methods such as protocol, headless, and real browser-based. In this post, I will outline the main aspects of those followed by a comparison matrix which you could use for choosing an appropriate simulation approach.

Protocol-level Simulation

Protocol level or HTTP-based testing was very popular in the early days of our digital age. With the rise of rich web client technology the proved simulation approach has been more and more outdated.

A typical HTTP-based test driver executes service requests and parses responses. Modern web 2.0 applications consist of many client-side scripts, which are totally ignored and not measured, in this type of test execution. In worst-case complex use cases cannot be simulated on protocol level due to a shortage of client side generated ids.

Complex protocol based use cases can be difficult to implement. A performance engineer needs to deal with cookies, session ids, and other dynamic parameters. Depending on the used technology of your system under test some web form names often change once a new version have been deployed which will cause the HTTP-based script to fail.

// Sample SilkPerformer protocol level script
transaction TMain
var
hContext: number;
begin
WebPageUrl(“http://lab3/st/”, “Greetings”);
WebPageStoreContext(hContext);
WebPageLink(“Join the experience!”, ” – New Visitor”);
WebPageSubmit(“Continue”, CONTINUE001, “Main menu”);
WebPageLink(“Products”, “ShopIt – Products”);
WebPageLink(NULL, “ShopIt – Product”, 3);
WebPageSubmit(“Search”, SEARCH001, ” – Search”, 0, NULL, hContext);
end TMain;

dclform
CONTINUE001:
“name”            := “jack”,
“New-Name-Button” := “Continue”;
SEARCH001:
“search”          := “boot”;

After all, protocol level scripts are perfect for service based tests in continuous integration environments, uptime monitoring or also for stress tests.

Headless Browser Simulation

With the rise of web 2.0 technologies the testing and monitoring business was faced with serious challenges. Rich browser applications could no longer be tested or simulated on the protocol level due to the missing client side logic during script replay.  Therefore, several headless browsers have been introduced such as HtmlUnit, PhantomJS or SlimerJS. They are often built on top of WebKit, the engine behind Chrome and Safari.

Headless Browsers have all the advantages of real Browsers, and they run faster without the heavy GUI. Many test automation, monitoring, and performance testing platforms are using headless browsers as they allow realistic user simulation.

Some tool providers have built their headless browser engines and ran in maintenance pitfalls. They have to keep the pace with new browser versions. It’s highly recommended using free available headless browser kit because there is a broad community which works on improvements.

// Sample phantomjs script
“use strict”;
var page = require(‘webpage’).create(),
server = ‘http://posttestserver.com/post.php?dump’,
data = ‘universe=expanding&answer=42’;

page.open(server, ‘post’, data, function (status) {
if (status !== ‘success’) {
console.log(‘Unable to post!’);
} else {
console.log(page.content);
}
phantom.exit();
});

Finally, headless browsers are ideal for test automation, performance testing, and SLA monitoring.

Real Browser Simulation

Web2.0 applications are full with JavaScript, Flash, Ajax and CSS. Without a full browser, it’s not possible to measure the actual end-to-end response times of the whole web page. Real Browser Monitoring allows you to verify the site’s functionality and performance as perceived by the end-user.

A typical real browser monitoring solution collects loading times of images, javascript, CSS and more. Often they provide waterfall charts, which visualize the load time of those components.

One of the biggest disadvantages is their footprint. A single real browser script requires much more CPU and memory resources on the load injection or monitoring machine. Therefore real user based simulation is not recommended for stress test scenarios.

// sample SilkPerformer real browser-based script
transaction TMain
begin
BrowserStart(BROWSER_MODE_DEFAULT, 800, 600);

// navigate to the login site
BrowserNavigate(“http://demo.com/TestSite/LoginForm.html”);
// set the authentication for the secure site
BrowserSetText(“//INPUT[@name=’user’]”, “BasicAuthUser”);
BrowserSetPassword(“//INPUT[@name=’pwd’]”,     Decrypt3DES(“Ax7/X9sk1kIfHlbAZ434Pq4=”));
// submit the form
BrowserClick(“//INPUT[@value=’Submit Query’]”, BUTTON_Left);
end TMain;

After all, real browser simulation is useful for acceptance testing or SLA monitoring. Don’t use it for performance or stress testing because the resource footprint is too high.

Comparison Matrix

Obviously, there are good reasons for protocol, headless or real browser-based user simulation. The table below provides some guidance to choose the appropriate approach.

Criteria HTTP Headless Browser Real Browser
Realistic User simulation

 

No Yes, but with some limitations Yes
Easy script creation

 

 

No, depends on application complexity Yes Yes
Robust script replay Yes Yes, sometimes tricky tweaks required Yes
Easy Script maintainability

 

No Yes, debugging could be tricky Yes
Multi-Browser Support

 

Yes Yes, but with some limitations Yes
Low footprint on load injection machine Yes Yes No
Good for continuous integration

 

Yes No No
Good for performance tests

 

Yes Yes No
Good for

stress tests

 

Yes No No
Good for uptime monitoring

 

Yes Yes No
Good for SLA monitoring

 

No Yes Yes

Keep doing the good work and share your experience with me.