ButtonJS Performance Primer on
All Platforms

ButtonJS Performance Primer

ButtonJS is a small JavaScript snippet that provides the tools to power your mobile partnerships. The zipped size of the JS is 12KB (uncompressed it clocks in at 32KB).

What are the goals of ButtonJS?

ButtonJS aims to be small, fast, and safe. Small refers to the footprint of the javascript being served in terms of file size, fast refers to latency in every phase (user experience, fetching/evaluation of the script, and fetching of available actions), and safe refers to our diligence to fail gracefully in error conditions.

How do we make it small?

We employ a number of tactics to keep the footprint of ButtonJS small. The first is that we have no external dependencies – we do not have a requirement that you have JS libraries such as jQuery or lodash or even tiny utility libraries available on your page. Beyond that we leverage the Google Closure Compiler heavily to analyze and optimize code paths, remove dead code, and aggressively shrink the size of the resulting file.

How do we make it fast?

ButtonJS is served from Amazon’s Global Content Delivery Network (Cloudfront). The file is distributed to all edge locations ensuring high speeds wherever in the world your users are located. All requests for ButtonJS are gzipped, drastically reducing the amount of data being sent over the wire, and served with cache headers such that subsequent requests for the JS will be fulfilled from the user’s browser cache.

How do we make it safe?

As mentioned above, the Google Closure Compiler provides a lot in terms of code analysis and catches many common classes of JS errors (loose type constraints, typos, etc). Additionally the JS only runs if a few up-front checks determine that the current browser can support it. To be safe, we catch any potential errors that may arise from things like parsing invalid JSON or invalid property access. We additionally have a large test suite which runs against all major browsers (desktop + mobile) to ensure that nothing slips through the cracks.

What is the load time of ButtonJS?

When considering the load time for using ButtonJS it’s helpful to break the concept of "loading" into two phases: the JS, and the action(s). The first time ButtonJS is fetched we need to download the gzipped file, which hovers around 12KB currently. On subsequent requests, the file will be served from the local browser cache. This file is loaded asynchronously and in the standard implementation has no impact on page load. When evaluating the loading of available actions this measurement becomes more dependent on the specific connection. For example, to display an Uber Button our servers need to verify the pricing and availability of Uber in the desired area. It’s important to note that this also occurs asynchronously and while a Button may not display immediately, there should be no other impact on user experience.