Web Page Performance

I was wondering what you guys do to improve the performance of web pages created with blocs since according to lighthouse it is difficult for google to render all the JS / CSS created by blocs (eleven) I still don’t understand why there are so many.

I usually try to combine them as much as I can into a single file but it is a tedious process if you need to re-edit the website. @Norm is there a way for blocs not to export as many JS / CSS?

I’m no expert on this subject, as regular readers will attest, but I followed GTmetrix’s simple advice and greatly improved my website’s speed…

Which equates to:

This is my score on GTmetrix

But blocs export a crazy amount of css/js

Look how many js and css files

Wow, looks good to me!*

I have learned that some things are not worth worrying about if a) your speed is good and b) your SEO is good.

For example, the number of ‘requests‘ in my case… it’s because I have a lot of (well optimised) photos on my home page. So I live with it.

Anyway, hopefully some better-informed people will chip in!

*Strictly amateur opinion

if you are not using font awesome, ion icons or line icons you do not need those files

your page load time I really high while page size is less than 1 mb

but I have to agree with you blocsapp does not focus on clean code output or performance

hopefully they will in next updates

1 Like

I think you will find that unused fonts will not affect page load times. Fonts are generally only loaded if there are specific references to the fonts in the CSS of your website. In other words, they load when they are called. If you haven’t called any of the fonts through the CSS, they won’t be loaded. If you are concerned about this, simply delete the unused fonts from the fonts folder after publishing.

Im always trying to follow all the advices by google to improve the performance of my sites but honestly there is way to much manually stuff to do. For exmaple I don’t understand why blocs export all the bootstrap library when you are not using the whole thing. There is a problem also on the font file that google ask for correction and so on. I was trying to implement a few days ago google’s new vitals in one of my sites and I think by next year this will be a huge topic on the forum if blocs 4 doesn’t correct it! I mean if you only need a site to have something online where people can go from time to time then is fine but if you are relying on google to rank you site then you will have a, serious problem. The average performance of a page build by blocs without any manual work is between 80 to 86% or so… Thats not good.

@Stewie_Griffin I think most of us who were feed up with bloated wordpress sites sendup using blocsapp in hope it will produce high performance websites. but we end up getting the same bloated poor quality code with no option to use a plugin to automate the manual work.

I think some people go into meltdown when it comes to testing for page speed, and more often than not, much of it is pure hype to get people to sign-up for website monitoring services. I took a few of the speed test websites and was hard pushed to find one that ranked higher than 76%!! so why were they at the top of Google listings? because they paid to be there.

Although it is generally accepted that bootstrap does cause initial bloat when visiting a site for the first time, it isn’t the major issue that many make it out to be. If it is of real concern, there is nothing to stop you from serving bootstrap from a CDN. Of course, you always run the risk that the CDN may be down when someone visits, so you would probably need a fall back to your own hosted version of bootstrap anyway. You can do the same with javascript libraries, but with the same caveats. This only works because there are millions of websites out there that use the bootstrap framework, so the chances are that many users may already have a cached version of the bootstrap framework if they happen to have visited a site that uses the same CDN. Likewise, anyone who has visited your site will also have a cached version of your bootstrap framework, so repeat visits will be much faster. The same applies to fonts. You could have those delivered via a CDN on the off-chance that another site the user has visited has used the same fonts as the ones in your website.

The other thing you can do is to consolidate those CSS files into a single file and then minify the consolidated file. This is a simple copy and paste function and only requires a simple change to one line in your output HTML file. You could also enable GZIP on your hosting so that everything gets compressed on your server.

By far, the biggest savings are made by correctly optimising your content, particularly images. As things stand with Blocs, it already minimises your HTML, CSS, Javascript and Bootstrap files, so it’s already doing as much as possible to create faster loading sites. Anything beyond that is down to you, as the website developer. As almost every academic will tell you, the only real way of fully optimising your site is to hand code it. Of course, that suits their narrative because they make their living by teaching people how to hand code. Google, as you would expect, do their bit to support the narrative by convincing everyone that they are going to downgrade your ranking if you don’t achieve a certain mythical score. The fact is there are millions of bootstrap websites out there that actually do appear in Google’s listing, so there is clearly other factors involved in the ranking algorithm.

Certainly, Google doesn’t seem to worry about page speed when it comes to websites that are serving up google ads and using google tracking tools. The BBC News website ranks at about 68% (81% for a repeat visit), but it delivers a lot of content for Google. So, expect the BBC and similar site to get very high rankings from Google.

For me, the benchmark of performance is page size. If it’s less than the median of 2.11 mb it will do just fine. Interestingly, even a page size within that median can load in anywhere from 1.2 seconds to 7.8 seconds, depending where the test server is located. So, much of this speed testing is very much driven by the gullible. Seeking utopia on the Google scale isn’t the be-all and end-all of website design and development. People visit websites for all manner of reasons and as long as they see something within a few second, they are normally happy. I don’t know of too many people who sit there counting the milliseconds in order to decide if they are going to stick around to see what the site has to offer. If that was the case, I’m sure Amazon wouldn’t get the number of visits it gets. (their score, by the way, is between 51% and 73% with an average load time of 7.37 seconds.


This will change by next year. Most of the SEO gurus are warning the web developers already about this. It won’t be the main factor for ranking but it will play a good part on the game.
Also paid ads to list in google on fist place its a waste of time and money. The only people who clics on them are your competitor’s bots.

Hm, how can I improve my website in terms of performance? I ran a gtmetrix test on a site I’m about to publish and get theses results:

I’m not familiar with the steps I’d need to take to improve the performance. Any tips?

@pumpkin It opened almost instantly for me. It looked like less than a second.

Yes, same here. I’m still wondering about the C Grade performance according to gtmetrix and what I can to do solve the issues that gtmetrix found.

I do these kind of analysis on a daily basis, so I reckon I have some experience on this matter. My preferred tool is GTMetrix, as this combines Google Pagespeed and Yahoo Yslow into one very useful report.

Before running a test on GTMetrix.com, create yourself a free account and log in. This allows you to set your test location to a location that geographically close to your target audience. Running a test on a site hosting in Belgium from Vancouver, Canada makes no sense, as the distance will introduce extra delays and thus result in a report that is not realistic.

When running the analysis, there’s a number of key metrics to take into account:

From this chart I’ll take the First Contentful Paint and the Fully Loaded Time into account.

Schermafbeelding 2021-04-06 om 12.24.25
From this list I’ll take the Total Page Size and Total Page Requests into account.

This gives us following metrics:

  • Total loading time (Fully Loaded Time): 1.9 seconds
  • Total page size: 642 kb
  • Total number of requests: 39

As you can see, this page is already fairly well optimized. So not much action is needed here. However, in most cases, these metrics will tell you exactly how to optimize:

A high Total Page Size (for example 6 MB) will tell you to take a closer look at your assets, such as images, video’s, …
Ideally you’d want to keep your total page size under 1 MB or lower. The lower the amount of data that needs to be transferred, the better the performance.

You can also increase the performance of the data transfer by tweaking some thing server side:

  • Enable HTTP/2
  • Enable GZIP
  • Set Expire Headers and Cache Control headers (to avoid common elements suchs as the logo, certain css or js files need to be downloaded upon each page request/visit)

When it comes to images, I’d advise following best practices:

  • Large images (full width, fullscreen) should be a maximum of 100 kb
  • Smaller images should not be larger than 30 kb

A High number of Page Requests probably indicates an overuse of Javascript/CSS/Images. In this case I’d look at animations (in case of a lot of JS) and see where I can reduce. Same goes with CSS and Images.
Reduce to the bare minimum. Always ask yourself the question: Do I really need this eye candy?

And for those of you that might argue that 2 or more megabytes isn’t much for a single webpage, please take this into account:

Hope this very basic set of thing I take into account helps you guys :wink:


Right, creating an account and setting the server to London already provided a totally different result:

Done it again with the same settings and got me a score of D. Why’s that? And then B, and now A again. I take it it’s due to the overall web usage and stuff, but such a range…

Any tips on how I can change the cache policy for files when visiting the webpage? That’s one thing, that’s alway on top.

Make sure you have disabled cache bust for JS and CSS in the Blocs export settings on final published sites. You could also add cache expires headers in the htaccess file something like this:

<IfModule mod_expires.c>
  ExpiresActive On

  # Images
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/gif "access plus 1 year"
  ExpiresByType image/png "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/svg+xml "access plus 1 year"
  ExpiresByType image/x-icon "access plus 1 year"

  # Video
  ExpiresByType video/mp4 "access plus 1 year"
  ExpiresByType video/mpeg "access plus 1 year"

  # CSS, JavaScript
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType text/javascript "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"

  # Others
  ExpiresByType application/pdf "access plus 1 month"
  ExpiresByType application/x-shockwave-flash "access plus 1 month"

I also suspect lazy load is working better since updated in the beta of 4.2 so that might be worth trying again now. I had that disabled for a year on websites.

If you are using a LiteSpeed server I also have some separate cache code for that.

Check the waterfall chart of each of these tests. I suspect that the initial request will vary greatly in length, which in itself could indicate variable load on the server. If this is a shared server this might be a case of “noisy neighbours” (= impact on your performance due to other sites on the same server)

This is mine:

That’s impressive!

1 Like

Lucky you!
I’m getting 63/70 on Google page insights , and an E from GTMetrics.
But I neither understand why, what to do nor how to improve an image heavy site.
In my mind, if it works and a client waits 3 instead of 2 seconds to get started, then it’ll have to do!
The mobile accessibility of my site is a huge value.
The rambling thoughts of a furniture maker!