Interesting technical aspect. I had read previously where scrolling was supposed to be "improved" in iOS 10, yet I never saw this. In fact, it felt like a huge regression. I've noticed the scrolling is the worst in Safari (Apple's own app which you would think would be updated - perhaps because more visual content needs to be loaded while scrolling). I've also seen it in Messages, Twitter, Mail, and Music. Really, anything where there is a lot of information or a long list to scroll through. I never had a performance issue like this before on iOS 9, so when updating to iOS 10 to see the extreme jitters and white space pauses as the content is loaded was quite jolting, and had the effect of making it seem like a large performance regression. Besides, it's just plain annoying if you are scrolling a web article and have to wait multiple times for it to load and see these visual jitters when this just worked on iOS 9 without issue. Perhaps APFS will help, but it seems this just isn't much of an issue for Apple as it has not improved much throughout any of the iOS 10 releases.
There is a couple of things that makes the whole „simply showing a webpage” complicated.
iOS apps can be constructed from various APIs - UITableView, UICollectionView, WKWebView, to name most popular; all of those api’s have to conform to very strict rules if you want them to work fluidly on iOS devices. Conforming to those rules or following guidelines to create your custom views are time-consuming and are slowing down development, so we end up with everyone using code that are bloated, are repeating itself, don’t care about strong reference cycle (long story short: when object - like image you see scrolling through an app - is created and is no longer used: should be freed from memory, iOS provides it with ARC, but noone really cares - it is held in memory because some completely pointless variable in app stills refers to that object). That is our first problem.
If you open app written without consideration of memory constrains of mobile platform - firstly it works fluid, as it is empty or filled with not that much data (and it is indirectly related to actual amount of data, as app with hundreds of megabytes can work much more fluid that app only uses only 20 megabytes of ram). But in time you will see that once it was an fluid app it becomes more and more bloated. There could be a couple of reasons: reading and hoarding temporary objects in memory, problems with asynchronous - as it is, reading in background thread - reading from database, using JSON connections that have a long time to complete request.
As iOS have become more and more fully-front-multitasking (and with many processes running in the background) operating system - things that once were really simple, like forcing app to save it’s state and quit - became complicated. There is a base of tasks that cannot be force-quitted to free memory. And there are apps that, even if they are in background, finishing their tasks, uploading data, or doing whatever is allowed by iOS (they even may fetching data, if they received push notification, even if their state was suspended or you have force-quitted them recently).
So: first you have some very memory consuming and racing for the memory (even if force-quitted) apps like facebook (which abuses couple of iOS guidlines and probably uses some dirty workarounds for staying always-alive, VOIP kit to name the one), twitter, maybe instagram (I’m not familiar with it’s memory management, but I suppose it’s similiar, as in: whatsapp, google hangouts, etc.).
Second: iOS memory management frees amount of memory that is within a scope of your request: it doesn’t know if you scroll back in your imessage history and there is 15 megabytes animated GIF. If it is requested: it would free memory that are being used by some app - and provide it to imessage. (And no, making iPhone or iPad 64 gb RAM version would not help in this case).
APFS can help in cases when reading from disk (like scrolling in imessage, providing app with GIF file) because it will have higher priority, and probably could be prefetched with some system options.
And there is a problem with web pages: modern web pages are full of javascript and whatever they think that they are loading data. They mostly do it synchronously, even if a lone developer thought thoroughly to make his chunk of work conforms to DOM. When you view a webpage you should see only a part of a webpage that is a part of the DOM structure, not all of crazy api-css-style-json-ajax-with references to twenty or so web pages providing some sort of code needed to work-code. That is when you browse through an bloated webpage you receive subpar user experience.
Web view have to rebuild from http/json/yourmomma request (still: in memory) to show the portion of screen you want to view.
It’s only a scratch of the problem. But: yes, this is why web/web-js-based-app/apps are causing a not-fluid scrolling.