I’ve built a dash app but it takes lot of time to fully become Interactive, here’s what google’s PageSpeed Insights had to say about it.
Any idea on how to minimize network payloads?
Can anyone help me to improve the performance of this app.
Thanks
It looks like you’re running in dev mode. This means you’re serving up the unminified files for the all the Dash javascript files. Fort testing performance (and for running in production) Turn debug mode off with debug=False in your call to run_server.
Also, if this is for a production context you might want to use a WSGI server to run the app.
1 Like
hi, thanks for the reply, i turned debug to false, can you provide me with additional details on how to run the app in WSGI server.
See the Deployment page on the Dash Docs. You can essentially follow any tutorial you find for hosting a WSGI app (using gunicorn or uwsgi etc), but where you find the WSGI callable in the tutorials code (often called application or app) you would point it at the Flask server instance attached to the Dash instance. In most Dash examples, this is app.server (where app is the Dash instance).
1 Like
Although I would guess that you won’t see that much performance change from the Pagespeed tool. This is probably more relevant from the performance side of scaling against some amount of user load.
Just out of curiosity, how are those estimated savings (2.44s, 1.55s) even possible when the initial app only takes about 1.3 seconds to load based on your first screenshot? And to be honest, 1.3 second load time is not something I’d spend to much effort optimizing. You’d probably have more impact on UX by optimizing runtime by profiling what is going on in your callbacks.
1 Like
Just an empty layout page takes 1.3 seconds, the total time taken to load all the charts is more and that is what I’m trying to optimize.
In that case, you will need to look into the algorithm and data structures you are using to generate the charts.
Does it just take a while to load, or does each UI interaction feel slow as well?
If it’s the former, then you could pre-render the initial figures and not perform any calculations. As for the latter situation, you could look into memoization with flask caching, but I’d still stress profiling your call backs.
Hey can you give me an example on profiling callbacks?
Not sure how to really give an example that doesn’t feel contrived, so I instead put together a few steps that you can follow to pinpoint any bottle necks in your application. Also remember that with optimizations, there is going to be a cost-benefit relationship with time invested, so you should really decide whether shaving off a couple seconds is really necessary.
Steps:
1: Check out the browser’s network tab:
Open up the browser dev tools and inspect what is going on in the network tab. This tab allows you to inspect all the requests as they come in and breaks down their roundtrip time from request to response. Make sure that you are not in debug mode though so you don’t have see the constant interval of reloads which make it harder to focus on the requests that you trigger yourself.
Here is screenshot of my network tab when I toggle a dropdown in one of my applications. It took ~261ms to complete:
That said, I wouldn’t treat these as exact times since there are a lot of variables at play such as different hardware for starters. Rather, this should simply be used as a sniff test for any callbacks that are taking relatively longer than other ones, and thus warrant more review.
2.Profiling:
After you have have narrowed down your bottlenecks, you can now profile the underlying code, isolated from your dash application. Here are the python 3.x docs for the standard library profiler: https://docs.python.org/3/library/profile.html
3.Use timeit to compare alternative methods:
Once you have figured out the bottle neck, via profiling, you can now look into alternative implementations. You will want to test the contenders and see if they are an improvement or not. This can be done with python’s timeit module. Here are the relative docs for that one: https://docs.python.org/3.7/library/timeit.html. I don’t know why though, but I find it tricky to implement that module. I instead use the %timeit magic function in ipython/jupyter notebook as I don’t have to do any setup. Tell me that this isn’t as simple as it gets:
In [1]: %timeit [i*i for i in range(100)]
6.61 µs ± 79.7 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
Hope this helps and good luck!
5 Likes
Thanks for this, I’ll try and update you.
That’s odd. You’ll want to open up the network tab of the browser developer tools as described in step 1 of @mbkupfer’s reply. Look for the entries corresponding to requests for your static assets and see if they have any errors.
Also, did you supply the name parameter to your Dash instance?
1 Like