Performance Update - August 2022

TLDR

We've implemented several performance improvements into the Pixel Manager, further extending its lead over other tracking managers.

• Full REST API support
• Pre-compressed Pixel Manager JavaScript libraries added to each new distribution

Full REST API support

We had it on the roadmap for a long time and many of our users have upvoted it: REST API support

Until version 1.17.11 the Pixel Manager was only using the WordPress internal AJAX API to communicate with the server. From version 1.17.12 the Pixel Manager fully supports the REST API.

You probably have questions. What's bad about AJAX? What are the benefits of using the REST API? And, why did it take so long to implement this?

I'll answer one by one.

What's bad about AJAX?

Nothing's is really bad with AJAX. It works, and it has been working very well for a long time. But, there are a few things that are not so good. For instance, each time you make a request to the server through AJAX, the entire WordPress / WooCommerce instance loads on the back-end. This is a significant performance hit. And this is especially an issue if you have a lot of plugins installed that make the server slow.

Also, the AJAX API only offers one endpoint and all the logic to capture server events have to be built into the plugin. This is not a major issue, but it makes for less clean code and more work to maintain.

So, it made sense to look into a better way to communicate with the server.

What are the benefits of using the REST API?

Probably the most important benefit of the REST API is that it only loads a minimal version of WordPress / WooCommerce in the back-end, thus making each request much faster. In our tests REST API calls in average were 30% faster than AJAX calls. This is not only a speed improvement, which is neat. It also means that the server has to work a lot less to handle those requests, freeing up resources. This is especially important when you use server-to-server event tracking such as Facebook CAPI. The Pixel Manager exchanges a lot of data with the server, and using the REST API removes a lot of stress from the server compared to using AJAX.

Plus, creating REST API endpoints in the back-end is cleaner and is more streamlined, making the code easier to maintain and to test.

And, why did it take so long to implement this?

There was a lot of consideration and planning involved in implementing the REST API. You see, AJAX has one big advantage over the REST API. It is active on all WordPress installs and it can't be turned off, or at least no one dares to turn it off. So the AJAX endpoint is available on all shops where the Pixel Manager is installed.

The REST API on the other hand is not active on all shops, even though it is enabled by default. The reason is that when WordPress launched its REST API support, there was a way to enumerate all users of the shop (get a list of all users of a shop). So the REST API publicly revealed more data than most of the shop owners wanted to show. WordPress fixed this, but nonetheless the REST API had become discredited and people started to disable it.

So, we had to build in fallbacks and safeguards in order to make server calls work, no matter which endpoint is active. This made the back-end and the front-end code architecture significantly more complex.

On top of that we had to think ahead and build in more logic that would make the server calls more efficient. You see, more and more platforms start to offer not only browser tracking pixels, but also server-to-server APIs such as Facebook CAPI. TikTok for instance now offers a server-to-server event API too. And in order to handle all of this more efficiently and avoid duplicate data exchange between the front-end and the back-end, we had to restructure the event flow between the front-end and back-end.

All of this took more time than most of us thought it would take. On the bright side, the new architecture is so streamlined and clean, that it will be much easier to scale up and implement new server-to-server event APIs.

A few interesting things about the new REST API implementation

Because the Pixel Manager now primarily uses the REST API, it also takes advantage of a modern method to send tracking events from the browser to the server: navigator.sendBeacon. This method is available in most browsers and has two significant advantages:

• It keeps the connection alive until the data is successfully sent to the server. It does that in a way that doesn't interrupt the visitor experience in any way. And it does this even if the visitor exits a page, making sure that the tracking event is sent to the server, no matter what.

• One additional advantage is that navigator.sendBeacon runs with a lower priority than the main thread. This makes sure that the browsing experience is not slowed down or interrupted by tracking events in the background.

But that's not all. The Pixel Manager detects if a request is too big to be sent through navigator.sendBeacon and automatically falls back to using fetch for sending the event. (fetch is another modern way of sending data to the server. It can handle much more data, but runs at a higher priority.)

And, if the REST API is not available, the Pixel Manager detects this too and automatically falls back to using AJAX.

Neat isn't it?

With this new version the Pixel Manager has become the first tracking manager to fully support the REST API in order to deliver the best possible user experience, highest tracking accuracy while keeping the server load as low as possible.

Pre-compressed Pixel Manager JavaScript libraries added to the distribution

Many shop owners know that JavaScript libraries should be minified. Minification is a way of making the JavaScript libraries smaller and therefore faster to transmit to the browser. That makes a lot of sense. The smaller the code, the faster the transfer to the browser, the faster the page fully loads, the happier the visitor, right?

But, did you know that minification is not as effective as many think and that it takes much more to compress the code to the max?

Minifying a regular JavaScript file only makes it 30% to 40% smaller. That is smaller. Take a look at what a modern toolchain can do to decrease the size of a JavaScript file much more:

Our largest library (packed with all bells and whistles) when only minified is about 115kb large. But, if we pre-compress it using gzip or brotli, it shrinks to only 23kb using gzip and down to 19kb using brotli.

That's an almost 90% reduction of the size of the library from the minified version. Nice!

Now, the more informed ones among you will say, that the server is doing the compression for you on the fly anyway. And yes, that is generally true. But, doing the compression also takes time and thus increases the server load unnecessarily. The following article goes into full detail what happens if you serve pre-compressed vs. on-the-fly compressed libraries and makes the point that it makes a lot of sense to bundle pre-compressed libraries with a distribution: https://css-tricks.com/brotli-static-compression/

Therefore we decided to add pre-compressed JavaScript libraries to each release of the Pixel Manager. This way, your server won't have to do the compression for you, and thus will reduce TTFB (Time To First Byte) even more.

And the good thing about the browsers today is, that they will negotiate with the server which file they want to receive, will opt in for the smallest one that they can process, and you won't have to worry about compatibility at all.