Approaching Performance


We don't have to tackle everything related to a whole page load to get great results.

  • Whatever we think of Google, they have helped us to prioritize.
  • Performance is now a measure of the visitor's experience. How fast and smoothly things load in the viewports of their devices.
  •  When we stop looking at the whole page load and focus on the viewport things look different.
  • Generic advice may not help: i.e. better hosting, removing plugins, adding a CDN.  Context is needed.
  • It not so much about how many assets and requests we have on a page, but how and when they are served to visitors.

  • It's easy to get lost and over optimize  if we start blinding ticking boxes in tools like Asset CleanUp, Performance MattersFlying Press and addon option in various caching plugins.  It is easy to create error or break functionality. Commonly I see the breaking mobile navigation. Probably best used after the more fundamental stuff is optmized.
  • Often a few snippets in our child theme's functions.php file can replace the main benefits of optimization plugins.
  • It's easy to start chasing the "fastest" theme, builder and hosting. Unless you know your tool is actually preventing you getting a good performance, it's easier to learn how one set of  tools work... Naturally,  Gutenberg is the lightest option, but  does not have page builder layout features (and associated bloat - yet!)  most get them from a 3rd party blocks and are back dealing with the same optimization issues, but minus the benefits made us chose a page builder (mostly client ease in my case) .
    (The business template here was cited as reason to change platforms. All that was required to get a 100 PSI mobile score was optimisation of an image).


Focussing Largest Contentful Paint (LCP)

  • LCP is the time it takes to load the largest element in the viewport.
  • We probably want to focus on the mobile view (as Google is presently).
  • Focus on our headers/hero sections and what needs to load first (images, CSS , JS, Fonts etc) to show that largest element.
  • We can get clues from "waterfall". ( and
  • Google also tells about render-blocking resources. Files that pauses the loading of the DOM. The jQuery problem: hard to defer from due to dependencies calling from a CDN not worth it.

Google's PageSpeed Insights (showing the largest element)


Google's PageSpeed Insights (showing us things we could consider deferring or removing)

Render Blocks
  •  We can inspect our (chromium) browsers and see lots of real time performance performance data. The coverage tab is handy for finding unused CSS and JS (thanks to Nathan Wrigley).  Although if we want the benefits of code free WYSIWYG platforms we probably have to accept a degree of unused code.


Looking at whole site

  • CrUX  (Chrome User Experience Report) is aggregating the experience of all pages served on the domain. So it may be best to focus on your most visited pages.
  •  However, apparently we can not hide pages from Google so we may want to check out worse pages (thinking of Origin Summary)
  •  Field data gradually changes over a period 28 days you may want notifications of site (Thanks to David McCan).
  • CWV as a SEO ranking factor is probably business as usual.  You only need to do better than your competition.
Gcv Wp

Improving THE Largest Contentful Paint

Image optimization (viewport)

  • Getting the smallest file sizes particularly is an image is the largest element (ShortPixel does that for me).
  • Serving sizes most appropriate to the device loading it. No point in loading a 1920px wide background image to a 420px device,
  • Using SVGs (if vector styled imagery ). SVG logo perhaps.
  • Avoiding images (perhaps removing for mobiles only).
  • WebP seems like the solution for the near future. Presently it is not without (performance) issues. Thanks to Paul Lacey. (Often worth ignoring the "Serve images in next-gen formats" warning).
  • WP's support of srcset and lazy load is still to be explored in relation to how they work on Beaver Builder.

Caching (hosting)

A long "Time to First Byte" (TTFB) generally is reason for not getting a good LCP score. Mostly due to resource heavy plugins/themes we don't have enough server power for due to the time it take WP to process the PHP functions and query the database.

For client sites I use WP Rocket. On this site I am now experimenting with  During my tests I constantly got the same scores without caching of any form and with light plugins for SEO, Security and Backups.

This is really the topic for another video because of the different forms of caching available. Ideally are hosting are builds and hosting should be good enough to manage without it, but I could help with load impact and potential save the planet by allowing us to put less strain on servers.



Gzipping is working here:


You can test your server support this ( In get over limitation HTTP 1 had over the number of connections it could make. Now combining CSS and JS files is not so beneficial. (arguably pointless).

This could have some major benefits for LCP - it could be something BB need to look in to in the future as they combine for us.



Maybe setting (mobile) hero sections to 100 vh.  Maybe removing (background) images for mobile?   Simple navigation and a focus on a good headline has always been the key to conversion.  Perhaps happy days for those who want to argue against a viewport sliders and for simple messaging.


Watch out for heavy plugins that may drain the Time to First Byte. Tools like Query Monitor and UsageDD can help, but check the waterfall for asset being loaded that could impact on the LCP.


  • Consider deferring  the loading CSS and JS.CSS technique : Also a feature in WP Rocket .
    JS technique:

    /* Defer JavaScript - except jQuery */
    if ( is_user_logged_in() ) {} else {
    function defer_parsing_of_js ( $url ) {
    if ( FALSE === strpos( $url, '.js' ) ) return $url;
    if ( strpos( $url, 'jquery.min.js' ) ) return $url;
    return "$url' defer='defer";
    add_filter( 'clean_url', 'defer_parsing_of_js', 11, 1 );}
  • Consider Preloading/prefetching/preconnecting and lazy load assets. I have started using this here, but I need to do research more. Effectively move stuff up the waterfall.
  • Consider dequeuing unused CSS and JS (by page type)
  • Check for console errors!!!
  • PSI is not measuring background video like GT Metrix, but probably will so optimize them (
  • This plugin will remove the (Gutenberg) blocks CSS
  • Probably the biggest performance killers are 3rd party scripts (videos, maps, fonts, analytics, tracking scripts, Live chat applications, GDPR/Cookie notices, pop-ups etc.).

As mention before we have to be mindful that this is just one of over 200 racking factors for Google. We make compromises choosing WordPress and Page Builders for it benefits. Of course, we have more unused HTML, CSS and JS, but in cleaning it all up we lose the flexibility (out client may need) to go in and add new types of content freely. There is a balance to be found.

You can support my work by buying the tools I use through my affiliate links:

Discounts on these two lifetime deals:

MainWP.   Discount code "digitalfreedoms" 15% off
WP Code Box.  Discount  code "beaverjunction"  25% off


WP Rocket | ShortPixel | Beaver Builder | Advanced Database Cleaner