Medusa: Discussion: Web UI takes a lot of time to load
Before reading, please add Horizon | 1964-05-02 | BBC Two tv series, wait until the show is downloaded and open the episodes list.
NOTE: I'm not requesting anything. I'm just opening a discussion to see if we can improve Medusa. I know the source code of this project is huge and some parts of them are really old (from other projects). I also know you are moving to Vue slowly, but IMHO efforts could be done in a smarter way.
I always thought Medusa takes a long time to load the episodes list because of I'm running Medusa in a hardware with low resources, but I was wrong. It takes almost the same time to load if I run Medusa in my powerful desktop.
- I did some profiling tests in the python backend and everything was perfectly fine, most of the time the Tornado server was idle. I saw some things that could be improved, but the main problem is not here.
- Profiling in the web browser I saw more disturbing things. First thing I saw was we are loading a lot of resources, although most of them are already cached after the first visit. We can reduce the number of downloaded files but the main problem wasn't the download of these files... Most of the time to load the page was spent in executing JS code. I can't give you more detail, but just loading the vendors.js file takes around 500ms.
Just some open questions:
- Are we using all dependencies included in vendors / vendor JS files? E.g. we have jQuery and most of the things could be done in Vue in a more clean way.
- Could we pack all JS files better? We can concat and minimize all JS files in only 1 file to sped up download (same could be done with CSS). We should take a look at vendors.js file also, Firefox is taking to much time to load that file, maybe we are doing something wrong with Webpack...
- How far we are from having a real SPA in Vue? Now, each time you click something in the web the whole page is loaded. Using Vue Router this can be avoided in most cases. If we can't reduce vendors file, with this approach will be loaded only once...
- Why we don't render most of the page in the client side (browser)? I saw really weird things. E.g. The list of episodes is rendered in the server (displayShow.mako), but before the paged loads, you get the same information (the list of episodes) from API
/api/v2/series/tvdb260449?detailed=trueso the same information is downloaded 2 times. IMHO we should download only the API and render with Vue in client side. In most cases the backend runs with low resources and the browser runs in a powerful desktop/mobile. - Why we have "pull connections" to the server with websockets and API calls at the same time? E.g. In the episodes list there are one websocket open and calls to
/home/getManualSearchStatus?indexername=tvdb&seriesid=260449every few seconds - It's necessary to load the configuration
api/v2/config/mainand all JS files in every page? Having a SPA will fix this issue too. - Why we have the same resources duplicated in dark and light themes? I think the JS code and most images should be the same, only 1 different CSS (and some images) for each theme.
I think removing unused dependencies (vendors /vendor JS) and merging dark and light themes will make the code more maintainable. Packaging all JS and all CSS in only 1 file will reduce the page load time. And moving to a real SPA will make Medusa amazing and blazing fast.
ping @p0psicles @medariox @sharkykh
ngosang
All 2 comments
When I have more time to answer I'll go in more detail, but.. Most of your observations are just valid. Can't say much about it then, yes we know and yes we'd want to have it that way eventually.
But it's going slow as the only active contributors are mainly python devs. So the frontend SPA development is on a break. Or going very slow.
Also yes the old api v1 polling should eventually be replaced by websockets. The same as how we plan to update the "state".
The theme can also be merged again. But that just had a much lower prio to us.
p0psicles
on 22 Jan 2019
I can go in more detail for what its worth.
Are we using all dependencies included in vendors / vendor JS files? E.g. we have jQuery and most of the things could be done in Vue in a more clean way.
Part of the process in moving to Vue. Just work. The more we move to vue the smaller the vendor file will become. But with that part of it will be added as vue components of course.
Could we pack all JS files better? We can concat and minimize all JS files in only 1 file to sped up download (same could be done with CSS). We should take a look at vendors.js file also, Firefox is taking to much time to load that file, maybe we are doing something wrong with Webpack...
Not an expert on webpack myself. But as i understand, moving to a single webpacked SPA will improve this.
How far we are from having a real SPA in Vue? Now, each time you click something in the web the whole page is loaded. Using Vue Router this can be avoided in most cases. If we can't reduce vendors file, with this approach will be loaded only once...
Not very far. Each mako template needs to be refactored to vue. So step 1 is remove the mako variables and replace them with vue templating. Then step 2 is refactoring the mako to a pure .vue file. And moving it into /themes-default/slim/src/components and make it part of Vue Router. From looking at src/components you can see that only:
- add-recommended
- add-shows
- add-recommended
- config-post-processing
- config
- login
- irc
- app-header
have been transitioned.
You see that some don't have a tag. So those aren't fully transitioned. As they are combined (through a hack) with a mako template.
I also created a list of the highest prio todo's here: #4765
Why we don't render most of the page in the client side (browser)? I saw really weird things. E.g. The list of episodes is rendered in the server (displayShow.mako), but before the paged loads, you get the same information (the list of episodes) from API /api/v2/series/tvdb260449?detailed=true so the same information is downloaded 2 times. IMHO we should download only the API and render with Vue in client side. In most cases the backend runs with low resources and the browser runs in a powerful desktop/mobile.
You are right. This is because someone started changing this to vue. But stopped half way in the process. It's also bothering me. We use vuex for state management. And the goal is to build up initially the state with the apiv2 calls. Then update it through websockets through events from server side. Obviously the mako is to be removed.
Why we have "pull connections" to the server with websockets and API calls at the same time? E.g. In the episodes list there are one websocket open and calls to /home/getManualSearchStatus?indexername=tvdb&seriesid=260449 every few seconds
It's necessary to load the configuration api/v2/config/main and all JS files in every page? Having a SPA will fix this issue too.
Why we have the same resources duplicated in dark and light themes? I think the JS code and most images should be the same, only 1 different CSS (and some images) for each theme.
Yes the old api v1 polling should eventually be replaced by websockets. The same as how we plan to update the "state".
Only one theme is served. The build scripts have already been adjusted to build a dark and light theme from the /themes-default/slim theme. So in terms of performance this isn't really an issue right now.
p0psicles
on 23 Jan 2019
Related issues
skarekrow
路
4Comments
Shootersss
路
3Comments
hergonoway
路
4Comments
elpedriyo
路
4Comments
xorinzor
路
4Comments
Most helpful comment
I can go in more detail for what its worth.
Part of the process in moving to Vue. Just work. The more we move to vue the smaller the vendor file will become. But with that part of it will be added as vue components of course.
Not an expert on webpack myself. But as i understand, moving to a single webpacked SPA will improve this.
Not very far. Each mako template needs to be refactored to vue. So step 1 is remove the mako variables and replace them with vue templating. Then step 2 is refactoring the mako to a pure .vue file. And moving it into
/themes-default/slim/src/componentsand make it part of Vue Router. From looking at src/components you can see that only:have been transitioned.
You see that some don't have a tag. So those aren't fully transitioned. As they are combined (through a hack) with a mako template.
I also created a list of the highest prio todo's here: #4765
You are right. This is because someone started changing this to vue. But stopped half way in the process. It's also bothering me. We use vuex for state management. And the goal is to build up initially the state with the apiv2 calls. Then update it through websockets through events from server side. Obviously the mako is to be removed.
Yes the old api v1 polling should eventually be replaced by websockets. The same as how we plan to update the "state".
Only one theme is served. The build scripts have already been adjusted to build a dark and light theme from the /themes-default/slim theme. So in terms of performance this isn't really an issue right now.