Just wondering what the optimim settings are for AJAX transition between pages in the Advanced settings.
I find that it can be quite slow on the first page transition (4-5 seconds sometimes), and then it is fine when clicking on other pages.
Seems to work pretty quickly without AJAX enabled.
This is most likely the cache.
I suggest to play with those settings, and your own cache in the server or install, if any.
If then this issue persists also with the usual clean install (Toolset, WordPress and a native Theme), please report back to me.
We will need to look at your install directly. Sometimes it can be that data called creates a bottle neck and it slows the site down.
But from what I read here, this is entirely due to the cache.
Although, 4-5 seconds is NOT expected and that is why I would like you to report back to me in case you still will see those issues.
We will then be eager to analyze and as usual solve it (I hope, fast).
I enabled all the private forms, as you are already experienced with our Forum system I assume you are familiar with all the packages you can add if you have any (Duplicator, Database Dump, etc).
As usual, if you provide such data, please let me know where to see the issue quickly.
Thank you, Lindsay, for your continued presence here in the Forums.
It's like seeing an. old friend... just only written form 😀
OK, I'm going to do some testing with the various settings in the Advanced options first - it seems to be around the 2 second mark atm.... the third page has fewer suppliers on it and seems a little faster. Maybe reducing the number of posts per page to 9 might help - it's currently 12?
So to test I've gone to look at a Supplier single page, backed out in the browser then clicked on the pagination. First move to either page 1 or 2 is always slower, once we've gone to the first page chosen and then move to another using the pagination it's pretty quick. I've attached my current Advanced options JFYI.
Could you just have a look remotely as a visitor? I'm not entirely sure if it's the slowness of my local internet connection skewing it a bit my end?
Then I'll move on to testing with a cleaner site etc.
Yes, sorry for so many support logs! It's really nice to be referred to as an old friend though as I must be a nuisance really :). Thank you very much for everything you do, the support you give and for this amazing product.
I can confirm a similar issue you describe.
Just load this page:
https://toolset.com/known-issues/
Then paginate by one and see a huge delay.
Paginate again and all is fast.
I also know why it happens, but that does not mean I declare this as expected.
It's Views's cache mechanism. It has to load a set of results and paginate them.
Depending on your settings this will even preload images.
This allows fast load on subsequent pages, but we got to start somewhere, right?
So when Views receives the data, it caches it, and that includes usually more than the current page.
So this is why it takes longer to load the first set of results.
This initial load could theoretically be brought down by not loading subsequent images and so on (this can all be changed in the Custom Search Settings)
But then you will just have a "more evenly" divided load time on all results pages.
Right now, only the first load is slow, then it is cached and hence there to display at the very moment of the call.
I will discuss with the Developers if this can be avoided somehow, but I fear this is partially expected, although, I feel it is longer than in previous Views versions.
That is what concerns me and why I will discuss this with the Developers.
Can you wait until they have some reply for me?
If this is urgent, I can look directly into it, but I am not sure I can even see this issue on your end.
I loaded hidden link and paginated it.
It was super fast.
Am I looking at the wrong page?
Hi Beda, thanks for your help - more than happy to wait.
You are not looking at the wrong page, I'm glad it appears super fast. After testing some of the settings in the Pagination 'Advanced options' I found that leaving it as I set in 'Views - Pagination Advanced Settings.png' (image above) seemed to be the best 'balance' for now and it's not too bad - though as we agree the first page load is definitely more sluggish and from my end that first page load can be 1/2/3 secs (not consistent). I can live with it for now though.
Thank you again.
The Views Lead Developer Juan updated me regarding this issue:
There is a tradeoff here and it is difficult to solve.
The loading time for the first pagination event accounts not just fpr gathering the next page, but also for caching the upcoming pages: if you started pagination, chances are that you will continue doing so, so it makes sense to do this caching as stated in the View settings. We need to do it before the second page gets displayed, because otherwise the caching becomes useless since you could try to paginate to the third page before it is indeed cached.
Now, on firts pageload, we are not cachign the second one, because it is expensive. We only start caching when you do show that you do want to paginate. So the second page is not cached when you try to reach it.
We can cache the second (and up to the reach set in the View settings) page when first loading the first one, but that will introduce a server interaction that will be useless for most of the visitors, but will load the server and database anyway. Or we can continue as we are now.
There is no win-win solution here, but we are open to suggestions.
Now, my idea was to leave this as is, as it makes sense why it happens and how it happens.
I would suggest to document this instead.
Do you agree?
