I picked up a client site which uses infinite scroll, so though I didn't do the original implementation, I've done a lot of work and improvements on it. It's basically a site which publishes video game strategy guides, so it gets a good amount of search engine traffic from people searching things like "how to beat X boss" or "how to find Y item in Z level," and the site owner is very interested in making sure the people who hit those pages can smoothly find the other pages (and the ads thereupon) in a guide. Here's some thoughts on the problems and challenges we've faced.

One, as mentioned in the article, the memory pressure and exhaustion issues - these were the biggest problems when I first started on the project. These were especially a problem on mobile, and a problem as guides grew in page count, page length, number and size of images, etc. To resolve this, after loading a new page, we basically do a rough count of the number of words in all guide pages currently loaded, and if it's over a certain number (I can't recall what it is off hand; 10,000, maybe), we start deleting pages in the opposite direction that the user is scrolling until we're under again - so if they're scrolling down, we remove the "previous"/"up" pages, and vice versa. (Gotta make sure to not actually delete any of the pages that are currently visible in the viewport, though…)

Oh, I guess I should mention that too; we actually have it working in two directions, so when you land on a page from a search engine result, the requested page loads, then we also load in a previous page and a next page. If you start scrolling up and getting near the beginning of the previous guide page, we again load another page above it which you can keep scrolling into if you'd like. That "two-way" infinite scroll is probably a bit more difficult to implement than just doing it in one direction.

Anyway, a huge problem that happens when you're adding and deleting pages like this is that the viewport would jump around, making it really annoying to try to read things. This is especially a problem when scrolling up and getting that page added above the existing content, or when scrolling down and a page above the existing viewport content is deleted. I can't remember the fine points of how I solved this but it basically involved measuring the height of pages as they get added/removed and then offsetting the location of the viewport by that height immediately after adding/removing the page such that it appears to the user that the jump never happened. This also means we had to make sure images on all pages have width and height attributes so that they don't cause repaints which reposition things as they load. Same with ad slots. This sort of math and trying to figure out what the browser is doing got hairy quickly and I always bristle when they want me to go back and touch up something to do with this code, but fortunately it's now in a state where that rarely happens.

Off the top of my head, I recall that another trick we're doing is that if the user clicks the link to another guide page, we capture that click and see if that page is already loaded, and, if so, scroll the user to that guide page rather than reloading the whole thing.

In the end, as a developer, this part of the code is not at all fun to work with, and as a user, I don't particularly like normal browser behaviors being hijacked for the purposes of locking in my attention like that. But I'm a step or two away from having to worry about user engagement analytics and all that nonsense, so I accept that the bosses have different priorities than I do and I do what they tell me to do in the best way I can do it. That's what they pay me for after all.

Edit: Also, we use the browser history API to change the URL appearing in the location bar when the user sufficiently scrolls on to a certain guide page, so for the most part, bookmarking, back and forward buttons, the "History" menu, etc all work as expected.