Is WebAssembly the dawn of a new age of web performance?

This post was contributed by Intechnica Performance Architect Cristian Vanti. Check out another of his posts, “Performance Testing is not a luxury, it’s a necessity”.

Even though the internet was created several years earlier, I think that the birth of the World Wide Web as we know it coincides with the release of the Mosaic browser in 1993.

In the past 22 years, everything to do with the web has changed incredibly fast and very few things have resisted change during this time. I can think of only three examples of this:

  • IPv4 (born in 1981)
  • HTTP 1.1 (born in 1997)
  • Javascript (born in 1995)

The first was superseded years ago, even if IPv6 hasn’t been fully adopted despite several attempts.

In February finally HTTP/2 has been formally approved, and easily it will quickly replace version 1.1 after 18 years.

Yet Javascript, after 20 years, is still the only language universally used in web browsers. There were some attempts to replace it with Java applets, Flash or Silverlight but none of them has ever threatened Javascript’s position. On the contrary, it started to conquer the servers as well (primes example: Node.JS).

While in the server area, a plethora of different languages have been created aiming to simplify the development of web applications. In the front end, Javascript has been the only real option.

On 17th June 2014, Google, Microsoft and Mozilla jointly announced WebAssembly. This could be a turning point for front end development for several reasons.

Firstly, there have been several attempts to replace Javascript, but each one was backed by a single player. This time the three main browser developers have joined to overcome Javascript.

Secondly, they decided to not replace Javascript in a disruptive way, but rather putting at its side a new binary format, a sort of bytecode. The user will not see any difference; everything will continue to work in the same way for whoever wants to stay with Javascript, but a huge opportunity has been created for those who want to develop faster applications.

Thirdly, the performance improvement that WebAssembly could carry is impossible by any other means.

And lastly, WebAssembly is a brilliant solution, something so simple but so powerful, something that should have been invented years ago.

WebAssembly is simply a binary format for Javascript. It isn’t a real bytecode: It is the binary format for the Javascript Abstract Syntax Tree (AST), the product of the first step in the Javascript parsing, nothing more. It is not a new framework, not a new language, not another vulnerability option. Not another virtual machine, but still the good old Javascript one.

In this way the webserver will not send the pure Javascript text but instead will send the first elaboration for that code in a binary format. The benefits will be a more compact size for the code and less work for the browser compiler.

But the full potential comes from the use of asm.js, a highly optimizable subset of Javascript that Mozilla created some time ago and is already implemented by all the biggest browsers. asm.js code is only slightly slower than C code, giving CPU intensive applications a great opportunity. Moreover there are already cross-compilers that can parse other languages (C, C++, Java, C#, etc.) and produce asm.js code. This means that it’s been possible to compile game engine code to asm.js, and the same will happen for heavy desktop applications like CAD or image editors.

Silently asm.js and WebAssembly are leading us to a new internet age.

This post was contributed by Intechnica Performance Architect Cristian Vanti. Check out another of his posts, “Performance Testing is not a luxury, it’s a necessity”.


Do users expect too much of applications?

Today, users expect more and more from their applications (both mobile and web).

In terms of performance, 47% of users now expect a page to load in 2 seconds or less. Apps like Instagram and Twitter set high expectations in terms of usability and functionality. And the cloud is everywhere – data is expected to be at our fingertips at all times.

As well as consumer expectations constantly rising, the expectations of businesses is also increasing. Now, anything that takes more than 3-6 months to start delivering real value is unlikely to get past the drawing board.

85% of businesses want to deploy apps within these time scales, but only 18% have processes in place to support this pace.

One solution Intechnica has recently adopted to meet and exceed these expectations is to adopt Rapid Application Development, which allows 80% of an application to be built using a drag-and-drop interface, leaving just 20% to traditional coding. This speeds up the development process to the point where a functional, useful web or mobile application can be deployed across various devices and delivering value to the business within weeks.

Case study – Delivering value within weeks

Intechnica, using Progress application development solutions, recently helped a leading European transport and logistics company to match the pace of business change by developing a mobile application to deliver new functionality within weeks, as opposed to the 3-6 months it would have taken using traditional application development methods.

The front-end of the company’s existing logistics, stock and order management application could not keep pace with the rate of change required to meet the new expectations of its users.

The solution was remarkably simple – but hugely effective. Today, smartphones are ubiquitous, so a simple mobile app was developed to replace several paper-based processes and mobilise the entire operation. GPS-based geolocation, time-stamping and photography functionality (all of which is available in almost every smartphone) was built into the app.

The business is now able to move with much greater pace and efficiency, enabling it to reduce costs and pro-actively manage its resource planning and invoicing functions with much greater accuracy.

The app was built, functional and delivering benefits to the business in just a matter of weeks.

Read more

Learn how businesses are addressing the increasing demand for faster development and time to value in an exclusive white paper produced by Intechnica. Head on over to the Intechnica website to download your copy now!

Performance Testing Mobile Apps: How to capture the complete end-user experience

Intechnica will be part of a live webinar presentation on August 26th (10am UK time) focused around the challenges of capturing mobile end-user experience in performance tests.

Today, so much emphasis is placed on end-user experience, particularly when it comes to mobile where end users expect the same level of performance from mobile apps as they do from web apps.

In the discipline of performance testing the end-user experience of mobile users is highly impacted by characteristics of the devices and the quality of the network. This makes it difficult for testers to accurately replicate production conditions with conventional testing tools and approaches.

Head of Performance Ian Molyneaux (author of “The Art of Application Performance Testing”, second edition available soon from O’Reilly) will join fellow performance testing expert Henrik Rexed (Neotys) to provide insights on:

  • What are the challenges of including mobile end-user experience in performance testing
  • What are the metrics you need to collect from the application, from the network and from the device
  • How to capture, correlate and analyse the relevant metrics and get a true picture of mobile app performance

Register now for the webinar, or if you can’t make it on the 26th, register anyway to receive a recording once available.


Performance testing is not a luxury, it’s a necessity

Recently I chanced upon a post posing the question of whether Software Testing is a luxury or a necessity. My first thought was that testing should not be a luxury; it’s much more expensive to face an issue when it arises in a live system, so if you can afford to do that, perhaps that’s the true “luxury”. However, testing is now accepted as a fundamental aspect of the software lifecycle and Test-Driven Development (TDD) stresses this aspect.

Unfortunately too often software testing is understood only as functional software testing and this is a very big limitation. Only if your software is supposed to be used by a very small number of users can you avoid caring about performance; only if your software manages completely trivial data can you avoid caring about security. Nevertheless, too often even the more advanced companies that use TDD doesn’t consider performance and penetration tests; or, at least, they do it only just at the User Acceptance Test (UAT) stage.

Working for a company that is very often requested to run performance tests for clients in the few days before the live release, we are often faced with all the problems that the development team has ignored. It’s hard when we must say “your system can’t go live with the expected workload” when the client’s marketing has already advertised the new system release.

Intechnica is stressing the performance aspect so much that we are now following the “Performance-Driven Development” approach. The performance requirements are collected together with the functional ones, addressing the design in terms of system architecture, software and hardware. Then the performance tests are run together with the unit tests during the entire software lifecycle (following the Continuous Integration practice).

I think that such an extreme approach may not be suitable for everybody, but recently I tested the performance of a new web application for a financial institution. We had already tested it 3 months earlier, but during these 3 months the development team has added new features and fixed some issues, the web interface has slightly changed, and as a result, almost all the test scripts became unusable and had to be fixed.

This tells me that the performance requirements must be considered throughout the entire development stage. They must be expressed and included in the unit tests because that is the only place where defined software contracts are used. Performance tests can be done at the UAT stage, but, just as no serious company would implement a UAT without having first functionally tested the code, so should you measure performance during the development stage. Additionally, an Application Performance Management (APM) tool is highly advisable to monitor the application and to find out the cause of performance issues rapidly in development as in the production environment.

Is testing a luxury? I’d prefer the luxury of a good dinner to the “luxury” of wasting money for an application found unfit for launch on the “go live” day.

This post was contributed by Cristian Vanti, one of our Performance Consultants here at Intechnica.

New case study: Nisa Retail Mobile app on Amazon Web Services

Amazon Web Services have recently published a new AWS Case Study, looking at how Nisa Retail have implemented an innovative mobile application to make their members’ lives easier. Nisa engaged with Intechnica to design and develop the app, which is built on AWS technology.

As an AWS Consulting Partner in the Amazon Partner Network, Intechnica was well positioned to leverage the power and flexibility of AWS to deliver a scalable solution that would not impact on Nisa’s core IT systems such as their Order Capture System (OCS).

The full case study is available to read on the AWS website.

If you need an application built with performance in mind from the outset, or specifically built around the flexibility of the AWS infrastructure, Intechnica can help. Fill in the form below or use our contact page.

New SlideShare presentation – “Technical Debt 101”

We’ve just published a new slide deck on SlideShare titled “Technical Debt 101” (click the link to view, or watch embedded below).

The slide deck was written by Intechnica Technical Director, Andy Still. Make sure you take a look at Andy’s regular blog posts, including expanded posts on Technical Debt management, over at

Andy explains why Technical Debt doesn’t have to be negative, but it does have to be carefully managed. These slides give a quick run-down of best practice to approaching Technical Debt management.

We have extensive experience in managing Technical Debt. Get in touch to talk to us about managing your Technical Debt the right way.

Channel 4 & Intechnica present “Performance in CI” at London Web Performance Group

Packed house at News International

Continuous Performance Testing was the hot topic at the London Web Performance Group of 20th March. Intechnica and Channel 4 were on hand to give a presentation highlighting the challenges around performance in CI to a packed room at the News International HQ.

Andy Still outlining performance in CI. Photo: @Peran

Andy Still outlining performance in CI. Photo: @Peran

In fact, it was “standing room only” as Andy Still (Intechnica co-founder and Technical Director) kicked off the presentation by providing some background on performance in modern development approaches. He also addressed the debate on whether process or tooling is more inhibiting to this approach.

This was backed up by Mark Smith (Online QA Manager, Channel 4) who provided detailed technical insights to the recent “Scrapbook” project. Intechnica provided Channel 4 with a dedicated Performance consultant to oversee the performance and testing needs of the project to great success. Mark outlined the tools and processes implemented and the results achieved.

The presentation, hosted by News International, was well received by the 100+ attendees and sparked a spirited Q&A session afterwards. Comments in reviews on the site described the presentation as “great, insightful” and “excellent and useful”.

The presentation can be viewed on Slideshare now.

Web Performance Groups meet regularly in London and Manchester. If you are interested in attending a Web Performance Group meetup, you can join by following these links for the London and Manchester branches.

Mark Smith describes the Scrapbook project. Photo: @mesum98

Mark Smith describes the Scrapbook project. Photo: @mesum98