Skip to content
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

Open
joeytwiddle opened this issue Sep 7, 2018 · 6 comments
Open

Make feed less heavy #393

joeytwiddle opened this issue Sep 7, 2018 · 6 comments

Comments

@joeytwiddle
Copy link
Collaborator

joeytwiddle commented Sep 7, 2018

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.)

@lionleaf
Copy link
Owner

lionleaf commented Sep 7, 2018

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!

@sigvef
Copy link
Collaborator

sigvef commented Sep 7, 2018

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!

@yonatan
Copy link
Contributor

yonatan commented Sep 7, 2018

Have you considered play/pause buttons (i.e. no autoplay)?

@imscary
Copy link
Contributor

imscary commented Sep 8, 2018

play/pause buttons can be hard to create... In my opinion, autoplay is the best choice here

@joeytwiddle
Copy link
Collaborator Author

joeytwiddle commented Sep 8, 2018

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:

  • Removing the canvas
  • Setting styles on the window or the canvas.
  • Breaking globals (for example overwriting Math.sin)
  • Overwriting dwitter API functions handled by reset()
  • Adding new globals handled by reset()
  • ... what else?

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).

@lionleaf
Copy link
Owner

lionleaf commented Sep 8, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants