META: UFR keeps crashing on Chrome mobile

The gfycat clips are very choppy for me on my desktop (Firefox and Chrome).  Not sure what is causing it, but it's been all season.

I use Firefox on iPhone and it happens to me as well.  (Also happens in Safari for me.)  The page constantly re-loads and eventually the browser crashes.  I have to hard restart the phone to get it to work, but that's a temporary solution.

When it happens across multiple platforms (Chrome, iPhone) and browsers, it's usually the site.  Usually.  However, I have a (speculative) explanation.

In my time troubleshooting mobile issues for a CDN (always a fun* time), I would occasionally see failing HTTP requests originating from the browser.  Not specific to MGoBlog, but it's quite common.  I mean when you load a site, only the initial hit is triggered by the end user.  Everything else should be due to embedded content (typically confirmed by the presence of the "referer" header).  Ah, but mobile browsers have other ideas.  They have various means of conserving device resources and bandwidth.  Sites do too, but some mobile optimizations are baked into the browser.  One optimization that seems particularly impacted by UFR is the piecemeal page load, which is a common front-end means of conserving resources.  These browser-initiated requests tend to be more fickle than end user or embedded content hits, and there's nothing either the end user or site owner can do to prevent them.

Mind you, this is an educated guess.  I can't actually troubleshoot the issue because the failure points are as opaque as what's going on in Schembechler Hall.  HOWEVA.  All other MGoBlog features work fine, at least for me, and the one thing they all have in common that does not apply to UFR is relatively short page length.  (I presume there's nothing special about how the UFR page is put together on the back end.)  Any mobile browser I use (re-)loads the page piecemeal, something they don't do (or need to do) as much for shorter columns.  Whatever they're using also seems buggy as hell, because somewhere along the line the cache or memory gets corrupted and the browser starts an infinite reload loop.

Suffice to say, they (as in Apple, Mozilla, Google, etc.) are not going to do anything about it.  Seth could give the Drupal community a try, but I can't speak for the odds he'll get a response.  It might be gfycat, but when I see the page load start to break down, it doesn't seem to be having problems with the images.  Also, when Ace was around, I don't remember seeing One Frame at a Time breaking my browser in the same way.  So, my first guess -- which may not be better than anyone else's -- is the piecemeal page load optimization is getting some kind of overflow by the sheer size of the HTML itself.  One possible solution is to make the UFR table a separate page and link to it, but that's probably something to consider/test during the offseason.

EDIT:  One thing to note about gfycat and autoplay is that it's something the piecemeal load optimization has to track across the whole page.  To conserve resources, the browser only autoplays media that's displayed on the screen (this is also to prevent cacophony when a page has multiple video clips), but to do that, it has to parse the entire page HTML so it knows where you're at.  It's trying to only load content you're viewing, but it also has to know where you are, so while it can delay loading the media content, it can't do anything about the voluminous HTML.  Usually the media is heavier (resource-wise and bandwidth-wise) than the HTML, but UFR is a glaring exception.  This is not the fault of gfycat, per se.  Browsers need to stop overriding autoplay settings (then they wouldn't need to parse the full page), but they won't do that, so again, I think the page itself needs to be broken up.

*it was not fun