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.