> 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].
That's us. Big win last fall, right back where we started. And it's not like we stopped working on things in the middle.
Every feature request is adding more logic to the code, and it's not uncommon for the business to ask for code that affects every single path.
I've noticed this before, but it's very true on this project: management is very hesitant to create new 'areas' of the application, and so more and more functionality shows up on the common paths through the code, with all of the attendant uptick in computational complexity that goes with it.
Long ago I had a job where they couldn't understand why the whole site had gotten slower. Well, apparently when we told them that putting an expensive call in the header on every view, that everything was going to get slower, they didn't believe us. Nobody needs that kind of data, the ones who do don't need it to be accurate to the millisecond, and every penny you spend on information the average user is unaffected by is wasted money.
There is no big picture. There is only hill climbing and getting stuck on local maxima constantly. And no I'm not bitter, why do you ask?
>There is no big picture. There is only hill climbing and getting stuck on local maxima constantly.
This really nicely describes why I think so much software becomes bloated. You see this with startups all the time--at first the product is hacky/clunky/lacking features, then after some time and love it does a small set of things really, really well and is truly a joy to use, and then later on it becomes slow, bloated, and trying to do far too much and ends up doing many things unremarkablely rather than a few things well (the opposite of "half, not half-assed").
I think that last stage happens when you have individual teams A/B testing new changes independently and hacking on each new piece without much thought to the overarching cohesiveness of the product. All the incentives naturally align toward this too, so it takes some really strong leadership to prevent it and have a broader product vision that supercedes all the local optima of each individual team's features.
(As a side note, this also often happens when the software/startup needs to be monetized)
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.
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.
Yeah, without constant focus on perf, things regress extremely quickly. We're building tight integration with perf budgets into our infra & dev workflows across both Instagram and Facebook, so that any perf regressions will be intentional tradeoffs with product experience rather than unfortunate accidents :)
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.
That was a common complaint but the newest version doesn't do that anymore. Instead of immediately loading the new content, you instead get a little hover button at the top of the feed that says New Posts - that you now click to load the new content.
Because the old system was indeed super annoying, seeing something cool and then having it disappear in a long feed was annoying beyond belief.
It's a small change with the hover button, but one that is definitely a huge improvement. Sometimes the biggest UX changes are super minor - but their impact on a user's experience is massive.
I was looking to make williamscales's very complaint as soon as I read this. Instagram's latest beta for Android 10 does not include this hover button.
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.
(Author here) To clarify, we don't actually replace it automatically - we show a pill notification that new stories are available. You can either choose to tap it and see the new feed, or ignore it and continue with what you were doing
I have definitely had the "the thing I was looking at right after the app opened disappeared after a few seconds and I can't find it again" experience /u/mfontani describes.
I just loaded Instagram and it did this. It’s probably not something you see because you open the app multiple times a day. You definitely run into it when you only open the app a few times a week.
I see the "new posts" pill if I've scrolled down into the cached content at all, but if I'm just looking at the first post I see the behavior everyone else is describing. It's still pretty annoying.
I have the latest version of the app (on iOS) installed and this literally just happened to me. I run into it nearly every time I open the app.
I also see if it the app is running in the background and I switch back over to IG. I can be in the middle of my feed and scrolling and after a few seconds it refreshes and I lose my spot.
I think it will be better if you remove unread posts from the bottom (keep everything till the scroll point) and append new posts, so, the user won't notice them.
I don't use instagram, but I use FB mobile and this same behavior exists on there, and I echo this sentiment.
I have 1000+ connections on FB, built out over the past 15 years (I started using FB in college when it was a college network); which is to say, I'd never be able to fully read everything every one of my connections have posted because there are too many. Sometimes I see an interesting post as I'm scrolling, start reading it, and everything changes (sometimes it waits until I click into the comments of a post, and go back, and then everything changes, which is arguably worse because now I can't refer back to the original post...). If I didn't make a mental note of who created that post, it's lost forever. If I remember who posted it, at least I could search for that person, and scroll down on their feed.
Yeah, I experience the same thing. The back button is entirely broken on Facebook. When going back, other stuff is loaded. It's hard to find the same post twice.
I only have like 150 friends on FB and it's already hard to find something.
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.
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.
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.
I agree, and this happens on an even not-slow connection. I would be interested in seeing the testing studies that made them go with this change. (I’m sure they did some.)
The Google Feed on Android phones does something similar but presents a "Refresh Feed" "pill" button when it detects that there's fresher content to pull. Surprised Instagram doesn't do this.
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.
You're probably talking about the desktop web version I assume. If you check out the mobile web version its actually pretty close features wise, theres direct messaging, stories, creation with webgl filters,etc. The desktop version of these is admittedly lagging behind though - but I'm optimistic that desktop will get some more love in future :)
Making web UIs is excruciating compared to mobile (where everything is designed to be as easy as possible for you) so I don't blame them. Their main userbase doesn't use laptop/desktop computers anyway. This is the trend now, where the website is just an ad to download the app.
The mobile web version and apps appear to use nearly the exact same react/react native codebase. I'm mostly just confused as to why the desktop web version is completely different (and much worse because they removed almost all the features) than the mobile web version.
I just tried. Why can't I upload shit from the website? I tried changing my user agent and clicking the new upload button that appeared and it didn't work (possibly because it was a video?)
What's the point of making a website if it's crippled compared to the mobile app?
If you really want to do Web uploads on Instagram, you can do it using Chrome.
When you're signed in to your account, right click the page > inspect. Then when the right side inspect panel opens, make sure "device tool bar" is toggled to show up (it's an option in the very top right, left of Elements, Console, Sources, etc).
Set the device options to responsive, something like 500x700 or whatever works for you. You can drag the dimensions on width. Then reload the page. It should retain the device dimensions choice and will show the mobile nav bar at the bottom that includes an upload button.
Can't reveal the exact numbers, but yeah - a lot of people use IG on web :) Mobile web was always the big focus for us though - most people assume its just a desktop only web version, but actually the mobile web version is much more fully featured than the desktop version.
I'm specifically asking about instagram staff because desktop instagram.com is embarrassingly buggy when it comes to basic core functionality such as the initial display of comments, and loading more comments using the plus symbol.
Since you're here, can I ask - is it intentional, when using IG on the web, if I click on a photo on someone's profile page, the comment section is auto-scrolled to the bottom instead of showing the description?
not buggy but very unfriendly imo. i don't have an account but i have bookmarked a few. not sure if being logged in makes any difference but my pattern is: click on interesting post, scroll down the comments section, scroll all the way back up so i can click on the "+" sign to get more comments, scroll down to where i left, read some more, go back to the "+" sign, etc...
does not make any sense!
i mean, i put up with it because i don't have an account and well they can decide not to show unregistered people anyone's feed.
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)
> 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.
Well you're loading the main feed page of instagram, you expect your feed photos to show right? We don't push random junk - its the content that the page needs to render something useful
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