在网上的资料的介绍中，可以知道，WASM的执行速度要比其它一些JIT的解释型语言高很多。一个最直接的结果就是一些大型游戏和一些复杂的绘图工作都可以在网页上进行了。
为什么它的执行效率这么高呢？在前面提到过，一般JIT都是边解释边编译边优化，如果优化过度还需要反优化，再优化的过程。而WASM则是直接编译成抽象的字节码，只需要在执行过程中由引擎编译成机器码正常执行即可。
WASM的执行仍然是基于栈的方式，或者说基于栈的虚拟机方式。所谓基于基于栈的虚拟机，就是一个OpCode需要的所有的值，在操作执行之前都已经存放在了堆栈中。由于操作符事先知道自己需要多少值，那么它就可以从栈的顶端弹出相应的数量即可。那么这些指令，就可以相对的来说变得更短，比如说变成一个字节的长度。因为指令不需要对相关的寄存器进行管理，也会相应的减少wasm文件中对寄存器操作的OpCode和相关操作，从而减小wasm的文件。
但是一定要分清楚，这只是虚拟机的部分，真正的当其被加载到浏览器时，浏览器会通过编译来应用实体机的各种寄存器。也正是因为wasm没有指定相应的寄存器，这也给浏览器加载时带来了很大的自由度，由自己的编译器来决定使用哪些寄存器的效率更高。
WASM目前主要是在浏览器上应用，所以其执行的第一步是从服务器获得相关的WASM文件，由于其在编译过程中省略了很多的工作，所以其文件相对其它解释型的文件来说要小很多，这对于网络上的数据流动，有着很高的效率。
浏览器拿到WASM文件后，将其转换成一个typed array或arraybuffer.
因为在LLVM IR的过程中，相关的优化已经完成，所以此处不需要太多的优化，这就意味着编译的速度非常快。同时，由于WASM的类型固定，编译的过程不需要要解释语言的推导过程，也在另一个方面上提高了效率。
编译器把上面的字节流编译成相关的Module并根据实际情况生成实例并翻译成机器码。
在编译到机器码后，其执行效率可想而知。但是Webassembly的一个缺点是，资源的管理（内存等）目前还是个空白，所以需要手动来控制。这个仁者见仁，不做过多解释。
其在执行过程中还是有不少问题需要完善的，比如WASM对JS中的一些元素的调用的问题等，这都需要进一步的发展。毕竟目前只是MVP的最小功能版本。
上面简要的分析了Webassembly的执行方式，并将其执行的流程进行了初步的说明。实际上，WASM在执行上还是具有非常大的优势的。也正是因为它的这种抽象机器码的执行格式，使得它的应用前景还是非常不错的。虽然目前其仍有很多需要改进的地方，但从目前发展的速度来看，还是让人有很大的希望的。