4 ms·

Nice tool, but fails when the network is intermittent. I suggest loading all data together with the page, and avoid using AJAX altogether. It's not huge, afte

• bruno_labarbere 2y ago
  Thanks for the feedback! You're making a point. You're absolutely right: today, CLIC relies entirely on AJAX, which is not ideal if the connection drops. Loading everything upfront would make it more resilient, but I'm also trying to avoid making users wait several seconds before they can do anything. That said, the database is "only" 4.3 MB, so yeah, it's not huge, but my priority so far has been to get the compatibility logic right before optimizing performance. Basically, I focus on making sure the results are photographically accurate before worrying about network issues. Of course, if users can't even load the database, they don't have much to verify! I see a few ways to improve this: - Preloading a compressed version (.gz or .br) to reduce size. - Lazy-loading only what's necessary, then fetching extra data when needed (first need to learn how to do it). - Implementing a fallback cache (LocalStorage/IndexedDB) to avoid reloading every time. - Also, one potential optimization would be loading only the most popular brands/mounts first, then fetching the rest on demand. The problem? I don’t have enough user data yet to know what’s actually "popular" and I won’t get that data unless people use the tool first. So, yeah... chicken & egg problem. For now, brute force it is, but once I get more feedback on what users search for the most, I can optimize accordingly. It's a trade-off between "just making sure it works at all" and "making it load efficiently." But I’ll definitely look into this!