-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make feed less heavy #393
Comments
Also see #66 This would be awesome to sort out! How big impact does the actual creation of the iframe and canvas have? Currently it even does a network request, but I haven't had issues with the speed of loading new dweets, more with everything getting sluggish at some point. So one alternative that might be simpler is to simply have a way to completely destroy iframes when scrolled away far enough and recreate them if they scroll back in. But your idea to keep a pool of iframes that circulate is definitely going to be the fastest way to do it. It would require a change in how dweets are loaded, but doable with the json api and some js. I would be happy with either solution as long as we can scroll infinitely! |
Some good ideas here! In particular though I think we're dependent on fully destroying and recreating canvases to make sure they are 100% clean slate. We can still unload iframes that have scrolled out of view! |
Have you considered play/pause buttons (i.e. no autoplay)? |
play/pause buttons can be hard to create... In my opinion, autoplay is the best choice here |
sigvef is probably correct. Reusing the iframe+canvas might work 99% of the time, but sometimes a dweet will change the window in a way we can't easily reset or undo. For example:
Unless we can solve all of those problems, we must destroy old iframes and create new ones. Still, I hope that doing just that should provide some performance improvement. @yonatan Not autoplaying dweets would reduce resource consumption, but ideally I want to play them, I just want the resources back again once they are some way off screen! However, I would be quite happy with an option to disable autoplay (with autoplay on by default). |
Full destruction and recreation is probably the way to go. I expect it would help quite a bit, so I suggest we start there. If the recreation is still slightly sluggish I expect we could do things like remembering the dweet code and create the new iframe + canvas purely by js, avoiding the network request. But that can wait until we have destruction / recreation in place. @yonatan I agree with joeytwiddle and kipkat in that I want to keep the autoplay, at least by default. But I have considered pause/resume buttons, see #205, but I'm no longer certain if they are worth the screen estate |
The feed is currently a big sluggish, I suspect because:
It keeps creating new iframes and canvases. After you have viewed 4 pages of dweets, your window will have 40 iframes in the DOM, with 40 large canvases!
When a new page of 10 dweets loads, 10 iframes are created all at the same time, and the first frame of each dweet is rendered too. This can make time-to-see-next-dweet quite large.
My suggestion:
Keep a pool of maybe 20 iframes, and re-use the old ones.
So for example, when we load dweet 21, we would actually re-use the iframe and canvas and dweet card HTML from the first dweet, which is now way off the top of the screen.
(We could do this by getting the
clientHeight
of the old dweet card, and changing that box into an empty div. Then we can set the new values into the old dweet card, and append the dweet card at the bottom of the page.)(The pool size may need to adapt to the display, for example if someone has a monitor the same height as the Empire State Building.)
Ideally, load the data for the next 10 dweets pre-emptively, but don't do anything with it. Wait until a dweet scrolls (nearly) into view, before creating/stealing its iframe. Wait until it is actually in view before rendering its first frame.
Optional extra: Let me limit the pool size to 1, so the size of the DOM will be as small as realistically possible. (This would be a suitable mode for old phones with very little memory.)
The text was updated successfully, but these errors were encountered: