AJAX, asynchronous javascript requests and RESTful APIs together can create an interactive web experience in a manner that reduces resource usage in both CPU and network without having to reload the whole page, but despite the colourful sounding technology, is this better than the plain old method? In this article i’ll be discussing the usage with ground up php scripts and php frameworks, which we’ll use wordpress for this.
WordPress is not a framework first, it is a php CMS first, framework second. I only code using wordpress to extend its functionality as a content management system, adding a much better remote interface in this case. Having asynchronous tasks and only updating changes is very efficient but has its drawbacks especially with wordpress.
Asynchronous events are very good in a sense but actually less efficient to the CPU than traditional loops (old case for openGL 2.1 vs dx9, windows and linux) in where the traditional loops were faster (CPU crunching was faster than waiting for data to move around the architecture and coming back to the CPU) but created blocking events whereby something else couldnt be processed while the loop was taking place. Modern games and GPUs use non blocking asynchronous architectures which if you have ever played a game requiring high end visuals, you will noticed things like textures and geomatry details can end up loading in late after the map has loaded and the game started. But is all of this worth the hassle? Even in loading of websites we have defer and asynchronous javascript (letting you load the file first, render it after the page has loaded), and the same for css. What happens here is the website starts rendering in parts, which is good if it all happens within a certain timespan, but bad if it happens seconds after the website has loaded and user started scrolling through (looking at you news sites with layout changing ads and content).
Whether you use wordpress for this or just php code from the ground up, this induces significant delay, but in wordpress refreshing the page will always take longer and transfer more data than ever. For instance not only do you have your content data but you also have the entire site data for that particular page you are refreshing, increasing server and client CPU load, network and taking longer in total. Benchmarks will complain of slow server response with this especially when you cant cache the entire page, but it often times is the more efficient way with faster times in total. Below is an example timing from one of my work along with in javascript clientside timing.
The timing looks atrocious but there’s a lot not said with the standard woocommerce order browse method of having to refresh, although being able to run without javascript is crucial when you are using a security plugin to rid the website of malware/injected code. Especially on shared hosts, admin pages of many websites load very slowly taking seconds. The AJAX+REST method of 1.5s is a lot lot faster in comparison using only KBs of data rather than MBs (many wordpress sites are atrocious in network use, taking up MBs per page). wordpress AJAX only uses a hook on the php side (no differences for pure javascript side) while REST is pretty standard wordpress or not in request so it is very easy to pick up and learn without using any jquery.
My plugin has to keep secrets secret, this means it has to be the in between from client and remote server, adding to the delay. There is no way around this to avoid unnecessary secret info available on the client machine while using a secure connection method to the remote server. In simple terms it works like this (load order page) -> Client requests data via AJAX -> wordpress plugin -> remote server -> wordpress plugin -> client . Quite a chain compared to cutting out the middle man and going straight to the remote server with less security, but rest assured its still faster than refreshing the page in wordpress admin on the remote website. The changes also workout a lot smoother too with only a portion of the page changing with new data of what you’re expecting to see, while also being a lot more secure and only giving the client the data and code they need, not everything from the server that they dont need that could be exploited later on. It adds more steps and work but you should always be thinking about security when it comes to e-commerce, as sometimes bypassing a step might not be the best way in security as the first part of loading wordpress requires a user with sufficient privileges logged in, and should the user not be authorised you do not want to provide them with irrelevant secure data for something else either.
However this chain and delay triggers benchmarks with the turtle sign appearing saying server response is too high, but not having to reload the entire page is a much bigger saver in all aspects even time. This can be significantly reduced with non framework php specific code to address each particular website with their database directly without going through wordpress (no modularity and more configuration when adding to any other website), but it can significantly reduce the response so its not without its cure, if only wordpress plugin developers decided to make their code fast and also good, response would be a lot less of a problem as everytime wordpress is loaded, it has to load its plugins as well and most plugins are not made with speed in mind, only to get the job done. Even the theme has to be loaded as well which shouldnt be needed for an AJAX request. WordPress should set its ajax requests to load only the plugin involved and wordpress and nothing else unless specified for other plugins and themes.
In summary chaining requests like AJAX + REST is still worth it despite the delay, as most wordpress sites are very heavy, sporting heavy plugins that are poorly developed (frameworks in frameworks), heavy themes and page builders (these are a nightmare in page loads and optimisation). Being able to selectively load wordpress or only code related to the query is a lot lot better but wordpress doesnt have this feature only hooks for different stages of loading. The resource savings though is still good despite benchmark scores and warnings, as this is one of the things that often people will tell you not to do but is actually a good alternative than the normal methods available.