Website is very slow in spite of grav core feature (crazy fast..)

Hi there,

we have been trying pretty much everything however (including setting up cloudflare) according to google speed test website is still very slow both mobile/desktop, what really is plainly disappointing is that is even slower than previous joomla version.

joomla speed test output 85% 83%
with grav we are down to 51% 41%

Theme is the same and we even improved structure, framework and code.

Can you please suggest a way to achieve the "crazy fast" grav feature?

Hey there. Are you willing to share your URL so folks can take a closer look? If not that's ok, but it does help. I'm active on the Cloudflare community as well and this is usually the first request for most 'my site is slow' topics.

In my experience, google page speed score is the hardest to achieve high numbers on. Have you tried other performance tests like GTmetrix or Pingdom to see how you rate with them?

For reference, even my own personal blog - which I've designed around <1s page loads - cannot break into the 80s for google scores, however I am in the high 90s for GTmetrix and Pingdom (and yes I am also using Cloudflare).

Without seeing your site or a waterfall of assets loading it's hard to determine exactly why your site would be slower on Grav than previous Joomla.

Hi Andy,

no pb, Ive shared my url on previous topic, check here

I understand what you are saying, developer mentioned pretty much the same things, but also possibly main reason that prompted me to give grav a shot is loading speed so if that cant be fully accomplished is kind of disappointing, also considering the time and effort we put into converting this site.

Here is what is puzzling me, why with same theme, same content, pretty much same everything site was much faster with joomla that as opposed to grav uses a db and has some zillion files more running on server?

Those were the stats.

Here is an excerpt of discussion with developer,

"Ive heard of that tool (gtmetrix), but google speed test is pretty much the standard since google is eventually calling the shots and inflicting penalties to slow pages.

I just know these facts. We had around 85% on both desktop and mobile before with joomla! running same test.
Now its all down to 53%/41%

I believe that there's plenty of room for improvement. I'm not sure how much server is affecting though joomla version was running on same server with same config though"

Hello,

I'm not really competent in this question, but you have some really heavy pictures:
http://www.designdiverso.com/user/pages/04.thoughts/the-new-era-of-entertainment/v_20170427-161041_1.jpg almost 1Mo for exemple.

Hey again. Thanks for the link, I will do some investigating.

@tancredi:
main reason that prompted me to give grav a shot is loading speed so if that cant be fully accomplished is kind of disappointing, also considering the time and effort we put into converting this site.

Yes, I urge you not to give up just yet, but it does seem a bit odd. Is your Joomla site still accessible for comparison purposes or have you fully 'switched over' to Grav at this point?

@tancredi:
google speed test is pretty much the standard since google is eventually calling the shots and inflicting penalties to slow pages.

Yes this is true. It is somewhat unfortunate because Google seems very harsh in particular areas (like images) and I wonder if their standards have some folks chasing after unattainable scores. Like I mentioned, my own site cannot even achieve 80s on google, and the homepage is only 1.5MB with just 19 HTTP requests (and only 2 of those are to external origins).

I'll do a little poking around and see what I can come up with, but you may need to wait to hear from someone from Team Grav about specific causes of this.

@AmauryH:
you have some really heavy pictures

I noticed this as well. Is it possible these images were being optimized at all with Joomla? I don't have any experience with Joomla but I assume they offer some kind of image optimization (via plugin maybe) like on Wordpress.

During a quick scan of the waterfall I notice there is a redirect chain for an asset that's returning a 500 internal server error status code (https://mautic.designdiverso.com/form/generate.js?id=1 is pointing to https://mautic.designdiverso.com/installer). Google isn't reporting this error specifically but it appears to be taking approximately 1s to resolve this redirect chain as an error and proceed with page loading (script seems to be render-blocking). Is this asset a remnant of your Joomla installation or something else?

Additionally, your assets do not have expiration date for browser caching. Joomla may have been adding these headers for you, I'm not sure. You can set expires headers in the Grav dashboard Configuration > System > HTTP Headers section. I'm not sure if there's a default value but you must indicate in seconds (e.g. 604800 for 7 days).

If you address these two things you may appreciate an increase in your scores, but I can't guarantee that.

@andy:
I noticed this as well. Is it possible these images were being optimized at all with Joomla?

If they were uploaded via the admin panel, I think so.
As in Grav, I believe that you can choose the compression rate. 🙂

thank you for the feedback and suggestions, must be noted that if you are referring to blog images in joomla I had something called easyblog an extension that sold for a lot more than it actually does.. believe me I had nightmarish days figuring out why it never worked properly most features were broken 4 out 5 days a week, reason is it just does not work.

I'm not sure whether that extension had any kind of gimmick for making images "leaner" however bear in mind all the content, images etc.. were exactly the same. No were not loaded via joomla media UI.

Joomla version is down now, fully replaced by grav's, developer mentioned that framework is been actually upgraded from bootstrap to bulma.
Apparently its more flexible concerning some specs.
Code was also improved if you require more details I need to ask developer as Im not sure exactly where and how he made the improvements.

Can you provide even more insights on how to improve this very poor performance? my goal is to achieve as close as possible to 100% google speed. I know 100% its a lot, but grav claims crazy fast and thats what we want.

Is there for instance a plug in for image optimization? Anything else that could help?

@andy thought you were part of grav team.

@tancredi:
Is there for instance a plug in for image optimization? Anything else that could help?

How do you call your images ? In markdown, in twig ?

• For exemple, in markdown, when you call a picture:
  ![Sample Image](sample-image.jpg?cropZoom=300,200)
  You can add &quality=XX, like this:
  ![Sample Image](sample-image.jpg?cropZoom=300,200&quality=60)

• In twig, you can do it this way:
  {{ page.media[article.image|first.name].cropZoom(300, 200).quality(60).html('', article.text, 'img') }}

This way, without plugin, you can adjust the compression rate.

Thank you @AmauryH Ive passed the info to the person in charge of development. Keep it coming!

FYI for me as publisher blog is another reason why we decided to opt for grav, its unacceptable to have a feature rich blog that barely works 90% of the time, blog must work smoothly inside out, also Ive asked for plug in solution as I havent been into coding now for a long time and currently am acting as BDR/marketing manager.

For me it lands at 3.6 MB in 3.55s. Couple of quick things that make a difference also: HTTP protocol and PHP version. Your site runs PHP 5.6.31, go 7.0 or 7.1, and serve content over HTTP/2 rather than 1.1 - it will alleviate a lot of the time needed to handle all the requests (which came in at 41 total). 100 % on Google is difficult, but not insurmountable, though arguably a worthless goal since anything above 90 tends to be worthless optimization.

I hit 100 % on PageSpeed and 94 % on YSlow (here), some details on how here.

@OleVik:
100 % on Google is difficult, but not insurmountable, though arguably a worthless goal since anything above 90 tends to be worthless optimization.

I agree with this. Here's a base Grav installation with Antimatter theme and CSS and JS pipelines enabled, which scores 71 mobile/89 desktop using google page speed test (here are GTmetrix results). If you're looking for some kind of benchmark or baseline scores to achieve (sans images) this is probably it.

@tancredi:
thought you were part of grav team.

Nope, that Andy is @rhuk

@AmauryH k dev is saying

"?cropZoom=300,200&quality=60

I've also tried, this leads to blurry images on the HiDPI displays."

Any other solution to this very welcome and appreciated

@tancredi:
this leads to blurry images on the HiDPI displays

This was just an exemple, the cropzoom is to resize the picture, so you should not use it if the final image shouldn't be this size. Use just the quality. Sorry, I should have keep it simple.

Hi there!

First of all, thanks! It's great that we can try to improve Grav basing on your real-life case study and benchmark 🙂

On first look, it seems to me that images really are huge on your website. It is possible that previous solution (Joomla) was using some optimizing mechanism. You (and your dev) should definitely take a look at built-in image optimisation tools in Grav core, as well as the big variety of responsive images plugins. There is no point in loading 2kpx wide image on a cellphone, right?

Another thing, the same 2000px, 1Mb picture pointed out by @AmauryH is used on the front page as a background for a cell that renders on my laptop as ~300 px wide. And there are 3 of them!
The same scenario occurs on 'work' page, why ar you loading 800px wide picture into 400px wide cell?

I'm afraid that big part of the problem may be the fact, that unfortunately, theme is not really responsive nor optimized, it would load quite long even if it was pure HTML with no php backend at all. Seriously, who puts style="background-image" in half of sections on a website in 2017? What is this iframe doing there? Why putting external javascript on top of the page? Why do you even need this components for modal & carousel, there are solutions reusing code that you are already using and have loaded!!

Oh, by the way. Loading code? Turn on assets compression and pipelining. If your clients browser will load ONE compressed js file, it'll take lots and lost less time and resources than loading ten of them. That's why this option is built into core.

Of course, updating PHP and HTTP version will probably speed things up a bit, but I'm sorry to say, that the website loads slowly, because it's poorly deployed. Grav won't make your project super-fast, if templates are not written to be super-fast.

Cheers, Makary

Disclaimer:
I'm not a member of Grav team, nor anyhow connected with them.

@MakaryGo

Hi there, first of all thanks for your feedback, I will pass this on to the developer in charge. So it seems that all has to be blamed on our theme in the end.

FYI last year we have been nominated twice for best UX and design with this theme.
Joomla version was running twice as fast and you are claiming that basically is a image size issue, I wonder how it that possible with the exactly same theme, content and settings?

I will get back to you with a possibly more detailed reply later on.

Hi! :) I didn't mean that ALL is to be blamed on your theme! I also can't
say that it isn't great design and clean UX, because it is, I like it very
much :)
The point is, that the design is one thing, and the code under the hood is
something completely different. So, a design (theme) that looks exactly the
same and acts exactly the same, does not have to be technically built by
the same code and the same techniques.

You don't have to take my word on it, just do some loading speed check
yourself and see what is taking most of the time. According to my tools, it
is:
a) loading many different assets, some of them rather large - because you
have some plugin enabled, Grav 'attaches' to the end HTML code six
different stylesheets, if I remember well, same thing with JS files. So,
each of them is taking one request and one response. Because of this
modular behaviour, Grav has built into the core function called 'assets
pipelining', it just needs to be enabled. When you do so, system will
collect all the CSS files, and attach them to the code as one entity, which
will take only one HTTP request and response. Same with JS. There is a tool
for it, you just have to enable it ;)
b) rather 'relaxed' use of graphics. I did some tests, and none of the
three pictures used on the front page is rendered in full size that is
loaded there, even on my 4K screen. And there are another 3 requests, and 3
responses, and the files are just big (almost 1 megabyte). Same goes with
loading non-responsive pictures to responsive layout - there is no need to
send 1900 pixel wide picture to a smartphone that has a screen 600 px wide.
And files that big have their weight, so it slows down the process
unnecessarily.
c) not using server-side GZIP compression, which can lower the size of
files sent from server to browser even in half.

I'd like to repeat one more time – just because previous website did ACT in
the same way that the present, does not mean that it was the same code, and
thus can act differently. I can't tell you this without looking at the
previous one.

If you'll need some help in terms of enabling any of the features mentioned
above, I'll be really happy to help :)

Cheers!

P.S.
Please, mind that my primary background is frontend development, that's why I'm advising in the area of HTML to reduce loading times.

@MakaryGo

Hi and thank you for the prompt follow up, I can already say as a premise even though I lack an extremely technical take on some of the issues:

1) All the compression concerns can be possibly addressed to the fact that we are only waiting to find a solution to another critical issue we have that is implementing forms via mautic, as you probably are aware of mautic should work seamlessly with grav we are using its plug in, however some issues have occurred and dev is trying to sort them out before completing all the optimization and compression steps.

2) what are you referring to exactly with "theme being not responsive"?

3) In order for me to also get to the bottom of this, is it safe to say that when we resolve the compression related issues we will witness a consistent speed improvement? What else can be done?

4)

Blockquote The point is, that the design is one thing, and the code under the hood is
something completely different. So, a design (theme) that looks exactly the
same and acts exactly the same, does not have to be technically built by
the same code and the same techniques.

As I mentioned in above replies dev should have actually improved code overall since previous joomla version, so I dont really understand what can be the issue but Im sure very interested in learning more if you have specific concerns with framework, code and these kind of elements.

Let's start at the end of it.

@tancredi:
In order for me to also get to the bottom of this, is it safe to say that when we resolve the compression related issues we will witness a consistent speed improvement? What else can be done?

Compression is one thing, pipelining is other. Let me quote myself 🙂

@MakaryGo:
loading many different assets, some of them rather large - because you

have some plugin enabled, Grav ‘attaches’ to the end HTML code six

different stylesheets, if I remember well, same thing with JS files. So,

each of them is taking one request and one response. Because of this

modular behaviour, Grav has built into the core function called ‘assets

pipelining’, it just needs to be enabled. When you do so, system will

collect all the CSS files, and attach them to the code as one entity, which

will take only one HTTP request and response. Same with JS. There is a tool

for it, you just have to enable it

This step should give some loading speed boost. In my case, on some mock Grav instance I have, without real content and graphics, change was:

Note, I am using custom JS as well (Masonry) and I didn't change any caching or compression options, only pipelining.

@tancredi:
as you probably are aware of mautic should work seamlessly with grav we are using its plug in,

I'm afraid I can't help with Mautic integration, I don't use it. If you have any problems with plugin, probably best way to proceed would be to contact said plugin's author. Also, please mind that this plugin (if I'm looking at the right GitHub repo) wasn't updated in a year, so it may not work perfect with latest Grav version.

@tancredi:
what are you referring to exactly with “theme being not responsive”?

I meant rather that it's not fully responsible. As you well know, I'm sure, Responsive Web Design (RWD) means that we're serving to a client version of website that will look best/good enough on a device that client is using. It means of course serving a website that is narrower and has more compact navigation, but not only.
Mobile devices (aka 'handhelds') not only have smaller screen than desktop or laptop computer. They also use different web connection, different hardware (CPU, GPU, RAM) and software. So, for website to be truly responsible, it has to display not only different size, but different assets as well. As I wrote before:

@MakaryGo:
there is no need to send 1900 pixel wide picture to a smartphone that has a screen 600 px wide.
And files that big have their weight, so it slows down the process unnecessarily.

Ad. 4, as I said before, I haven't seen the previous version of this website, so I cannot tell if it is better or worse now. I can only tell you, based on my experience in frontend, that the present theme uses some techniques that are not optimized for speed. I.e.:
On the main page you're loading 3 pictures as a cell background, here:
<img src="//cdck-file-uploads-canada1.s3.dualstack.ca-central-1.amazonaws.com/flex036/uploads/getgrav/original/1X/b04265a0eff19aab0cbb38baa948541f958dc780.jpg" width="690" height="150">
First one on the left, despite the size it's displayed in, is loaded by the browser like this:
<img src="//cdck-file-uploads-canada1.s3.dualstack.ca-central-1.amazonaws.com/flex036/uploads/getgrav/original/1X/7a8d237631b5fcb9c14ec0b924d31733788ad335.jpg" width="690" height="331">
It is almost 2000 px wide and weights almos one megabyte. If you would use cropped, and/or optimized version of it, I bet it wouldn't weight more than ~140 kb.
It means, that this single pic would load five times faster.
Am I clear enough now? 🙂

Ok so here is the reply from developer,

Blockquote Most recommendations of Grav's guys have been enabled already (like JS pipeline), some of them -- Grav related issues, some plugins just appending blocking JS.

However speed is down to a 35% on mobile which is very poor, I really am not sure whats wrong, can you guys please have another look perhaps provide some feedback and additional suggestions eventually we really need to solve this issue ASAP. Truly appreciated.