Tag: web development

Web Assembly Deep Dive – How it Works, And Is It The Future?

Posted on by eugene evdokimov

You’ve most likely heard of Web Assembly. Maybe you’ve heard about how game-changing of a technology it is, and maybe you’ve heard about how it’s going to change the web.

Is it true? The answer to this question is not as simple as a yes or no, but we can definitely tell a lot as it’s been around for a while now. Since November 2017, Web Assembly has been supported in all major browsers, and even mobile web browsers for iOS and Android.

In this article, I’ll explain what Web Assembly is, how it works, what are the advantages, and what are the current uses today.

So with that being said, let’s get started!

What is Web Assembly?

Let’s take a look at how MDN explains it:

“WebAssembly is a new type of code that can be run in modern web browsers — it is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages such as C/C++, C# and Rust with a compilation target so that they can run on the web. It is also designed to run alongside JavaScript, allowing both to work together.”

We can learn a few important things from their explanation:

First, Web Assembly (or, WASM for short) is not a language you write, but a compilation result of other languages. Here’s a list of all the languages that support compilation to WASM: https://github.com/appcypher/awesome-wasm-langs

You’ll probably be surprised to find out you can even use TypeScript syntax to write Assembly, using AssemblyScript.

Second, WASM is faster than JS and runs with near-native performance in the browser. This is a big deal and is what makes WASM so attractive.

Third, WASM is designed to run alongside JavaScript, and not to replace it. One of the misconceptions about WASM is that it is somehow a competitor to JS. The truth is, WASM has been designed to run alongside JavaScript from the get-go.

WASM and JS can even communicate with each other. So WASM code has the ability to indirectly access JS features such as different features of the Web API like the DOM, Audio, Web Sockets, etc.

How Web Assembly Works

So by now you probably get that WASM is fast, but why? How does it actually work?

In order to understand that, first you’ll need to understand how the JS engine works behind the scenes. Since this is not the main topic of the article, I’ll only touch on it from a high-level. I explained it much more deeply in my article about how the JS engine works, and I highly recommend to read it first if you’re not familiar with the subject at all.

Also keep in mind that engine implementations are different, the steps I’m explaining here are about how V8 works, but other engines might do this differently.

How the JS Engine Works

In order to compile JS code there are few things the engine must do:

  1. The Parser – the engine must pass that code through a parser first. The parser goes through the code line by line and checks it for valid syntax as well as for the code types. If everything is valid, the Parser creates a tree data-structure called an Abstract Syntax Tree (AST).
  2. AST to Intermediate Representation (IR) – Then, the engine interpreter takes the AST and turns it into Bytecode, which is an intermediate representation of the code (an IR is an abstraction of machine code).
  3. Compiling the IR to Machine Code – Only then the engine compiler takes the Bytecode and turns it into a code a machine can run on its processor.

How WASM Works

The reason WASM is faster is because WASM code goes directly to the compiler, effectively skipping step 1 and 2.

But you might be wondering, why? Why is WASM able to skip steps 1 and 2 and JS not?

The reason for that is because JS is a dynamically-typed language, which means that JS checks the type of variables at run-time by the Parser.

In contrast, statically-typed languages require to declare the types in advance, therefore types are known and are checked at compile time.

So the way WASM works is:

  1. You write code with its types, usually in a statically typed-language.
  2. Then you generate a pre-compiled WASM module.
  3. Then you can run this code straight by the engine compiler, skipping the parsing and the transformation to Intermediate Representation.

Where is Web Assembly Today?

But did WASM pass the test of time?

In 2019, researchers from Braunschweig in Germany looked at Alexa’s top 1 million websites and their use of Web Assembly. They wanted to see what WASM is being used for today.

They analyzed 947,407 websites and 3,465,320 pages. They found that 1,639 websites are loading 1,950 modules of WASM.

The two main uses of WASM were:

  1. Crypto Mining – 32% of the websites used WASM for Cryptocurrency mining (mostly with malicious purposes in hacked websites). The reason they used WASM is that the speed boost also means that computer hardware can be exploited more effectively for cryptojacking attacks.
  2. Gaming – 29.3% of the websites used WASM for gaming. One example is the popular game Doom 3.

However, there are more uses for Web Assembly than just Gaming and Crypto Mining. In fact, Figma, a popular web designing tool, reported that they tripled their loading speed with WASM.

Fastq.bio reported they were able to improve performance by 20 fold. Autocad also used WASM and reported they were able to get native-like speed in the browser.

Conclusion

Web Assembly is definitely a revolutionary technology that allows running heavy software in the browser, something that was not possible before.

With that said, if you’re not trying to run super heavy computation then you probably don’t need to use WASM.

JS is still very fast and still dominates the browser, that doesn’t seem to change with the coming of WASM. Rather than replacing JS, WASM allows for better integrations, and software that uses WASM will most likely use JS too.

Website Performance Monitoring – You Are Doing It Wrong

Posted on by eugene evdokimov

With all the data available today, it’s easy to think that tracking website performance is as simple as installing a few tools and waiting for alerts to appear. Clearly, the challenge to site performance monitoring isn’t a lack of data. The real challenge is understanding what data to look at, what data to ignore, and how to interpret the data you have. Here’s how.

There are five common mistakes that administrators make when tracking website performance. Avoiding these mistakes does not require purchasing any new tools. In order to efficiently avoid these mistakes, you simply need to learn how to work more intelligently with the data visualization tools you already have.

Mistake #1 – Not Considering the End-User Experience

When it comes to things like response times, it’s easy to rely on “objective” speed tests and response logs to determine performance, but that can be a mistake. The speed that is often more important is the perceived speed performance, or how fast an end-user thinks the site is.

Back in 1993, usability expert, Jakob Nielsen pointed out that end users think a 100 millisecond response time is instantaneous and that a one-second response time is acceptable. These are the kinds of measurements you must make, to accommodate end-users, and not rely solely on “backend” data.

Mistake # 2 – Letting Common Errors Obscure New Errors

Common errors, by definition, make up the bulk of the weblog data. These errors occur so often that it’s easy to ignore them. The problem occurs when among a large number of common errors hides a new, unique error that gets missed because of all of the “noise” around it.

It is important that your website performance monitoring tool has the ability to quickly identify these “needles in a haystack.” Short of that, it is essential that the long trail of common errors be mined for new errors. This can give valuable clues to forthcoming performance problems.

Mistake # 3 – Ignoring Old Logs

It’s easy for IT folks to not want to go back and investigate older logs, say greater than one year, but that can be a mistake. Being able to go back and evaluate large quantities of older data, using simplifying techniques such as log patterns or other graphical means, can give great insight. It can also help highlight a slow-developing problem that could easily get missed by strictly focusing on the most recent results.

When establishing site performance monitoring policies, make sure they specify enough historical data to give you the results you need. Assuming you use a site management tool that can accommodate large data sets, it’s better to err on the side of too much data than not enough.

Mistake # 4 – Setting the Wrong Thresholds

Website performance tracking is only as good as the alert thresholds set. Set them too high and you miss a critical event. Set them too low and you get a bunch of false positives which eventually lead to ignoring them.

The reality is that some servers or services being monitored are more prone to instantaneous or temporary performance degradation. This is enough to trigger an alert, but not sufficient to bring it down, and could be due to traffic load or a routing issue. Whatever the reason, the only way around this is trial and error. Make sure you spend the time to optimize the threshold levels for all your systems to give you the actionable information you need.

Mistake #5 – Only Paying Attention to Critical Alerts

The sheer volume of site performance data makes it natural to want to ignore it all until a critical alert appears, but that can be a mistake. Waiting for a critical alert may result in a system outage, which could then impact your ability to meet your Service Level Agreements, and possibly even lead to liquidated damages.

Rarely do systems fail without giving some clues first. It is imperative that you mine your existing data to develop a predictive ability over time. You also need to understand which site performance metrics are worth paying attention to before it costs you any money.

There you have it. Five mistakes to avoid when monitoring website performance. Not more data, but more intelligent use of existing data.