Improving Performance & Resource Efficiency

Dear YITH Support Team,

I hope this message finds you well.

I’ve been a long-time user of your products, and YITH WooCommerce Wishlist has been a core part of my projects. However, while performing a deep dive into my server performance and access logs recently, I identified several significant technical bottlenecks that I believe could be improved to make the plugin more competitive in the modern WordPress ecosystem.

I’d like to share my findings with your development team:

1. AJAX Overhead (admin-ajax.php): The current implementation of load_fragments triggers multiple POST requests to admin-ajax.php on every page load, even for guests. This bypasses server-side caching and puts heavy pressure on the CPU. For high-traffic sites, this becomes a major bottleneck.
2. Database Churn & Auto-Increment Issues: I noticed that the plugin creates a database entry in wp_yith_wcwl_lists for every unique visitor (including bots). On one of my staging sites, the auto-increment ID reached over 150,000, while the actual number of active wishlists was only around 200. This constant write/delete cycle for guest sessions adds unnecessary load to the SQL server.
3. Bot Optimization: Currently, search engine bots (like Googlebot) trigger the full Wishlist logic, including AJAX fragments. Since bots don’t use wishlists, this is a waste of crawl budget and server resources. A “no-bot” mode or a way to dequeue scripts for non-human agents would be a game-changer.
4. Modern Architecture (Request for LocalStorage): Many modern competitors are moving away from server-side sessions for guests. Using Browser LocalStorage to store guest wishlists would eliminate thousands of database writes and AJAX calls, making the plugin significantly faster and “cache-friendly.”

I truly value the flexibility of YITH Wishlist, but in an era where Core Web Vitals and server efficiency are top priorities, these “legacy” approaches to session management and AJAX feel like they need an update.

Are there any plans to transition to a REST API-based approach or to implement LocalStorage for unauthenticated users in future releases?

Thank you for your hard work and for considering this feedback!

Best regards, Oles