multiple iframe performance

1,453 views
Skip to first unread message

Jeremy Vuillermet

unread,
Sep 26, 2015, 7:53:48 AM9/26/15
to ClojureScript
Hello,

My app is composed of multiple mini games. Each of them is loaded in an iframe and have their own server.

The majority of them are written in clojurescript/reagent.
The problem is that loading the javascript is slow and very slow on mobile.

I'm trying to load only few games and then load the others on demand but that's also a problem because I need to be able to switch games quickly.

I just feel the root of the problem is I don't know how to share the commons lib. Ideally (I suppose) I would serve google closure and other common libs only once from the main app and the others iframe could use it or at least cache it.
iframes are on the same domain sub/domains.

Any idea on how to speed up the load time ?
(maybe the iframe is a bad idea and I would like to discuss alternatives)

Colin Yates

unread,
Sep 26, 2015, 8:07:00 AM9/26/15
to clojur...@googlegroups.com
Hi Jeremy, in my experience, as soon as I hear myself say ‘the problem is that XYZ is slow’ I now immediately stop and verify that that is actually the bottleneck, as in my experience, it rarely is. My intuition (and most of the people I know have awful intuition around performance). You might be different, I have no idea :-), but my first piece of advice is to validate that statement.

For example, rather than loading a game just use the exact same JavaScript but don’t start the game, instead display an ‘I am loaded’, now launch the same collection of iframes, is it still slow? If so then yes, that is your problem, if not then it is elsewhere.

One technique I usually do is have the backend return a HTML page with a literal timestamp (generated by the server) in it and then have the very first thing the JavaScript do is print the current timestamp - I can then see exactly how long the JavaScript loading took place.

Apologies if there is ‘teaching to suck eggs’ going on, but that would be my first place to look.

Other questions:
- are you using :advanced compilation as I found that was a nice little ‘go faster’ injection.
- do you have one atom which every iframe is sharing (ages since I used iframe but I understand they can’t access the same JavaScript space so I guess not)?
- exactly how much time does one iframe take, how much time do all the iframes take
- how many iframes
- how big is the compressed JavaScript file(s)
- iframes - really? :-)

(and if it isn’t clear I would be amazed if the bottleneck on a collection of iframes each running games was the _loading_ of the JavaScript :-)).

HTH.
> --
> Note that posts from new members are moderated - please be patient with your first post.
> ---
> You received this message because you are subscribed to the Google Groups "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com.
> To post to this group, send email to clojur...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.

Alan Moore

unread,
Sep 26, 2015, 11:58:47 AM9/26/15
to ClojureScript
Yes, you would be surprised at where all the time goes...

As Colin said, my advice is to measure everything using something like chrome tools, react's chrome tools or wireshark to find out how long each operation is taking.

If it turns out not to be the network you could be reaching a worst case with react and/or reagent. Maybe your games are too complex for the differencing algorithm and too much is changing each frame or you aren't using key= properly. One copy may work fine but maybe it doesn't scale. The react chrome tools should help you figure out what is going on.

Surprisingly, iframes can come in handy but less so as a UI feature and more as a performance tool. We have a page that has to display a small window of uncompressed video from a web socket onto a canvas element at 16-24 frames/sec and doing this in the main page/thread sucked up so much cpu that other background processing on the page was delayed or blocked and we were forced to move it to its own iframe. Most browsers give each page at least one thread, including iframes. YMMV.

Good luck.

Alan

Jeremy Vuillermet

unread,
Sep 27, 2015, 7:52:53 AM9/27/15
to clojur...@googlegroups.com
Ok thanks, I'll keep measuring until I'm sure where the problem come from.

We have games like Rock Paper Scissors or blind test so it's not a rendering performance problem but more a time to load/time to first render problem.
For quick context, those are simple games for video game streamers on twitch.tv that need to interact/play with their viewers.

Colin, I'm using advanced compilation, I don't have any code nor atom shared between frames. I have 6 iframes atm, one per game. 
The average size of each bundled js is 1.4M where at least 1M is common libs like React, reagent, reframe, core async ... (estimated based on the fact that some game only have 200 lines with no extra dependencies and still get 1.2M)

"iframe, really ?"
I could try to remove iframes and go with 1 page but then the build would be harder because some games are in pure js, other coffee etc ... I'm the only one using clojurescript in the team atm.
Some games are also played in standalone with their own URL.
That's mainly for those 2 reasons that the iframes made sense for us but I would really like to discuss other possibilities.

--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to a topic in the Google Groups "ClojureScript" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/wiCdwrjjAQ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com.

Nikita Beloglazov

unread,
Sep 27, 2015, 1:36:34 PM9/27/15
to ClojureScript
Hi Jeremy

To share you code you can try using closure modules: http://swannodette.github.io/2015/02/23/hello-google-closure-modules/

You setup will be something like this: 1 common shared module and then each game is a separate module that depends on the common module. Then you'll get n+1 js files. In each iframe you need load common module and a game module. But common module should be cached so you browser ends up loading it only once for the first game and reusing it from cache for all other games. Browser still needs evaluate js file in each iframe, but maybe it don't take too long.

Nikita

Reply all
Reply to author
Forward
0 new messages