Toolset Blocks 1.5 – Faster Sites for Better SEO Ranking

   Dario

Announcements

April 21, 2021
36

In June 2021, Google will start ranking pages by speed. Toolset Blocks 1.5 includes the performance optimizations that help your sites reach top positions in search results.

Why your site needs to be fast

In June, Google is set to update its algorithm for page-ranking and include a new factor they call Web Vitals. In short, your site will have to load fast to rank well.

The idea behind this change is to ensure a better web experience for users. Everyone prefers sites that are faster, become interactive quickly and whose content doesn’t “jump” while viewing it.

Before you dig deeper you really must understand the metrics Google will use to rank sites. 

These are the three things that Google checks:

  • Largest Contentful Paint (LCP): this is the time needed to load the page. However, Google focuses only on the viewport*. For this, it measures the loading time of the largest visible image or a block of text. The loading needs to happen within 2.5 seconds of when the browser requests the page.
  • First Input Delay (FID): this is the time from when the page displays and until it responds to user actions (like mouse clicks or keyboard typing). Google expects this delay to be under 100 milliseconds.
  • Cumulative Layout Shift (CLS): in general, page elements shouldn’t move while or after the page loads. Google checks the starting point of all elements and if their position changes, it calculates how much they moved relative to the viewport size. For a good score, this number should be less than 0.1.

* Viewport is what users can actually see on their screen right away, without scrolling, for example.

Let’s take a look at two popular WordPress-related sites and how they’re doing (please note that these are just examples measured at the time of writing this article and that we’re fans of both sites):

WordPress Tavern

WPBeginner

As you can see, WPBeginner is almost in the green, which starts at 90. However, WordPress Tavern still has significant improvements to work out. 

Site owners need to understand the implications of having a slow-loading site and take necessary action on time.

How to test your site’s speed

To check your site’s performance, use Google PageSpeed Insights.

When you enter your site’s address, the system will measure its performance and provide you with a summary. Google calls this the Lighthouse Performance Score. In general, you want your site performance to be “green”.

By default, Google tests the “mobile experience” which simply means simulating a slower connection and using less parallel connections. You should also concentrate on mobile devices. If your site doesn’t rank well for mobile it won’t rank well for other devices as well.

The score is divided into sections and all listed items use a simple color code:

  • 0 to 49 (red): Poor
  • 50 to 89 (orange): Needs Improvement
  • 90 to 100 (green): Good
Color coding of PageSpeed Insights test results

To understand what’s causing problems in your site, start with the Opportunities section. It lists the top six issues on your site.

Opportunities section of the PageSpeed Insights

Clicking on any of these displays detailed information about that issue.

For example, here’s the expanded information for the issue with “render-blocking resources”. These are resources that the page needs to wait for before it will render.

Detailed information for the “render-blocking resources”

As you can see at the top, PageSpeed Insights automatically detects WordPress and gives you suggestions on possible solutions. This includes links to the WordPress plugin repository with relevant search for plugins that can help you optimize how your site loads resources.

You can also see a list of resource files that your site loads. These come from your theme, plugins, and even Google services (the first item on the above list is for Google Tag Manager).

You can also see how much time it takes to load each resource, which helps you determine the ones with the biggest (negative) impact.

Finally, it’s important to understand that many metrics are connected. This means that improving one will improve others. For example, improving the Largest Contentful Paint time will improve the Time to Interactive.

What makes WordPress sites slow

There are many things that typically slow down WordPress sites. One of the most common issues is that themes and plugins load too many resource files. What’s worst, they often load them even when it’s not necessary.

Each plugin that you add will typically add some JavaScript and CSS files. Even if the output of that plugin only appears on one page, all the pages in your site will load these resources.

In the past, many people relied on the fact that browsers cache everything on the first load and are fast from that point on. While this is true, it’s no longer relevant because Google will penalize websites that load slowly even once.

Our speed-optimization checklist for WordPress sites

Here is a list of things that you can easily implement, without needing the help of a “speed guru”:

  • Use a lightweight theme (check the theme’s CSS and JS files to determine how lightweight it really is).
  • Reduce the number of plugins you’re using. Each plugin adds to the loading time.
  • Evaluate the resources that each plugin ads, compare to alternatives, and pick the plugin that does what you need with the minimal resources.
  • Use a cache plugin and enable at least page caching and CDN.
  • Use “lazy loading” for large resources you cannot avoid (like Google Analytics or Facebook Pixel) which means loading them only after the page loads.
  • Make sure all images also use “lazy loading”. Your site should also load images in size relative to the screen size of the user’s device. 
  • Load videos asynchronously (not blocking the page render).
  • Avoid complex visual designs with a ton of styling and graphics. All of this takes time to load and render.
  • Use a fast host (if the host takes ages to load, everything you’re optimizing doesn’t help).

Until recently, combining resources would help page speed. For example, combining all CSS into one file. However, today this is meaningless because browsers don’t open new connections for each file anymore. So now, pages should simply load fewer resources that are as small as possible.

How Toolset optimizes resource loading

In Toolset Blocks 1.5, we completely rewrote Toolset’s asset loading, to eliminate any waste and make your sites load fast.

Toolset will not load all its block styles anymore. Instead, on the initial page load, it now loads only the necessary block styles. Once the page is ready we load the complete styling file. This way Toolset loads exactly what each page needs, without any spare baggage.

Additionally, the Toolset Image block includes lazy loading.

Testing the new improvements

We’ve tested Toolset before and after the new optimization and we’re very proud of the results!

We used the BlankState theme and tested speed in two main scenarios:

  • Page with regular content coming from your site
  • Page that also loads external content like YouTube videos

The following graph shows the results for these two scenarios.

As you can see, the performance improvement will be most visible on sites that also load external content like videos. On such a page, the loading time in our test went down from 5 seconds to only 1.1 seconds (of which Toolset takes 0.1 seconds).

Performance now becomes a major benefit when using Toolset. It has a huge performance advantage against using multiple plugins from different authors to achieve what Toolset does.

Which themes perform best with Toolset?

A good theme’s impact on the site’s performance should be negligible. It mostly comes from the CSS and JavaScript files it loads.

We checked the Toolset-recommended themes for you. You can see the numbers in the following table.

ThemeSize of loaded files
Twenty Twenty-One275.3 KB
Astra204.3 KB
OceanWP710.7 KB
Kadence221.9 KB
Page Builder Framework271.3 KB
GeneratePress142.7 KB

We didn’t list the number of files each theme loads because today, that doesn’t impact the performance anymore. In the past, browsers could handle only a small amount of concurrent requests so the fewer files you loaded, the impact on performance was smaller.

In conclusion, all Toolset-recommended themes should provide fast and snappy performance for your site.

How to proceed

June 2021 is around the corner, so our advice is to start testing and optimizing your sites right away. Don’t wait for others to solve these problems for you. Taking action as soon as possible will give you a head start and actually make your sites better for users.

You should consider removing all non-essential plugins or using less plugins that have the functionality you need. 

Finally, you can contact our support for any comments and help related to Toolset’s own performance. We will be happy to get the feedback and help you.

Feedback, Comments?

What’s your plan to prepare your sites for the new Google ranking changes? Any other thoughts or comments?

Tell us in the comments and we’ll reply!

 

Comments 36 Responses

    • Hi, Joel! Thanks for the comment, my bad, somehow, my table was missing GeneratePress. I just updated it. Yes, GeneratePress is still a recommended theme. 🙂

  2. Thanks for this.

    Very helpful to know what’s around the corner, and gratifying to know that I’m already using the best plugin to help!

    When you refer to using fewer plugins, I assume you’re NOT including plugins that operate only on the backend. For example, I use WP Ultimate CSV Importer and Admin Columns PRO, Folders and more.

    Alex

    • Hi, Alex! Yes, by fewer plugins we were primarily talking about the front-end. However, you can never be too cautious because a badly written plugin that operates only on the backend still has a potential of slowing your whole site down. So maybe doing a quick check (of the front-end) doesn’t hurt.

  3. Hi Team,

    Many thanks. This is really helpful and I’m glad that I’m using Toolset for my site.

    Yes, the performance is improved a lot after using Toolset 1.5.

    But there seems to be still a room for improvement and could be done with popular plugins like WP Rocket, W3 Total Cache etc.

    In case if we want to use these plugins along with Toolset, what do we need to do.

    Do we need to consider anything before using optimized plugins.

    Please can you do a tutorial or documentation on what to consider before using it.

    Thanks.

    • Hi, Pramod! Toolset works great with plugins like WP Rocket and there should be no problems in using them together at all. I am working on updating our FAQ page about this because it has some outdated information . I will share it with you as soon as it’s ready.

  4. I’m also wondering about GeneratePress, as I actively asked the Toolset support, if the theme is recommended before buying it.

    • Hi, Harry! It was my mistake, I just updated the table with the row for GeneratePress. Of course, GP is still a recommended theme. 🙂

  5. A couple of features (or perhaps tutorials?) I would like to see added to Toolset that would help reduce the number of other plugins needed are an Events/Calendar feature (I know this has been raised in the past) and a Favourites feature (where users can select their favourite posts and access them via a view on a certain page, this would be particularly useful for Estate Agent / Airbnb type listing websites).

    I’ve seen various solutions to these in the support forums but they often rely on lots of custom code leading to potential conflicts with third party plugins, and there seem to be a number of different methods proposed so it’s not clear which is best approach. If there was a simpler approach to accomplishing these with Toolset that would definitely help cut down the number of plugins needed and help improve overall performance.

  6. What about older sites that are not using the Blocks plug-in? I maintain one based on views/layouts and had been told that “you can keep using Toolset Views legacy editor. We have no plans to deprecate the support of those features.” But will we be able to take advantage of performance improvements?

    • Hi, Bob! Yes, we did, we also optimized the way that Views and Layouts load their resources. It wasn’t as extensive as the work on Blocks because Blocks allow you to style things, add images, etc. right from the user interface so we had to take all that into account.

  7. Ah the old page load speed topic.

    While there is always good reasons to spur on fine tuning, I do wonder about the criteria that is used. I keep seeing sites that, for all intents and purposes, load nice and fast. Perceptually they’re loading is fine and then you check on GTMetrix (now using lighthouse against the new Web Core Vitals criteria) and then you see the awful scores.

    I build and test sites on a measly 3.8Mb connection and this does focus the mind. I see some sites from flashy places like California and they take ages to load on this connection. Thing is, I find that it is generally not the theme, but all the additions you need to make to make the site functional. One case in point is WooCommerce. It starts fine but then you realise that it really need the side cart plugin to make it appear more useable. Then you discover that by default WooCommerce doesn’t provide a field for a recipients phone number if the delivery is to somebody else, other than the billing address. So another plugin for that one thank you very much.

    Yes you can help with caching performance plugins and I find the Asset Cleanup plugin very useful to unload resources you don’t need site wide. But, all this take time and sometimes I look over at encapsulated platforms like WIx or Weebly and wonder are we kidding ourselves with all the man hours spent on our sites? To this end I wonder if it is time for WordPress to focus on tightening up the platform and a little less time on blocks? Who knows?

    The good thing is, there are plenty of vendors, like Toolset, who put in the time to make their software better.

    I might be wrong on this but I predict that there will be a fair amount of kickback against the new Core Web Vitals, not in any vocal way, but by dint of many sites not bothering to improve their speeds.

    By the way, a bit mean to give WPTavern that score. I just checked and their score is nice and green on GTMetrix.

    • Hi, Stephen! Thank you for the comment and insights. About WPTavern, I even stressed in the article that we’re fans of it and it’s just an example of a popular site that at the time I was writing it (a few weeks ago) actually had this score on PageInsights. It wasn’t to be mean or anything, just a comparison of popular two sites. 🙂

      • Hi Dario, I know you weren’t being mean, it just looked a bit funny to see WPTavern in the red!

        Which leads onto another observation. I do see a lot of variance with these different tests. And then the question needs to be asked. What constitutes a fast website?

        I have the the feeling that Google bases it’s notion of a website on their pared down documentation pages. There isn’t much going on there regarding visuals. And if we want to picky, if you try navigating their documentation, especially for novice users, it can be infuriating. So much then for UX on Google’s side of things.

        In the real world there are many kinds of website. For the arts and creativity, one does expect some visual flair and with this it is very hard to conform to the criteria set at a very high bar. Likewise, as I alluded to in my opening comment, some sites are just demanding in terms of resources and all we can do is to fine tune, much like I see Toolset continually updating and refining things.

        I note the comment below on the grid and maps. I have a view on a very large inventory items on a client’s site. I don’t take much heed in the fact that this page takes a little longer to load as It needs to display about 60 items in a specific manner. I will always go back to tweak things as I come across nuggets of wisdom on site performance.

        My message to others, build you site with your clients needs in mind, configure it to a point where if loads to reasonably fast. Use page speed tools only as a benchmark to tease out things you may have overlooked and fix them if you can, in a timely manner. Maybe keep the home page light to achieve a reasonable score.

        I do see a lot of sites that present as really sophisticated, work well but then fall down on speed scores. If I hadn’t checked the scores I think I would have been none the wiser and I think those that build these sites know this.

        • Very good observations there, Stephen. The performance fluctuates for the same site because of different things like server load. This is why Google’s PageInsights provides the current score and the score across the whole month. The performance across a time-period (i.e. a month) is what Google will use to determine how your site performs.

          In general, the content is and will remain the king, so that stays the most important ranking factor. Site speed is important for the good user experience, so I think overall, this “initiative” is a good one for the long-term. Unless you give people some real, impeding incentive, they will never improve the performance of their sites. Media-heavy sites will still be like that and they won’t fall off the face of the earth. But I think overall, this whole thing could improve things and actually get people – from software developers to website builders and owners – to stop just shoving features, plugins and media onto sites without thinking about performance and overall user experience.

  8. Hey Dario,

    Great article. Speed always a concern when using Toolset.

    We use a Toolset grid based layout with a map to the right.
    The map, while an issue is never as much a problem as the grid. No matter what we set the grid image size to, GT Matrix always pics up that these images are original & huge.

    We can’t upload a separate image for each grid as this is the feature image which we need large.

    As a result our grid pages always load slower than the rest of the site. No matter what we use, we’ve never been able to speed up our Toolset grid pages.

    Onward and upward, as they say. Pete

    • Hi, Pete! Actually, we’re already working on an improvement that should solve this exact problem. And this is planned to be released very soon in the next “point” release (presumably 1.5.1). How it will work is that Toolset image blocks will use the so-called media queries and the browser will automatically display the image with the size most appropriate to the device. Let’s say the original image is in big resolution and its size is thus quite big. On desktop, this big size will load, however, on mobile phones, much smaller size will load and make the image loading much faster.

      P.S. You probably know this, but it makes a lot of difference to optimize all your images before uploading them. There are free services like TinyPNG that can easily make images 1/3 of their original size without any visible quality loss.

      • Hey Dario,

        Thank you for your response, hope you are well.

        That news is great to hear, every little helps as far as performance is concerned.
        You mention Blocks, will with apply to Views also?

        We created our sites using some very specific HTML before Blocks was introduced, nothing hugely fancy however even support said in the past to accomplish the layouts we have using Blocks would not be possible.

        That’s not an issue, we like Views and the total control it gives us. So hoping these improvements may be something we can use also.

        Yes, we optimise all images before upload and further in the site with the addition of lazy load too 🙂

        Thanks again.

        • Hi, I vote for Pete request! For me it’s very important that all the improvements are available also in classic Views. There are still many development where it is impossible to work only with Blocks interface. Views gives the full control I need to develop complicated architectures and interactions.

          About images optimization, something that would be great is an option to optimize the image BEFORE the image upload with Toolset Forms.

          I’ve recently developped a website where users can upload images by their mobile telephone camara. I’ve installed a plugin to compress images after upload, so I can save a lot of server space, but the user experience is still quite bad because the image apload takes very long (because of the image size and because of the mobile connection).

          I haven’t find any plugin to compress images before the upload. I found some JS custom code, but I still haven’t implemented it.

          Thank you to all Toolset team for your smart job!

          Umberto

          • Hi, Umberto! Thank you for the comment. There are no plans or even feature requests from clients about such image optimization in Toolset Forms. If you want, you can create a ticket in our support and submit a formal feature request. Our Support Team then raises this to developers and if there is enough interest from the clients, it is considered for implementation.

        • Hey Pete! No, this improvement will not be inside legacy Views because it’s simply not the same code as the one in the Toolset image blocks.

  9. Hello Dario,

    I am glad that the developers devote some attention to performance now.
    Well, 1.5 seems to be significantly faster than 1.4 in the back end, so congratulations.

    It wasn’t very difficult to reach 100/100 in Google PageSpeed and very fast load times with Toolset, at least on some pages. But it requires some work and dequeuing unnecessary scripts. It takes some time to figure out what is necessary and what is not.

    Toolset filters depend on jQuery and mediaelement.js. Dequeuing these scripts breaks Toolset filters and these scripts are relatively heavy.

    Any chance that Toolset will get rid of these dependencies in the future?

    I haven’t checked if jQuery and Mediaelement are still required in 1.5, but I expect that this hasn’t changed yet.

    From what I have read, a popular plugin providing Ajax filtering dropped jQuery recently.

    Greetings,
    Tom

    • Hi, Thomas! About dequeuing scripts… That shouldn’t be done for library scripts like jQuery or mediaelement as many plugins use these. So if you really want to dequeue it, you should do it on a per-page basis and doublecheck that everything is still working. It can be done but we wouldn’t recommend it unless you’re really an advanced developer.

      Anyway as we are gradually rewriting the View Block, we will be able to have more accurate script loading on the front-end, to have it only when it’s really needed. I have no ETA on this and it will probably happen in gradual steps.

      • Hello Dario,

        I have been dequeuing them for years, with WordPress conditionals. No issues. I just try to avoid plugins requiring jQuery, if possible.

        But it cannot be done for URLs with Toolset filters… It would be great if we could get rid of these dependencies completely…

        Greetings,
        Tom

  10. Dario,

    Where are things at with getting an official integration with GenerateBlocks? It seems to have been brought up numerous times, but still nothing official. This is an integration that I want as soon as possible!

    • Hi, Brent! GenerateBlocks recently released an alpha version of their “dynamic content” feature. We reached out to the GenerateBlocks developers about integration with Toolset but it didn’t work out. So, unfortunately, as things are looking right now, this integration will not happen.

  11. Can you elaborate a bit more on the “it did not work out” part? Is there a technical reason why it didn’t work out? Or an unwillingness on one side or the other to make it happen? Or a lack of communication?

    • Hi, Brent! We have nice and friendly communication with the authors of GenerateBlocks, there is no problem with that at all. But, as I’ve said, GenerateBlocks are working on their own version of Dynamic Sources in their blocks. So, naturally, they won’t be too interested in promoting our own Toolset solution for the same thing (even though ours is superior hehe). So, as you can see, it’s simply a situation where our agendas simply don’t align. Does this answer your question?

  12. This is one of the reasons why I think OTGS/Toolset should be building a complete theme, block and dynamic solution. Why rely on other theme and block builders to give you access? Maybe I’m underestimating the complexity of GeneratePress, but I’d imagine Toolset is far more complex and that building a clean lightweight theme that can outperform GP would definitely be within OTGS’s capabilities. Create a theme purely focused on speed, Gutenberg compatibility, and flexibility(when it comes to assigning layouts such as footers/headers/etc to various pages conditionally). Combine that with basic versions of your blocks with little or no dynamic functions and offer it for free or cheap. Then up-sell the users to your full dynamic blocks.

    GenerateBlocks isn’t the first to add dynamic data to their blocks and they won’t be the last. Eventually they’ll get sophisticated enough that they’ll meet the dynamic needs of most people and Toolset could be left out in the cold. Why not build a full solution and control your own destiny? Anyway, this isn’t why I came here… lol …

    In grids, sliders etc, I like to use images as background images instead of using the image block so that I can easily overlay those images with text etc. I’m pretty sure this causes wordpress to use the largest/default image. Is there some way to control the size of images when used as background images? Above you mentioned that the image block in 1.5.1 will load images more efficiently, what about background images?

    Thanks!

    • Hi, Peter! Thank you for your thoughts. The thing is that we cannot do everything ourselves and Toolset cannot have every feature users or ourselves come up with. This is why we focus on what we’re good at and let those who specialize in other things, like themes, do what they’re good at. Building a good theme takes time, a dedicated developer, and you need to maintain and keep developing it. At this point, there is no plan to go down that path.

      On the other hand, integrating Toolset’s Dynamic Sources into an existing theme is really easy and we provide full support to any theme author that wants to do this.

      Finally, about the background images… I checked with the development team and we have this as a feature request but at this point, I cannot guarantee it will make it in the next Blocks 1.5.2 release.