General How to make Safari Browser work faster

[cola79]

Found out that Safari works much snappier and fluid if you go to settings-safari-enhanced-experimental webkit...

and uncheck constant properties and viewport fit and check instead async frame scrolling.

Its way faster now on my SE and scrolling is fluid now.

The settings to uncheck are only useful on an iPhone X, as it helps with the notch.

 

[friednoodles]

Before this becomes "a thing" (like people incessantly killing all apps in the task switcher thinking it improves battery life): don't go adjusting these settings unless you understand what they do and have a specific reason to need to change them.

Both of the options mentioned will have no impact on scrolling speed (except placebo, of course...). Constant Properties has nothing to do with rendering and Viewport Fit won't have an impact either, since it's only relevant on viewport size change (and turning it off will make sites that specifically support webkit's new viewport options look broken).

 

[C DM]

Before this becomes "a thing" (like people incessantly killing all apps in the task switcher thinking it improves battery life): don't go adjusting these settings unless you understand what they do and have a specific reason to need to change them.

Both of the options mentioned will have no impact on scrolling speed (except placebo, of course...). Constant Properties has nothing to do with rendering and Viewport Fit won't have an impact either, since it's only relevant on viewport size change (and turning it off will make sites that specifically support webkit's new viewport options look broken).

If those options play a role like that why are they experimental? Seems like not having any of them on should be the normal baseline.

 

[friednoodles]

So that web developers who are doing development can test their sites with these features turned on and off to check the sites are functioning as expected for both situations, without needing two separate devices on different iOS versions. It’s the same reason these options exist, on by default, in the hidden by default Develop menu in Safari on macOS.

 

[Dr.Ravencroft]

It is my understanding, that the first two mentioned settings won't have any impact on scrolling speed. The "async frame scrolling" however can have a positive impact.

 

[C DM]

So that web developers who are doing development can test their sites with these features turned on and off to check the sites are functioning as expected for both situations, without needing two separate devices on different iOS versions. It’s the same reason these options exist, on by default, in the hidden by default Develop menu in Safari on macOS.

That's fine, and that's part of what I'm saying though: if they are experimental and there to check and play around with, then the default state should be with them off and everything working correctly in that state.

 

[friednoodles]

That's fine, and that's part of what I'm saying though: if they are experimental and there to check and play around with, then the default state should be with them off and everything working correctly in that state.

I see what you're saying, you'd prefer the semantics of it were the other way around: that when Apple decides to enable such features by default, that they enable them internally but change the options to say "Disable Constant Properties" and "Disable Viewport Fit" and for those toggles to be off by default. So the result would be the same, but all the toggles would be off by default.

They could definitely do that, but the reason they don't is to provide developers with consistency during the process of these features being introduced into Safari. They start off by adding features and having them disabled by default, then once they're considered stable and ready for widespread use they enable them by turning on the preference by default, then eventually they bundle the behaviour in and remove the preference completely. For the sake of consistency and simplicity the behaviour of the menu (in the case of macOS) or toggle (in the case of iOS) is always left the same throughout that process, so that people who are actually working with these features on a regular basis don't have to keep adjusting to changing menu and toggle behaviours. It would be annoying to reverse the intent of the menus and toggles with different point releases when there's no reason to, especially since these preferences are not intended for the average user to be worrying about. That's why they're placed where they are, with the menu hidden by default on macOS, and tucked away in the bottom of Safari's "Advanced area in a section called "Experimental Features" on iOS.

And, back to the original topic of the thread, there's a reason why they're put out of the way: so that people who don't understand what these features do, don't go messing with them and then attributing non-existent benefits or disadvantages to them, spreading incorrect information that's going to make things worse for themselves and others.

I'm sure Apple would prefer the options were even more hidden for this reason, but they've done a great favour to developers who do need regular access to them by placing them in a directly accessible location - this is especially true of Viewport Fit, where it's extremely handy to be able to quickly turn it on and off while testing layouts on iPhone X.

 

[C DM]

I see what you're saying, you'd prefer the semantics of it were the other way around: that when Apple decides to enable such features by default, that they enable them internally but change the options to say "Disable Constant Properties" and "Disable Viewport Fit" and for those toggles to be off by default. So the result would be the same, but all the toggles would be off by default.

They could definitely do that, but the reason they don't is to provide developers with consistency during the process of these features being introduced into Safari. They start off by adding features and having them disabled by default, then once they're considered stable and ready for widespread use they enable them by turning on the preference by default, then eventually they bundle the behaviour in and remove the preference completely. For the sake of consistency and simplicity the behaviour of the menu (in the case of macOS) or toggle (in the case of iOS) is always left the same throughout that process, so that people who are actually working with these features on a regular basis don't have to keep adjusting to changing menu and toggle behaviours. It would be annoying to reverse the intent of the menus and toggles with different point releases when there's no reason to, especially since these preferences are not intended for the average user to be worrying about. That's why they're placed where they are, with the menu hidden by default on macOS, and tucked away in the bottom of Safari's "Advanced area in a section called "Experimental Features" on iOS.

And, back to the original topic of the thread, there's a reason why they're put out of the way: so that people who don't understand what these features do, don't go messing with them and then attributing non-existent benefits or disadvantages to them, spreading incorrect information that's going to make things worse for themselves and others.

I'm sure Apple would prefer the options were even more hidden for this reason, but they've done a great favour to developers who do need regular access to them by placing them in a directly accessible location - this is especially true of Viewport Fit, where it's extremely handy to be able to quickly turn it on and off while testing layouts on iPhone X.

If they are stable and are there for widespread use then they aren't experimental.

 

[friednoodles]

If they are stable and are there for widespread use then they aren't experimental.

Sure, but you need to put the options somewhere, and they start as experimental features. Indeed, just because they're stable and Apple has decided to turn them on by default, doesn't make them not experimental any more; some of them, like Viewport Fit, are features where the W3C specs are still in flux (and indeed changed during the past few betas of iOS 11 and the Safari Technology Previews), but which needed to be turned on to provide support for the iPhone X, which is actually informing the development of the spec.

But what you call them is, again, just another case of semantics. Yes, they could have the "Experimental Features" area and another area called "New Features" or similar, and then move each item from "Experimental Features" to "New Features" as they decide they're ready for widespread use, and change the names of the toggles, but all of that doesn't change anything about the functionality, or the intent that the ability to turn them on or off is something that average users shouldn't be worrying about.

And again, all of this is entirely off topic: the real issue with this thread is that changing Viewport Fit and Constant Properties will not, as the OP claims, improve scrolling in Safari. Also, before people start turning on Async Frame Scrolling thinking it's to do with rendering, it's not, it's to do with the ability to scroll frames and iframes inside a page that can also be scrolled.

I'll say it again: don't go adjusting these settings unless you understand what they do and have a specific reason to need to change them.