from Hacker News

Making Instagram.com faster: Part 3 – cache first

by stablemap on 10/11/19, 3:21 PM with 68 comments

  • by kaycebasques on 10/11/19, 4:07 PM

    > However, as the product grew, a side effect was that our web performance began to slow. Over the last year we made a conscious effort to improve this.

    We’ve [1] been advocating strongly for using performance budgets [2] as a means of protecting hard-earned performance improvements. There’s some depressing stat around performance regressions... something like 25-50% of big sites regress in performance 6 months after a big push to optimize. Don’t quote me on the specific number, I believe it’s mentioned in [3].

    [1]: Google Web DevRel

    [2]: https://web.dev/performance-budgets-101

    [3]: https://youtu.be/YJGCZCaIZkQ

  • by williamscales on 10/11/19, 4:05 PM

    The trick of properly applying operations to cached posts is cool. But the overall experience is bad. It's so frustrating to see an interesting post appear for a fraction of a second and then disappear. It would be far more usable to simply focus on getting fresh data as quickly as possible.
  • by mfontani on 10/11/19, 4:43 PM

    > we immediately present users with a cached copy of their previous feed and stories tray, and then replace it with fresh data once it’s available

    I vehemently HATE this pattern.

    I'm on a slow connection, and I open the app.

    Yay, I see some (cached) content. I start reading.

    After a random amount of time EVERYTHING CHANGES, and I can't get back to it. It's gone, for all intents and purposes, forever.

    I'd love to have a something which tells me there's fresh content to be had, and that I could - if and when I so wanted - CHOOSE to see it.

  • by opencl on 10/11/19, 5:04 PM

    I wonder if they're ever going to bring the web version anywhere close to feature parity with the apps, or update the UWP app that's been abandoned for years.
  • by purple_ducks on 10/11/19, 5:42 PM

    Does anybody from instagram actually use instagram.com?

    Because the comments side panel on pictures is probably the buggiest implementation of _anything_ i've ever seen.

  • by throwaway_bad on 10/11/19, 6:05 PM

    This looks like a pretty naive solution.

    The more elegant way to do optimistic UI would be to use CRDT or OT.

    Usually syncing is talked about in the context of syncing multiple clients. Here, we just want to sync the cached offline state with the server state. This allows you to make arbitrary changes to your offline state even if your server has conflicting changes incoming, it will all be eventually consistent in the end.

    I would love to see a blog post about that! (the only way I know how to implement it cleanly is using pouchdb)

  • by wolco on 10/11/19, 11:05 PM

    Instagram engineering,

    Why can't search handle two keywords?

  • by hwj on 10/11/19, 5:35 PM

    Beware, cache invalidation is one of the hard problems in computer science. ;)
  • by pmlnr on 10/11/19, 6:46 PM

    > in part 2 we talked about improving performance by pushing data directly to the client rather than waiting for the client to request the data

    I firmly believe this should never, ever be done. This is the very reason I swapped to linux from windows xp many years ago: there was no way to tell the computer not to do anything unless I ask for it.