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

Good morning!
I’m very happy that you’re still trying to learn new things, @tancredi :slight_smile:
Let me clarify some of the questions you’ve asked!

Requests:
A website is a collection of documents. It contains text documents (HTML documents, CSS stylesheets, JS scripts), media files (PNG or JPEG images, PDF attachments, MP4 or OGG video files), and so on. Each and every one of them has to be loaded from server to the visitor’s browser. Every act of requesting an asset like this, is called HTTP Request. So, when you use CSS pipelining, you are reducing number of requests at least twice! Yay! (And same goes for JS!)

Images:

  • When you load image in Markdown via ![](sonokogroup.png) syntax, you are loading this image in its full size.
  • When you load image via ![](jou-pet.png?resize=140,109&quality=75) you are performing two (well, actually three) media actions on this image:
    1. First, you are resizing the image. As described in documentation, this makes Grav create automagically new image file by resizing your image to given dimensions - in this case 140px per 109px, and load this resized version into the website.
    2. Next, you are telling Grav to display this image with quality of 85. This shouldn’t make a picture very blurry, you can see visual comparison of compression levels i. e. on excellent Coding Horror blog here or on Wikipedia. Please, note that quality is the opposite of compression level: this means that quality 85 equals to compression lvl 15, so it should be noticeable only on 4k or Retina screen, and in the same time it reduces image size even as much as twenty times, depending on image contents.

But, as @AmauryH mentioned, if you wish to generate different images for retina and non retina displays (and possibly other), that’s not the thing you’re looking for. But, fortunately, Grav has required option built-in! It is another media action, known as .sizes(). To use it, in place where you wish to insert the image, add this image in highest resolution available, name it i. e. sonokogroup@3x.png (depending on size) and use syntax ![](sonokogroup.png?sizes=100vw) (Markdown). This will tell Grav to do the following:

  • generate smaller versions of the image
  • display one of them, depending on screen size of visitor’s computer.
Wider description of how it works

It uses HTML srcset attribute, which takes multiple image URI’s and displays to the user one that is fitting they screen best! Because it is rather new feature, it also adds fallback src for older browsers. Pretty cool, don’t you think?

2 Likes

Regarding linode and databases…

A VPS at linode is a bare Linux machine. You have root access to it and can install any software you wish including MySQL or mariadb. You can also create as many DBs as you wish.

Obviously this means you need to know a little bit about what you are doing but combined with serverpilot.io (which installs a powerful web stack ) you can get running quickly and securely with little to no knowledge.

Read my blog post an AWS aces and sever pilot.io.

@rhuk

ok, thank you, you mean it comes without a cpanel? I see this is getting increasingly complex, I figure it would have been easier to set up, but it looks like it requires some degree of dark forces, so I will wait for the dev to come back I dont wish to cause damage or waste time anymore than we already did.

if you meant this post Ive already read it and commented below.

It doesn’t come with a control panel ala CPanel. Serverpilot lets you do the basics like create vhosts, enable SSL, pick PHP version etc. The rest you would need to do directly on the server or via web-based tools like PhpMyAdmin to create databases for example. It’s definitely more of a developer thing than an end user.

1 Like

@rhuk

thats what I thought, unfortunately I dont always have dev with me and I still need to make decisions and move forward, so I was wondering is there a more friendly solution for lesser engineering savvy people?

Something with a Cpanel easy to use that I can just fire up and launch on my own (but still as reliable perhaps)?

@MakaryGo
thank you appreciate it, I never get tired of learning, nowadays I’m pretty much taking care of marketing and sales though.
I’ve some background in programming, but it is not my core skill really.
When I turned to grav cms I thought it reminded me of stuff such as jekyll Ive built myself and older version of the same site with it and also perhaps pulse, which seemed really easy from a designer standpoint.
However both lacked at least at that time features. Pretty much grav cms seems more complete features wise, mainly I was hoping it would be really fast out of the box and also extremely easy to set up and use.
I’m still hoping for the speed, ease of use is ok I guess, for setting up I really hope that there could be something like with a cpanel for me it saves a lot of time and I dont have to get dev to do that so he can focus on something else instead.

I am pretty sure, that your dev is a skilled professional, but did he made some projects on this very system before?
Perhaps it would ease things if we just could talk to him?
Just leaving under consideration.

@MakaryGo right now he is on holiday, I already mentioned the forum and thread, its up to him whether he wants to sign up or not.
Grav cms is relatively new for instance he was surprised that commenting plug in is still in beta phase after two years of production.
He’s very busy with his research and I can’t force him to keep up with the forum but I can assure you everything he has to say I will refer to you guys.
I"m doing the same filling him in with every relevant remark you have come up with. Talking to me is like talking to him.
What was your question exactly?

I was wondering if your dev did some Grav-based projects before.
As Grav uses some different approach to some things than ‘traditional’ systems, like Joomla or Drupal, it would help if he/she had some experience in Grav-specific technologies like Twig, YAML or Markdown, that’s all.

@MakaryGo yes I believe he did.

1 Like

@rhuk Ive checked the loading speed of https://getgrav.org/ its really poor, I’m not sure whether you should pleased with performance though.

@rhuk @AmauryH @MakaryGo @andy @OleVik @flavio

ok, now I really really am disappointed with performance on our site, since last time has gone way worse not sure how… devs have gone on vacation and left me deal with this, as per usual really hard to find some honest, reliable individual these days.

Can you please kindly explain to me what shall I do exactly to improve performance beside the obvious server/hosting issue?

Eventually could you be so kind and explain in a way that even a mortal like me (not a developer) can fix these issues?

Uncached GetGrav.org loads in 1.7s for me, which is not bad at all given how many resources are on the page. Looking at the PageSpeed results, there is clearly room for improvement. Your site currently loads in 4.15s for me, which is not horrible but far from ideal.

  • Images can be compressed without loss, which you’d usually do programmatically but there are free services available that do this, like https://compressor.io/.
  • Assets can be pipelined and minified by Grav, see: https://learn.getgrav.org/basics/grav-configuration#assets. Further, your developers/designers should both clean up the CSS prior to compilation and consider a tool like unCSS.
  • Your developers should set up expiration headers for the site, this is done on a server-level, see: https://varvy.com/pagespeed/leverage-browser-caching.html
  • Assets need optimizing in load-order: FontAwesome, OwlCarousel, and main.css should load deferred. This is particularly important for the first two. Have your developers look into loadCSS.
  • The server, ie. host, adds 0.27s to the load time. This is a lot and you should contact the host to find out why it is so slow.

All that said, aggressive optimization of a site really requires technical know-how. You can do a lot, but optimal results (eg. 100% on PageSpeed) requires optimization across the board. The two first points you can accomplish yourself with simply replacing images on the site and changing a few settings in Grav, the rest requires development work.

It seems very likely by the length of this thread that your developer is not as experienced with Grav development as he may of led you to believe. Determining the cause of a slow site is not easy without carefully evaluating everything that’s going on and debugging it. This take quite a bit of time and effort and is not something that is easy to do via a forum.

If you would like some experienced Grav developers to dig into your site and determine why it’s slow, and potentially fix them, I strongly suggest you contact us via https://trilby.media

@OleVik @rhuk thank you for your support and insights so basically I’m stuck with these issues until dev comes back or better yet I hire someone from your team in order to fix this properly because now I agree with @rhuk it looks like dev is not experienced enough with grav.

Now forgive me to be blunt, but I feel I’m among friends by now, I don’t mean to criticize but merely ask what’s your take on this.
I guess this is the catch with nowadays open source products, 5% open and rest is paid service. So why keep calling it open source when all in all you can’t get it to work without purchasing additional rather hefty development or support service?
Product is “free” I get it, but then doesn’t it sounds a little tricky on “users” end?

It is a bit tricky for end-users to optimize their installations, I agree, but the vast majority of users can get it set up without much issue from a basic package running near optimized. However, as it is open source, support is limited to volunteer services or developers who familiarize themselves with it. As a general rule, any developer competent in PHP should be able to install, develop, and optimize Grav - but along with this comes optimizations outside of the scope of Grav’s core like assets and the server used.

TrilbyMedia is the official development and support service available for hire, which could be a good solution for you. I am not aware of the skillset of your devs but I would inquire about their level of experience with PHP and Front-end. The combination of a competent PHP-developer and designer with experience in optimizing websites should be more than enough to get even an advanced website up and running optimally.

Apart from the planned “Pro Admin” plugin everything related to Grav is free, including extensions, source code, and code dependencies. But even though it is made to be easy to set up and run, it does require a tech-savvy user to make it run well. The optimizations needed to get your site running in good order does are not all that difficult, but for your particular case I would advise finding out if your devs are up to the task.

Grav is open source which means that the code is completely open. Also 99% of plugins are open source too. This means that any competent developer can look over the code and understand it. That means that nothing stops a competent developer from becoming as knowledgable or skilled as the original authors. However, being the original authors does certainly give us a head start and a wealth of knowledge about all parts of the system.

You of course can get things working without professional support, it just requires that you have some development skills and a some commitment to learn new things. It’s not like a closed ecosystem like Microsoft and other closed-source platforms where the company that wrote the product has privileged information that is not available for others outside of that company.

Basically the custom jobs we get via Trilby Media is what allows us to pay the bills and keep us focused on Grav development and improvement. Nothing forces you to use any developer, but as is the saying with most things in life, “you get what you pay for” :slight_smile:

@OleVik @rhuk

thank you guys for getting back appreciate your thoughts, I’ve one quick question somehow got me in a quandary here, we are possibly going to opt for linode, however I was wondering would you suggest to first try and optimize the site as much as possible on current host to see whether it gets better or just transfer the whole stack right away?

Also I noticed that the software required for linode as I would need to access as well, comes also with quite a price, such as cpanel https://cpanel.com/
can you suggest a reliable open source for this one?

is this good https://www.virtualmin.com/? I got no idea because I never had to have those installed before.

Hi
As someone who is currently struggling with Google page speed scores right now, personally I find Grav in and of itself to really be “crazy fast”. However what this really means is that Grav doesn’t get in the way of content being served to visitors so that while the Grav team have done 90% of the work creating a great tool its up to us (devs, admins, hosting providers etc) to do the last 90% and optimize our site - this is still a fair bit of work. Turning on pipeling, caching, image optimisation etc should definitely be delivering some easy wins in terms of performance I’d expect, before getting needing to examine the hosting provider.

All that said, I’m currently trailing https://fortrabbit.com (which I found via the Grav learning site) they are basically PHP as a service so there’s no cpanel type environment but there is a basic dashboard and sftp access. Upload all your content (Grav files and all) and that’s it the site is live. The trial is free (no CC required) try it out for a day or two and see if changing hosts makes any discernible difference or not.

@csixtyfour thank you for the suggestion, we are testing it right now.