[Resolved] Extremly slow loading times for views (504 errors)

[Author]

Posts

[marcoG-5]

Link to a page where the issue can be seen:

Time out here - about 50 results to show : hidden link
Slow loading with only 11 results, but page loads: hidden link

I expected to see: Faster load times

Instead, I got: Timeouts

[Beda]

It should be due to what the view displays.

For example, if you have a lot of conditions or a Featured image or Custom Image with a Custom Size generated by Views, then the loading will get very slow.
Also, this view which supposedly should load only 11 elements is not paginated, hence it loads all items at once.
Paginating can solve many performance issues.

Additionally, the conditional in the view is broken:
wpv-conditional if="('[wpv-post-field name="guru_company"]' ne '' )
That has a syntax (red) highlighting, which may slow down loading as well.
I suggest revising the quotes in that condition to correct it, and see if it helps (both to correct and to remove it)

Also I see my above assumption of custom image sizes used is true (width="150" height="352" )
This will slow the view by one second each image because views need to generate them
Better would be, to register such size in the theme so to generate it on media upload.

Can you confirm these steps solve the issue?

[marcoG-5]

Hello,

I've cleaned up the quotes and it had no effect.

Regarding the images - these are not featured images, and are being resized via HTML - these should not be re-generated by toolset.

To test your image theory, I removed the div that contained the images, again no effect on load times. The view only had 2 conditions, also ruling that theory out too.

I should not need to page 11 items, or 50. The system should be able to support such a simple output. I've generated larger (and more complex) lists of items with tooslet, and have not had this issue.

If there is a different approach to my view to optimise it (and keep the output), please let me know

Marco

[Beda]

I now see the page loading quite fast here hidden link
However, there is a JS error (Uncaught SyntaxError: Unexpected token < on hidden link) that could slow it down a little.

hidden link gives me still a 504 Gateway Timeout.
This could but does not have to, be due to this https://toolset.com/faq/why-do-i-get-a-500-server-error-when-editing-a-view/

You are right about the images, I totally inadequately interpreted them to be ShortCodes, in fact, they are not and hence, Views does not regenerate anything here.

The next step would be to confirm this happening without any other Plugin and another Theme.
Since locally, and as you say on other lists, this is not happening, it should hence be due to some other software interferences or a problematic server setting.
I see plugins warnings like "Redirection's database needs to be updated" which lead me to believe, this could be due to some timeout on redirects or other issues.

I exclude server (almost sure it's not) because your backend is loading satisfyingly fast, and the shorter view as well.
Hence I assume some problem with the content of the view and how that content interacts with other software.

Can you perform the above tests and if not solved, share the 504 producing View URL with me? I mean the Edit View link, which I cannot get from the front end since it produces a 504, and none of the scanned "Used on" matches the URL's you shared above.

Note also that the view does not become faster in your site even if I remove all Loop content.
It is hence pointing more and more to a problem with interferences of the query itself and other software.

I see you call fields in the query that are not made by Types, hence that could be an issue, as I am not sure how they are registered and eventually present a bottleneck
I also saw cache is used, which often can slow down especially Views since views already comes with a built-in cache system

All this should be doublechecked eventually on a testing site, before we can go on and once spotted, debug a technical issue within Views (if present)

Thank you!

[marcoG-5]

Hello

the problem was how the view was added to the page

[wpv-view name="test-guru" gurutype="shares"] works quickly

{!{wpv-view name='wealth-gurus' gurutype='business'}!} - this does not and casues the timeouts

Is there a reason these would work differently?

M

[Beda]

I do not see this happening with [wpv-view name="test-guru" gurutype="shares"] or {!{wpv-view name='test-guru' gurutype='business'}!}, as I changed the syntax in your code module to the correct {!{shortcode}!} on your site and the front end loads just fine:
hidden link
hidden link

Here, previously we got the 504, so I assume, there have been more changes than the ShortCode and they solved the issue.

For example, I see you mention 2 different Views.
The {!{wpv-view name='test-guru' gurutype='business'}!} one, seems to work no matter what the syntax.
{!{wpv-view name='wealth-gurus' gurutype='business'}!} instead, fails after a long trial to load.

But that is simply because the View is not generated with the GUI (which would be possible if editing this Page with a Content Template that is styled with DIVI and using Text Modules). This would then avoid passing not-existing ShortCode attributes.
The View wealth-gurus has no ShortCode attribute query but a URL parameter query.
So you cannot pass a shortcode attribute to it when inserting it.

However, removing that attribute did not solve the issue yet.
What solved it after all was to remove the Loop Content in the View.

So I adjusted this for you for now, by removing the ShortCode attribute from the View which is not working anyway, and then placed the Content Template of the Loop Item directly to the Loop, in the View hidden link
This worked.
You want to re-instantiate the Query there and order by your custom field, as I had to remove them temporarily to get all posts so to stress test it on a larger amount of items which now you can see loaded fast here:
hidden link

Please send me a copy of this site, if possible (https://toolset.com/faq/provide-supporters-copy-site/) so I can find out what the exact issue is in that View.
I will need to tear this site a bit apart so to isolate the problem and that's not good to do online/live.

Thanks!