Safari works amazingly for small websites, but for websites with infinite scrolling like Tumblr and Twitter, it becomes unbearably slow after the first hundred or so posts. Historically, Safari is slow to adopt new web features, and it STILL doesn't have web push notifications (and more).

You can run these same websites on Android Chrome just fine, even on a lower-powered Android phone. I'm not sure if they're using APIs that need to be polyfilled on Safari, or if Safari is just trash.

At this time, I'm convinced that if Apple allowed other browser engines on the App Store, this would not be a problem at all, not that I can test it out anyways.

So, yes, Apple still has a say.

Once I’m down about 50ish posts on my feed, hitting back from a post to get back to the feed seems to have around a 25% chance to quickly throw a “Safari has detected a problem” error and force a refresh - sending me back to the top of the feed. And this is on an iPhone 12 Pro Max so it’s not like the hardware is out of date.

I primarily blame Safari, but on some level I think Twitter is aware of the problem and has no intentions of fixing it. The mobile Twitter site is purposely designed to make it nearly impossible to open a tweet in a background tab if it doesn’t have an image (the browser tries to select text on a long press). That’s clearly something Twitter could fix if they wanted to.

(I've got an oldish phone, but it performs fine on every website I ever visit except Twitter.)

Tested in Android Firefox on https://mobile.twitter.com/home.

Good. These features need to be supported by browsers for an extremely long time and Google is trying to force garbage under the guise of "standards." I hope Apple continues to fight against the ridiculous power hungry feature creep.

However, curiosity requires that I ask what/how/why does any of that affect mobile-first web deployment in away that it is not addressed when a large chunk of that mobile use is broken? If you program yourself into a dead end, back up and take another turn.

Oh, it is easier in a mobile native where you get the benefit of hoovering up personal data on all of your users? Gee, let's not expend effort to make something work universally, let's instead take the easy route and make money on the side too. The fact that losing this large share of users because of one type of content is not enough of a decision to go the other route shows just how much money there is in the hoovering of data.

Still putting the blame on Tumblr.

So, to me, Tumblr's website is already the main point of access, and these performance problems don't exist on Firefox or Chrome. I'm not talking about server-side response times, I'm talking about the time to render posts on the client. I find that a lot of times, after scrolling, you have to wait a few seconds before you see anything but the blue background that Tumblr has.

So, no, I'm going to pin it on Safari if (even) Firefox can deal with it.

Yahoo runs one of the biggest ad networks in the world, and you need to register to use Tumblr. They as already have everything they need to track you right there.

A mobile app in many circumstances reduces the data tracking (see this whole discussion about how effective Apple's do not track is because of their monopoly powers).

Just because Apple made it harder doesn't mean they made it impossible. There's a reason so many places work on making apps for multiple platforms (at least 2) rather than a unified web experience. There are benefits beyond serving a webpage in a native app, and they all want those benefits. Stick your head in the sand and deny it all you want, but it still happens.

That's absolutely not true, even if the web developer implements this in the Dumbest Possible Way. Please point me to an example page and prove me wrong.

You'll be able to see it take seconds to render at a time. This is true on an M1 Mac, as it is true on an A15 iPhone and M1 iPad.

I scrolled through 300+ stories (or whatever they're called on Tumblr) and it still hasn't slowed at all. Not sure what you're seeing.

On M1 Max with Safari 15.5, it took me about 40 seconds of fast scrolling to get it to start stuttering occasionally. Then, another 30 seconds to get it to start blanking out for a second at a time. And finally, another 30 seconds to get it to start taking seconds to render. I won't give the number of posts before it started lagging because I don't know the exact number.

On my phone (iPhone 13 Pro Max, albeit on the iOS 16 beta), it takes Safari about 15 seconds of scrolling before the scrolling drops to around 40fps from what looked close to 120fps. Then, another 20 seconds to start seeing things rendering halfway before jumping around and then rendering the correct post. This isn't necessarily a fair comparison due to the usage of beta software, but even on an M1 on production OS software it doesn't seem to be much better. Chrome 102 on macOS handles the exact thing that I did without any problem at all.

It's especially bad when you have a lot of videos on your dashboard. If you only have image posts, it might take a bit longer to start stuttering.

This has been the case for years, so it's nothing new. I remember this being a problem almost a decade ago, on an 4th generation iPad with the A6X SoC. Things have improved since then for sure, but those it's probably mostly hardware improvements that's helping.

I'll accept blaming Twitter's horrible performance on its use of React Native Web, but not Tumblr.

This really sounds like one of those issues a dedicated person finds where the devs look at it and say no reasonable user would ever do this. The issue if not closed as "won't fix" gets deprioritized so low that it never gets looked at again. Even as a dev, I'd not have the patience to recreate the problem. It's just such an outside edge case from expected behavior/usage that I don't even know what to say in response.

I don't think you're in the target audience of Tumblr, which is fine.

I honestly worry for people that do. There's something sad to me about people that do.

Is it a memory leak in Safari? Is it a framework issue? You've started us down the path to a thing, but then you didn't finish telling us the thing.

You mean Gecko or Blink? WebKit is really not the problem. Web Developers' strict compliance to only make sure their site works on Windows may be part of it.

Strange. This is exactly how I use Twitter on my i-devices, and it's perfectly smooth.

Seems pretty simple.

So yes, Apple may only have required Tumblr to more effectively moderate to prevent child porn, but from a business feasibility point of view the practical way to do that was ban all porn.

Or you do what Tumblr did, and just ban all porn.

The more accurate word might be "categorize" or "filter".

It was obvious what was meant by "sort" when reading the full text, but I think the counter-point was more of a tongue-in-cheek retort regarding the above than an actual complaint.

It's nothing more than ammo that corporations use against each other in the fight for dominance, or sometimes, with the help of cooperative media, against politically disfavored sites like 4chan. In all my time browsing 4chan, I have not once seen child porn, though I did see posts 404'd for having contained child porn. Yet despite their efforts, any time the media talks about 4chan, they will introduce it in the same breath as child porn.

In short, child porn has become nothing but a tool for corporations fighting for dominance, or a fnord to tell the masses to stay away. And in all of this no-one gives a crap about the children, since they rarely spend even a word talking about tracking down the uploaders or creators of said porn (i.e. they say a site "has child porn", but not how fast it is removed, or if the site gives the IP of child-porn uploaders to the police, or anything beyond trying to establish in the viewer a bad site <-> child porn association).

Aren't there legal requirements in place for this stuff, at least in the US?