Website speed matters now more than ever. If you’re using WPBakery Visual Composer on WordPress, you know it’s a fantastic tool for creating stunning websites. But its impact on performance can’t be ignored. Bloated code and excessive requests slow things down, hurting both user experience and SEO. Let’s dive into some practical tips and technical know-how to optimize your site’s speed and ensure it passes Google’s Core Web Vitals benchmarks.
Understanding the Challenge
WPBakery Visual Composer makes website building easy, but it comes with a speed cost. Bloated code and render-blocking scripts can seriously slow things down. This affects how users interact with your site and can hurt your search engine rankings.
Making the Most of Key Tools
1. WP Rocket: Turbocharge Your Caching
WP Rocket is a powerhouse for optimizing site performance. Here’s how you can configure it:
- Install and activate the WP Rocket plugin from the WordPress plugin repository.
- Navigate to the WP Rocket settings in your WordPress dashboard.
- Enable features such as page caching, GZIP compression, and browser caching.
- Configure advanced settings according to your site’s requirements.
- Save your changes and test your site’s performance.
By caching pages and enabling GZIP compression and browser caching, WP Rocket significantly improves loading times, which is key for meeting Core Web Vitals standards.
2. Autoptimize: Streamline JS and CSS
Autoptimize is your go-to for optimizing CSS and JavaScript. Here’s how you can configure it:
- Install and activate the Autoptimize plugin from the WordPress plugin repository.
- Navigate to the Autoptimize settings in your WordPress dashboard.
- Enable options for optimizing CSS and JavaScript files.
- Configure additional settings such as minification and concatenation.
- Save your changes and test your site’s performance.
By minifying and combining assets, Autoptimize reduces HTTP requests and improves loading times, crucial for Core Web Vitals.
3. Nginx: Unleash Server-Side Speed Enhancements
Nginx offers a range of optimizations. Here’s a snippet to enable GZIP compression:
# Enable GZIP compression
# GZIP Settings
gzip on;
gzip_min_length 256;
gzip_comp_level 6;
gzip_buffers 32 16k;
gzip_http_version 1.1;
gzip_proxied any;
gzip_vary on;
gzip_types *;
With browser caching and HTTP/2 support, Nginx can significantly boost your site’s performance. You can also utilize brotli compression :
# Brotli Settings
brotli on;
brotli_comp_level 6;
#brotli_buffers 32 8k;
#brotli_min_length 100;
brotli_static on;
brotli_types application/atom+xml application/javascript application/json application/rss+xml
application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype
application/x-font-ttf application/x-javascript application/xhtml+xml application/xml
font/eot font/opentype font/otf font/truetype image/svg+xml image/vnd.microsoft.icon
image/x-icon image/x-win-bitmap text/css text/javascript text/plain text/xml;
Lastly you want to utilize the nginx expires configuration directive to allow for manipulation of the Expires and Cache-Control header to facilitate local browser caching :
# Expires for local caching
expires 1y;
4. Varnish Cache: Amplify Your Caching Strategy
Varnish Cache acts as a powerful reverse proxy server. Setting it up involves configuring caching rules to integrate closely with WordPress’ URL structure most importantly to accommodate what to cache and what not to cache.
Most of the configuration within varnish will happen within the vcl_recv configuration rules.
Strip all cookies except whats important
set req.http.Cookie = regsuball(req.http.Cookie, "(^|; ) *_ok(?:[bklv]{2})?=[^;]+;? *", "\1"); # removes olark cookies (_ok, _okkb, _oklv)
set req.http.Cookie = regsuball(req.http.Cookie, "(^|; ) *hblid=[^;]+;? *", "\1"); # removes olark cookie (hblid)
set req.http.Cookie = regsuball(req.http.Cookie, "(^|; ) *wcsid=[^;]+;? *", "\1"); # removes olark cookie (wcsid)
set req.http.Cookie = regsuball(req.http.Cookie, "(^|; ) *olfsk=[^;]+;? *", "\1"); # removes olark cookie (olfsk)
set req.http.Cookie = regsuball(req.http.Cookie, "(^|; ) *omp__super_properties=[^;]+;? *", "\1"); # removes olark cookie (omp__super_properties)
# Remove has_js and Google Analytics __* cookies.
set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(__[a-z]+|has_js)=[^;]*", "");
# Remove a ";" prefix, if present.
set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", "");
# Remove empty cookies.
if (req.http.Cookie ~ "^\s*$") {
unset req.http.Cookie;
}
The above snippet can be customized to accommodate any custom cookies that are in use on your site.
Rewrite all non-HTTPS requests
This is optional but since Varnish is likely the edge of incoming requests, is most ideal to rewrite non-HTTPS request to the HTTPS version of your site :
if (req.http.X-Forwarded-Proto !~ "(?i)https") {
set req.http.x-Redir-Url = "https://shift8web.ca" + req.url;
return (synth(750, req.http.x-Redir-Url));
}
Dont forget to also set the vcl_synth function to handle the redirect :
sub vcl_synth {
#redirect to login.thebigrock.com
if (resp.status == 750) {
set resp.http.Location = resp.reason;
set resp.status = 301;
return(deliver);
}
}
Dont cache admin or login requests
We absolutely do not want to cache the admin dashboard or login requests. This means we want to match URL patterns to ensure this never happens in varnish. We dont want a cached admin page to be visible to the anonymous user!
if (req.url ~ "^/wp-admin/(.*)"){
set req.backend_hint = your.backend();
return(pipe);
}
if (req.url ~ "^/wp-login.php(.*)"){
set req.backend_hint = your.backend();
return(pipe);
}
if (req.method == "POST") {
set req.backend_hint = your.backend();
return(pipe);
}
Finish off vcl_recv by caching everything else
The snippet below for varnish configuration will include ensuring all images are cached and the last directive if none of the other above patterns match is to just cache everything else :
if (req.url ~ ".(gif|jpg|jpeg|png|css|js)") {
set req.backend_hint = shift8stockfarm.backend();
return (hash);
#return(pipe);
}
set req.backend_hint = shift8stockfarm.backend();
return (hash);
By caching static assets, Varnish Cache reduces server load and improves loading times, essential for meeting Core Web Vitals standards.
5. WPBakery Visual Composer Options: Fine-Tune for Performance
Within WPBakery Visual Composer, you have control over asset loading and library usage. Here’s an example of a functions.php change :
// Remove unnecessary WPBakery Visual Composer elements
add_action('vc_before_init', 'my_vc_remove_elements');
function my_vc_remove_elements() {
vc_remove_element('vc_foo');
vc_remove_element('vc_bar');
}
Remove gutenberg block library css from loading on the front end
If you are not using gutenberg (especially if you are using visual composer), you want to trim the library CSS from being loaded on the front end of your site :
//Remove Gutenberg Block Library CSS from loading on the frontend
function shift8_remove_wp_block_library_css(){
wp_dequeue_style( 'wp-block-library' );
wp_dequeue_style( 'wp-block-library-theme' );
wp_dequeue_style( 'wc-blocks-style' ); // Remove WooCommerce block CSS
wp_dequeue_style( 'vc_font_awesome_5' );
wp_dequeue_style( 'vc_carousel_css' );
wp_deregister_style( 'vc_font_awesome_5' );
wp_deregister_style( 'vc_carousel_css' );
}
add_action( 'wp_enqueue_scripts', 'shift8_remove_wp_block_library_css', 100 );
Remove Visual Composer scripts that aren’t needed
Similarly to the gutenberg change above, you may not need the entire (bloated) visual composer library assets / scripts to be loaded for every page. You can expand on the snippet below to include the script libraries that are not needed for your site :
// Remove enqueued scripts that arent needed
add_action( 'wp_print_scripts', 'shift8_dequeue_script', 100 );
function shift8_dequeue_script() {
wp_dequeue_script( 'vc_carousel_js' );
wp_dequeue_script( 'vc_pageable_owl' );
}
add_filter( 'script_loader_tag', 'shift8_defer_scripts', 10, 3 );
The next snippet can technically be accommodated by Autoptomize or WP Rocket but its important to note that we can also selectively set loaded JS scripts to be deferred via a functions.php change in your theme :
add_filter( 'script_loader_tag', 'shift8_defer_scripts', 10, 3 );
function shift8_defer_scripts( $tag, $handle, $src ) {
// The handles of the enqueued scripts we want to defer
$defer_scripts = array(
'popmodern',
);
if ( in_array( $handle, $defer_scripts ) ) {
return '' . "\n";
}
return $tag;
}
The above snippet simply searches for a script label identifier (in the above case its “popmodern”) and search/replaces the html before its rendered in the browser to include the defer statement in the script tag. The “defer_scripts” array can be added to and modified in the above snippet to accommodate whatever you need.
Fine-tuning these aforementioned settings reduces bloat and ensures smoother performance, aligning with Core Web Vitals requirements recommendations.
Putting It Into Practice
With these practical strategies and technical insights, you’re ready to optimize your WPBakery Visual Composer site for speed and performance. By implementing caching mechanisms, streamlining asset delivery, and fine-tuning settings, you’ll enhance user experience and maintain strong search engine rankings.
Conclusion
Optimizing your WPBakery Visual Composer site for speed is crucial in today’s competitive online landscape. By leveraging tools like WP Rocket, Autoptimize, Nginx, Varnish Cache, and WPBakery Visual Composer, you’ll ensure your site not only loads quickly but also meets Google’s Core Web Vitals criteria. So, roll up your sleeves, dive into the technical details, and take your site’s performance to the next level!