Making Instagram.com faster: Part 3 – cache first • Hacker News Board

Re: Making Instagram.com faster: Part 3 – cache first

#11

Post by FakeComments » Fri, Oct 11, 2019, 4:51 PM UTC

nullandvoid wrote: post #6

williamscales wrote: post #2

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.

The same thing annoys me with youtube - notice something cool as you click something on the home page but then by the time you've clicked something and gone back its disappeared

This is made worse by the mobile experience of having every part of the page be some kind of button.

80% of my clicks are my palm grazing the edge as I hold it or trying to scroll and accidentally clicking on some block element link that doesn’t stand out as a button.

Re: Making Instagram.com faster: Part 3 – cache first

#12

Post by manigandham » Fri, Oct 11, 2019, 4:53 PM UTC

mfontani wrote: post #7

> 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…

Similar to Twitter and other social apps. Agreed that it's a very annoying experience.

Re: Making Instagram.com faster: Part 3 – cache first

#13

Post by KineticLensman » Fri, Oct 11, 2019, 4:56 PM UTC

mfontani wrote: post #7

> 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…

And the Guardian app as well. Opens to the last front page headline, and then refreshes after a few seconds.

Re: Making Instagram.com faster: Part 3 – cache first

#14

Post by jstummbillig » Fri, Oct 11, 2019, 5:01 PM UTC

mfontani wrote: post #7

> 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…

I am astonished by how any organization with considerable resources to solve these things could arrive at this solution.

If its good enough to show, it's good enough for me to look at. If it's good enough to look at, don't fucking rip it from my eyes.

Do not touch the viewport after content has been loaded. Hydrated into the feed only below everything the user might currently be looking at.

Re: Making Instagram.com faster: Part 3 – cache first

#15

Post by opencl » Fri, Oct 11, 2019, 5:04 PM UTC

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.

Re: Making Instagram.com faster: Part 3 – cache first

#16

Post by code_duck » Fri, Oct 11, 2019, 5:04 PM UTC

jarjoura wrote: post #8

mfontani wrote: post #7

> 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…

I'm pretty sure if you touch the feed at all, or it detects you haven't seen the content before it'll put a button there that won't move you to the top of the feed until you tap on it for that very reason.

You have to scroll past the first post.

Re: Making Instagram.com faster: Part 3 – cache first

#17

Post by arciini » Fri, Oct 11, 2019, 5:11 PM UTC

kaycebasques wrote: post #3

> 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…

In my experience, this cycle of "add features and performance regresses" and "fix performance" is actually not a bad way to do it, because it allows for better overall budgeting.

If you're constantly ensuring that performance doesn't regress, this makes certain features a lot harder to implement. In some cases, the better solution is not to "make this feature take a lot less of the budget", but to say, "are there other parts of the budget that are easier to cut than the current feature".

Having regular performance optimization sprints allows for us to "cut where it's easiest" rather than forcing us to restrict non-performant features, when they might be very useful for the business.

Re: Making Instagram.com faster: Part 3 – cache first

#18

Post by IanCal » Fri, Oct 11, 2019, 5:14 PM UTC

jstummbillig wrote: post #14

mfontani wrote: post #7

> 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…

I am astonished by how any organization with considerable resources to solve these things could arrive at this solution. If its good enough to show, it's good enough for me to look at. If it's good enough to look at, don't fucking rip it from my eyes. Do not touch the viewport after content has been loaded. Hydrated into the feed only below everything the user might currently be looking at .

This constantly annoys me on the shield TV. The YouTube recommended items will change while I'm scrolling through them. Something will look interesting and before I hit OK the item I'm currently on disappears. Unless I remember enough about it I can't find it again.

Re: Making Instagram.com faster: Part 3 – cache first

#19

Post by uluyol » Fri, Oct 11, 2019, 5:16 PM UTC

arciini wrote: post #17

kaycebasques wrote: post #3

> 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…

In my experience, this cycle of "add features and performance regresses" and "fix performance" is actually not a bad way to do it, because it allows for better overall budgeting. If you're constantly ensuring that performance doesn't regress, this makes certain features a lot harder to implement. In some cases, the better solution is not to "make this feature take a lot less of the budget", but to say, "are there oth…

Monitoring is key here. The point is that sacrificing performance should be a conscious decision not an accidental one. Small fixes can sometimes prevent big regressions from ever occurring.

Re: Making Instagram.com faster: Part 3 – cache first

#20

Post by OutsmartDan » Fri, Oct 11, 2019, 5:21 PM UTC

mfontani wrote: post #7

> 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…

Yes, I would rather the page be blank and load correctly rather than having content replaced while I'm actively looking at it. This pattern should be an anti-pattern, but I would assume they probably have a KPI to decrease site load time by a percentage versus a better product experience.