Gravity Forms and Optimization Plugins: Strategies for Performance
By Sam Estok
Published December 5, 2023
This hare wins this race every time! Let’s examine how many of the most popular WordPress plugins’ optimization strategies align with the state of server, browser, and asset technologies in the current landscape…
You Know You Need It
Website performance is a critical consideration for anyone serving up their hard work to online audiences, and therefore it’s one of the key factors most people managing their websites spend a lot of time focusing on. Performance directly impacts user experience, SEO ranking, conversion, and many other key metrics we use to monitor engagement and reach, and ultimately the greater success of our projects.
In the WordPress space, the number one move most people who are performance-minded will make is to search the space for optimization plugins, and they will not be disappointed in the amount of great choices they have.
That said, the purpose of this article is not to review any particular plugins or make suggestions on which to choose, it is to go over one of the main features almost all of these plugins focus a fair bit on, script and style optimization through concatenation (smush all those bad JavaScript and CSS files into one big ball and serve them late in the pages render).
That has to be a good thing right? Maybe…
The Big Wins
Before getting into this smush aspect of optimization strategies, it’s important to note all of the undeniably excellent features most well-crafted optimization plugins can bring to your website. We get excellent features such as:
- Strategies that simplify advanced caching approaches such as Object Cache when your server supports it
- CDN offloading of resources
- Image optimization
- Lazy loading
- Applying deferred loading to scripts that don’t have it
- Cloudflare integrations
and many more.
If you are a developer it’s often true that your own implementations of these strategies will usually have advantages over using one of these plugins to achieve them, but WordPress is made for everyone, and that’s where these helpful plugins come into play, allowing any website manager to enable all of these advanced features with ease.
That being said, our tendency when using any plugin that promises to make things so much better is to engage all the things. Heck, we’ve all seen many cases of multiple optimization plugins being enabled on sites, because, well, three have to be better than one, right!? (don’t do that, it brings all kinds of woes, and you should never need more than one for this task).
Crush All The Things
Now to the point of this article. A key feature in most of these plugins is a setting that will say something like “Minify and Combine All CSS and JS into single files” usually followed by some promise that this will turn your tractor into a supercar.
There is still some validity to this claim and strategy, but it’s mostly related to when our server and browser environments were far more limited in features related to asset delivery, and the assets themselves were constructed in less optimal ways. We’ll go over why you might not need this strategy anymore, from a pros and cons perspective, and finish with an analysis of Gravity Forms’ own built-in approaches.
1, 2, 3, It’s HTTP
Our URLs start with it: The Hypertext Transfer Protocol (HTTP) is the protocol used for transmitting data over the internet, enabling the fetching of resources such as HTML documents. It defines how messages are formatted and transmitted, and how web servers and browsers should respond to various commands.
HTTP/1 was released in 1996, and one year after came HTTP/1.1, which has basically hung out to this day to some degree, an amazing feat in any web-based technology across time. Its main limitation that we care about in regard to the topic at hand is its inefficient handling of multiple requests for resources between the browser and the server (due to head-of-line blocking). So, having 32 JavaScript files to serve up like it was 1998 would most definitely benefit from the combined files strategy these optimization plugins are promoting on HTTP/1.1. But wait! HTTP actually woke up after a long sleep.
In 2015, HTTP/2 was published, boasting excellent optimization of the multiple resource requests issue described above (through multiplexing capabilities over one TCP connection), and 2022 saw the release of HTTP/3 with even more gains in this regard (QUIC for one). From a browser perspective, an HTTP/2 or 3-enabled server mostly negates the gains you achieve from combining all asset files into one big file, and in some ways can have detrimental effects, depending on other factors. Before getting into those, it is important to note that smart bundling of some assets can still have a beneficial effect on these protocols, eg in the case of bundling for the critical rendering path, but it is notoriously difficult for one-size-fits-all plugins like the ones we are discussing to achieve this.
As of the writing of this article, most servers support either HTTP/2/3, and it’s easy to check if your server does, eg using this simple Chrome extension. Browser support is in the mid-90 %.
Don’t Get In The Way: Deferring Scripts
Just like in the way that HTTP/1.1 will block concurrent requests from making their way to the browser in tandem affecting initial loading performance, css and most javascript are render blocking and stop the browser from continuing to render the page until they are loaded. This is why it became common to load as many scripts as we could in the footer long ago, at least mitigating this for non-critical JS quite easily.
In the case of a plugin like Gravity Forms or its ecosystem, the situation becomes quite more difficult. The plugin environment is a complicated one requiring you to ensure that your scripts will be available when you need them in a mix of other factors, and older versions of Gravity Forms did indeed block rendering until their scripts were loaded to accommodate this need.
That all changed with Gravity Forms 2.5, which brought in the deferred attribute for all of our theme-side scripts. While a bit of a difficult endeavor for us, the performance gains for our customers made it worth it. This prevented all of our scripts from blocking page rendering, and combined with HTTP/2/3 capabilities further negated any benefits gained from bundling all JavaScript into such monoliths.
Many optimizer plugins offer this as a separate option to the combination of files (usually a setting that says something like “defer all scripts”), and if it doesn’t cause you any issues, I do recommend you enable this.
How Combining Files Has Some Detrimental Effects
Now for some downsides to the combine-it-all strategy.
The first big one is the browser cache. In the case of Gravity Forms, we supply all of our deferred files with version strings, and the modern bundles we are steadily migrating our code to go even further and use the file hash for each file served as its version string. What this means is that your visitor’s browsers will cache those files until they actually change (or their caches are purged).
So, even if you update Gravity Forms, but only one of our scripts changed, a repeat visitor will only have their browser cache updated for that one file, not all of our scripts. This is very efficient, especially compared to the fact that when you combine all JavaScript files into one, every time you update anything on your site, the entirety of the JavaScript you are serving will have to be reloaded by all of your repeat visitors. Hopefully, you can see the inefficiency in this, especially for sites that stay up to date continually with many plugins, which is always good practice.
Beyond this, our current bundles – and many others in the WordPress ecosystem – now use code-splitting to dynamically inject scripts only when they are needed. These optimization combiners can cause annoying issues for systems that use code-splitting, and we have had to continually adapt our systems to accommodate them when it’s usually of well, little benefit.
Wrapping Up
Optimization plugins are a great asset to the WordPress ecosystem and serve an important role in bringing performance to people who need caching and other optimizations for their websites quickly and easily.
If you do find yourself using the combine all css/JavaScript assets feature and have found it to cause you issues, or you really love to analyze the performance of your website from every angle possible, do consider the above information. If you are on HTTP/2/3, are using Gravity Forms 2.5 and up, and are deferring other scripts then you probably don’t need it enabled.
And if you still want to use it while having Gravity Forms active, you will get more stable and reliable use from our plugin – while experiencing no performance drop – by disabling it for our scripts and any others that already defer/code-split out of the box.
If you want to keep up-to-date with what’s happening on the blog sign up for the Gravity Forms newsletter!