Hacker News new | past | comments | ask | show | jobs | submit login

It is remarkably, painfully slow. Every letter entered into their search box (eg when searching a particular grocery store for a product) appears to be doing a full reload of results. You can feeeeel the horrible lag as you try to type and the site can't keep up with either your typed text or the results.

They should be doing a timed release on that. If you stop entering text for N ms, then go for a result. Otherwise they need to have cached results for a huge number of common combinations of letters, very frequently updated, for every store. It's a resource intensive thing to do well at their scale, for such a seemingly simple feature. If they are in fact caching all of those drop-down search results properly, something is very wrong on serving up the cached content.

And for the full results pages, when you try to load them for a given grocery store - the only answer I can guess for that is again mediocre caching. There usually isn't any other culprit other than that for such simple pages. In an effort to match current inventory, my guess is their caching isn't very good (constantly invalidated or rarely put into cache, so they're doing something that isn't very performant; I'd be astounded if they weren't doing some amount of caching on the results).




This makes sense technically, but it still doesn't answer the question of why it isn't fixed. Is it really that hard to experiment with caching policies? Is there secretly only one developer at instacart?


> They should be doing a timed release on that. If you stop entering text for N ms, then go for a result.

I believe that is called debouncing and it's something any non-junior frontend developer should have in their toolkit.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: