Implement Object cache for listing grid

[Sidlegionair]

It seems currently queries done by the JetEngine listing grid do not get stored in the object cache. Please consider adding, this will create a huge performance boost for Redis and memcache enabled websites

[simonvanoordt]

This is a must for me too, for bigger projects

[simonvanoordt]

I'm no expert on caching, so I can't make a judgment on how much this will improve page load times. However, most people do use redis or Memcached, so this might be worth looking into? Also because some people report on slow load times when using multiple listing grids on one page. Here's a link to a fb on which people comment in favor of implementing this. https://m.facebook.com/groups/CrocoblockCommunity/permalink/3937748336316558/

[medienstuermer]

Would be great 👍🏻

[cbwstudios]

This is really needed.

[tealou]

Can I check on status of this? Even with only 300 posts, Listing Grids are really slow. 99 on GTMetrix for pages that don't have it... drops substantially on the page with Listing Grids with Queries made via Query Builder.

[cbwstudios]

Please make this happen! It's the #1 largest complain from any single client.

[tealou]

@cbwstudios have you found any temporary workarounds for it, other than... not using it? Running Litespeed Cache and know the basics but there's a point where server stuff gets boring/confusing. I have Query Builder with pagination and dates to reduce how many are loading, but this is a bit of a hacky workaround and doesn't seem to help when you've got an "All posts" with Taxonomy Filter....

[futureyoon]

Anybody has any workaround for this? I built a nice listing template and display them on a page. I saw multiple duplicated queries (using query monitor) being made to retrieve the data to show on a page which slow down the performance badly.

Wit this rate, I will have to keep considering how many listing to display due to the performance issue.

[secondsky]

@Floydtm Unbelievable that this is open TWO YEARS!?

The Listing Grid is not really usable on any project which has more then a like 200-300 posts, its fucking slow. Instead of adding useless bloat junk to your plugins, MAYBE GET THE BASE RIGHT!!!

And honestly, the same goes for JetSmartFilters Used both in past, but as it comes evidently that its useless underperforming junk, it gets no longer used anywhere.

[Lonsdale201]

+1

[hansf71]

Please!

[Akfree1st]

+1

[neylwalecki]

Please @Crocoblock do this! We really need it!!!!!!

[CptSlow2000]

+1 Somehow sth gets cached. But every time you add a post or change sth, you have to clear the Redis cache. Not optimal.

[secondsky]

Hey @Floydtm are you alive? Can you get us an answer when this is going to be implemented?

[danjs74]

Hello - just to say same issue for me. The listings are slow - i only have 10 items in mine at the moment and when i filter / clear filters etc generally the behaviour is sluggish, close to unusable.

[Vigar007]

This is over 2 years and still no fix, I just started using Crocoblock in March 2022 and all my sites have this issue, hoping for some kind of fix soon.

[valmirselmani]

@danjs74 I have also noticed this problem and it has gotten worse with the Elementor 3.6 update. If you go back to Elementor 3.5, it is much faster compared to the newer Elementor version.

I tested it again now and it's 3-4x times slower than with Elementor 3.5.

[danjs74]

@valmirselmani ah ok - so maybe some sort of mis-match going on with the Elementor code base. I've now moved over to use some different tools - Elementor / ACF Pro / Gridbuilder (https://wpgridbuilder.com/). Lightning fast.

[futureyoon]

@danjs74 Thx for the alternatives. At least you opened up some other options to achieve the similar outcome. Can anyone help ping developers or lead of crocoblock for any update on this item? It's really sad that we have to switch to another solutions...

[cbwstudios]

The issue is that Croco has a fundamental issue with how they deal with listing grid queries. Did any of you ever notice how a single listing grid can query the DB as many as 10 times? (yikes) I have looked under the hood extensively. They have several fundamental flaws with what they're doing. In order to fix the issue they are going to need to seriously overhaul JetEngine. Because they won't commit to fixing the issue they then compound it every time they add new features. It's truly becoming a major issue. As many here have stated, it's becoming such a major issue that most 'serious' designers/developers are moving away from JetEngine.

The people at Croco are very nice people, with some pretty great ideas, but their implementation of those ideas has some serious flaws.

[danjs74]

@cbwstudios yes I would concur with those comments. I have found quite a few bugs etc when using JetEngine, that compounded with the speed issue means i'm unlikely to ever use it again. I've found AFC Pro to be more stable and robust, nice interface etc. I've paired it with Gridbuilder (https://wpgridbuilder.com/) which as you can see has very fast listings.

[futureyoon]

@danjs74 just for my knowledge (little out of topic), wpgridbuilder has something similar like Profile Builder in Jetengine? I am considering to transit if no croco guys care about this issue.

[valmirselmani]

@danjs74 The funny thing is that you can also use the JetEngine Listing Grid with Gridbuilder. Have you tried that out yet? It would be interesting to know if that speeds up the ajax performance or if it is the same performance. If it has the same performance, then the problem is clearly with the JetEngine implementation.

[Deakoi]

Hi everyone. Has anyone been able to check the performance of showing in Bricks Builder's CSS Grid Layout (with the Automatic CSS plugin, also called ACSS, because Bricks Builder doesn't yet natively support Grid Layout) and with his native Query Loop option the dynamic fields created by JetEngine and combining it with the WP Gridbuilder plugin to be able to filter them (I don't know if this last filter plugin is still compatible with Bricks Builder)? It could be a good alternative if the performance was optimal. Thank you.

[futureyoon]

I saw the changelog of jetengine 3.0.4 today saying "ADD: allow to cast SQL query results into specific object".

Does this mean listing result will be into object cache? Anyone has better understanding of this update?

[secondsky]

As @Floydtm nor any other from the team seems to care, I say thx to the guys who mentioned the alternative. I will try it out and if it turns out to be faster and offer the workflow and features which I need.... Crocoblock can stay on the snail path.

[TomVDH]

Yeah, I'm about to launch a massive partner directory for my employer and with all of the praise and touting Crocoblock's products get (both thru affliate YouTubers and other resources) this seems like a painful shortcoming.

@Floydtm -- would be useful if you chould chime in and give a sign of life at the very least -- or point someone to us who is able to address our questions.

[gualtier]

+1 on this! Getting higher load times :(

[RuanPienaarCode]

+1 We have been enjoying using jetEngine, but we have been slowing down the more content we have loaded. Crocoblock please prioritise this issue. The biggest request from my employer in meetings has been performance but there is nothing more I can do, other than moving to a different plugin. Hope you can improve the server queries this year or early next year. Really enjoy your products otherwise.

[JonasHaouzi]

FYI, the support has been totally useless and not able to understand anything. I'm even wondering if someone of their support team is actually a developer.

Given that these slownesses were killing our websites, we had to implement something quick (and dirty) until we get rid of this plugin.

We added some new lines within the function render of the file jet-engine/includes/components/listings/render/listing-grid.php:

Update 1

After $listing_id = absint( $settings['lisitng_id'] );. We added: $cache_key = 'listing-grid-' . md5(serialize($settings));

Update 2

Before if ( ! $this->listing_id ) {. We added:

// validate cache
$cached_output = wp_cache_get($cache_key);
if (!empty($cached_output)) {
    echo $cached_output;
    return;
}

ob_start();

Update 3

After jet_engine()->frontend->frontend_scripts();. We added:

// store content on variable
$generated_content = ob_get_contents();
ob_end_clean();

echo $generated_content;

// store cache
wp_cache_add($cache_key, $generated_content);

You can find the final file here: https://gist.github.com/JonasHaouzi/50b3d206fd157f9ae8110889a735bd72

cc and thanks to: @djulianm

[ConsultMePL]

FYI, the support has been totally useless and not able to understand anything. I'm even wondering if someone of their support team is actually a developer.

Given that these slownesses were killing our websites, we had to implement something quick (and dirty) until we get rid of this plugin.

We added some new lines within the function render of the file jet-engine/includes/components/listings/render/listing-grid.php:

Update 1

After $listing_id = absint( $settings['lisitng_id'] );. We added: $cache_key = 'listing-grid-' . md5(serialize($settings));

Update 2

Before if ( ! $this->listing_id ) {. We added:

// validate cache
$cached_output = wp_cache_get($cache_key);
if (!empty($cached_output)) {
    echo $cached_output;
    return;
}

ob_start();

Update 3

After jet_engine()->frontend->frontend_scripts();. We added:

// store content on variable
$generated_content = ob_get_contents();
ob_end_clean();

echo $generated_content;

// store cache
wp_cache_add($cache_key, $generated_content);

You can find the final file here: https://gist.github.com/JonasHaouzi/50b3d206fd157f9ae8110889a735bd72

cc and thanks to: @djulianm

I've tried it. It broke one listing (which in fact was a "listing" - listing of terms/button for terms anchor nav), but no improvement in performance at all.

Still looking for alternatives, Croco plugins in general are slow

[futureyoon]

FYI, the support has been totally useless and not able to understand anything. I'm even wondering if someone of their support team is actually a developer.

Given that these slownesses were killing our websites, we had to implement something quick (and dirty) until we get rid of this plugin.

We added some new lines within the function render of the file jet-engine/includes/components/listings/render/listing-grid.php:

Update 1

After $listing_id = absint( $settings['lisitng_id'] );. We added: $cache_key = 'listing-grid-' . md5(serialize($settings));

Update 2

Before if ( ! $this->listing_id ) {. We added:

// validate cache
$cached_output = wp_cache_get($cache_key);
if (!empty($cached_output)) {
    echo $cached_output;
    return;
}

ob_start();

Update 3

After jet_engine()->frontend->frontend_scripts();. We added:

// store content on variable
$generated_content = ob_get_contents();
ob_end_clean();

echo $generated_content;

// store cache
wp_cache_add($cache_key, $generated_content);

You can find the final file here: https://gist.github.com/JonasHaouzi/50b3d206fd157f9ae8110889a735bd72

cc and thanks to: @djulianm

Hi, quick check. Does it matter which cache plugin I am using in order to get benefit out of these lines of code? I am using W3 total cache (Redis enabled). and fundamentally is there a way to check if the list is coming from cache?

[Sidlegionair]

Hi guys,

It is my understanding that WordPress will put all query's done through wp_query in the object cache by default since WP 6.1. This means the plugin no longer has to do anything and this issue thereby seems obsolete. Sad the crocoblock developers didn't act on it earlier though.

[RuanPienaarCode]

I was experiencing performance issues with slow query execution in JetEngine, primarily caused by having too many Custom Post Types (CPTs) with an excessive number of custom meta fields—some CPTs had over 40 meta fields. JetEngine stores custom post metadata in the wp_postmeta table, leading to inefficiencies when querying large numbers of meta fields.

For each query, the system retrieves rows from the wp_postmeta table based on the post ID and the meta key. This resulted in the following pattern:

1 Post x 10 Meta Fields = 10 Rows Retrieved 10 Posts x 10 Meta Fields = 100 Rows Retrieved 100 Posts x 30 Meta Fields = 3000 Rows Retrieved

As the number of posts and meta fields increased, the query time expanded exponentially due to the need to search through all the meta fields for each post.

Solution: Optimization by Reducing Meta Fields

I resolved the issue by cleaning up and optimizing the meta fields, reducing the number of fields per CPT. This led to a significant improvement in listing performance, as fewer rows need to be queried in the database.

[djulianm]

FYI, the support has been totally useless and not able to understand anything. I'm even wondering if someone of their support team is actually a developer. Given that these slownesses were killing our websites, we had to implement something quick (and dirty) until we get rid of this plugin. We added some new lines within the function render of the file jet-engine/includes/components/listings/render/listing-grid.php:

Update 1

After $listing_id = absint( $settings['lisitng_id'] );. We added: $cache_key = 'listing-grid-' . md5(serialize($settings));

Update 2

Before if ( ! $this->listing_id ) {. We added:

// validate cache
$cached_output = wp_cache_get($cache_key);
if (!empty($cached_output)) {
    echo $cached_output;
    return;
}

ob_start();

Update 3

After jet_engine()->frontend->frontend_scripts();. We added:

// store content on variable
$generated_content = ob_get_contents();
ob_end_clean();

echo $generated_content;

// store cache
wp_cache_add($cache_key, $generated_content);

You can find the final file here: https://gist.github.com/JonasHaouzi/50b3d206fd157f9ae8110889a735bd72 cc and thanks to: @djulianm

Hi, quick check. Does it matter which cache plugin I am using in order to get benefit out of these lines of code? I am using W3 total cache (Redis enabled). and fundamentally is there a way to check if the list is coming from cache?

We used W3TC, but you can use the regular get_option to store the structure. The think is that we have removed fully Elementor and this plugin from our website.