Grav starts to lag out if to many pages clicked to quickly

Hi All,

I’m a webmaster in charge of a lot of Wordpress sites. I’m in the process of swapping one of my projects (as a test) over to Grav.

I’m LOVING Grav but I seem to have a problem that is leaving me scratching my head…

If I visit to many pages on my site to quickly the entire site starts to lag out for like 30 seconds to 1 min.

My test domain is:

To see if you can recreate the error, simply just start clicking pages before the previous one finishes loading.

Any help would be greatly appreciated!

I have no knowledge of browser internals, networking or Apache. Cannot help you there. But can do some observations…

Just had a look at your website using the network traffic tab in Chrome devtools (cache disabled). I fetched and noticed the following:

  • 36 request loading in total 8.1 MB, loads in ~18sec.
  • 19 / 36 requests are images loading in total 7.8MB. And these are loading very slow.
  • Jamming the shift F5 key delays load time to ~30sec.
  • It seems the images are causing the extra delay.

Not sure if this is causing any delay, but the images are not served from, but from

Doing the same tests on

  • 62 requests loading 8.2 MB, in ~19sec.
  • 23 / 62 requests are images loading 7.8 MB. Loading of images is very slow.
  • Jamming the shift F5 key does not cause any extra delay.

Thanks @pamtbaau

I moved all the images onto my test server.

When I do have the “lag out” problem, it’s when I visit to many different pages to quickly. Once the lag out occurs nothing will load on the site for about 30 seconds, then everything loads fine again.

It seems to happen when I visit :
Then click on the blog post on that page, takes forever to load and seems to crash the site.

Stalling happened a few times about 1 hr ago, but cannot reproduce any more…

Btw, you are aware that debugging is enabled?

So what it ended up being was a plugin called : Related Pages v1.1.4

Yes I turned on debugging to see if I could find the problem. I noticed that when I had the slow down, Related Pages was trying to re-cache the site for some reasons if there were to many requests.

You can change the settings of Related Pages to optimize the cache-hit it produces, but it must necessarily evaluate content to find relations. As @pamtbaau noted though, 7.8 MB worth of images should be considered massive these days. You should definitively optimize their loading by using responsive images, lazily loaded in srcset-attributes.

For my own insights I examined the Related Pages plugin and did some tests.

The Related Pages plugin has a paragraph Note about Performance. In my own words:

  • Finding related pages can be expensive, but resulting list is cached for subsequent request.

I did some testing on this: I created a fresh install of skeleton blog-site and added sleep(10) when Related Pages needed to rebuild the list. I printed now when related list needed to be rebuild, as well as when fetching list from cache.

Tests and results:

  1. Invalidate cache by touching system.yaml
  2. From http://localhost/site-blog/blog/hero-classes I hit all related pages
    DaringFireball Style Link :   Rebuilding: 2018-07-30 14:10:50
    Random Thoughts :             Rebuilding: 2018-07-30 14:11:01
    London at Night :             Rebuilding: 2018-07-30 14:11:12
    Focus and Blur :              Rebuilding: 2018-07-30 14:11:22
    Classic Modern Architecture : Rebuilding: 2018-07-30 14:11:33
    Every requested page added 10 secs before ‘Classic Modern Architecture’ was displayed.
  3. Without invalidating the cache, repeat 2:
    DaringFireball Style Link :   From cache: 2018-07-30 14:14:38
    Random Thoughts :             From cache: 2018-07-30 14:14:39
    London at Night :             From cache: 2018-07-30 14:14:39
    Focus and Blur :              From cache: 2018-07-30 14:14:40
    Classic Modern Architecture : From cache: 2018-07-30 14:14:41
    No overhead when list of related pages is fetched from cache.

In this test scenario, nothing seems to be wrong with the plugin ‘Related Pages’. The site does not ‘crash’ either. The connection with the server is just swamped by the repeated requests and accumulated overhead of building a list of related pages.

Besides, I think that it is an unlikely scenario that in production a user will hit all related pages and get penalised for being the first to rebuild the related pages list for each and every page requested.

Just my 2 cents…


I think this is interrelated to what the plugin must necessarily do to index itself, as well as cache-building from a cold cache. Those results would improve massively if the mechanism for indexing was running on something more advanced than the default filesystem-cache, just like cache in general runs much better when heated up.

Of course, not running it on content will improve performance a lot also.