[Webapp] Slow load - Githubissues

fgeorgsson commented 8 years ago

The initial load of the webapp is slow. Sometimes it does not even complete the first time, forcing you to reload the page manually. It usually works well after the first completed load due to partial caching.

Browsers do not load more than 4 - 10 resources concurrently which is the main problem. For me loading the dashboard makes 243 request, transfers 6.0 MB and finishes DOM at 12.70 seconds and load at 14.50 seconds.

Second load with caching on still takes 12 seconds or so to load. Only images seems to be fetched from cache.

There are also multiple failed requests for translation files, since the browser language/locale might not match the supported locale of different components. For me the browsers states 'sv', but most components have 'sv-SE' translation files.

Easy things to do:

Enable caching of css and js files (not done now, only for images?).
Enable gzip compression - on slow wifi connections this will help reduce the payload size substantially. Might be slower on good wifi and slow servers (like Pis?).

Harder things to do, but still pretty easy:

Build the webapp with webpack or browserify into at most a handful of js-files.
Bundle css-files into one or a few files (sass/less or something like gulp concat?).
Concat icons into a sprite sheet (something like https://www.npmjs.com/package/node-spritesheet?).

We would have to introduce a dev dependency on Nodejs and npm if it isn't required already. Wouldn't be needed for runtime.

Reported issues that might be related: http://www.homegenie.it/forum/index.php?topic=1478.0 http://www.homegenie.it/forum/index.php?topic=1512.0

Would you accept pull requests for these features? Build step would become more complicated to maintain, so I would definitely understand a nay.

genemars commented 8 years ago

I would accept PR. You can work on the branch ui-rework for the part that is related to HG. Other web server stuff could be implemented in mig-service project. Caching should already work for css and js as well so it must be a bug. Gzip compression is a good thing to start from I guess. Not sure how you would use nodejs and npm though. Also keep in mind that if the project get the required attention from people, I would rewrite the whole homegenie ui from scratch using more modern/lighter frameworks than jquery-mobile.

genemars commented 8 years ago

- Enable caching of css and js files (not done now, only for images?)

this is fixed now.

fgeorgsson commented 8 years ago

Allright, yes a rewrite is always fun if time and money allows. :) I will go for the low hanging fruit then, js and css optimizations. Icon spritesheet seems like more work, will skip that I think.

Not sure either how I will use node/npm, will keep in touch with progress. I code on Windows, so would start with that. Have access to Linux and OSX too so will add support for that too before submitting pull request.

Developers would have to install node and npm for the build process to work.

genemars commented 8 years ago

dunno anything about node too... so I feel like to suggest to preferably try to make without it. :D

Bounz commented 8 years ago

In the work project we are using npm with gulp for bundling and minification of js and css files in production. All npm modules are incuded into the repo, so team members don't need to configure enviroment except Task Runner Explorer extension which simplifies launching gulp tasks from VS and also allows to run them automatically in case any watched js/css file changed. I think this is a good idea to bundle and minify js and css, but please don't forget about source maps for js. Without them it's almost impossible to debug js in browser.

fgeorgsson commented 8 years ago

I looked at various options and I concur, gulp is the best option for this project. I have the app running with a single bundle.js file now in local branch. This was really easy to do. Will push to my fork when my kid is sleeping later. :)

Load time is down from 12 to 9 seconds on my machine with this change alone.

Some things left

Debuggability/fetching of 3rd party libs

Currently libs like jquery are checked into git. Often only the minified versions. I would like us not to have these files checked in at all. Prefferably we use non-minified versions instead and minify our bundle in the end only for release builds. Debug buikds would be friendlier to debug that way than now. Either we go with npm or bower. I will try using npm only. This would change css/image paths, and copy to output method. Requires more work.

Copy build to Homegenie ouput folder

Visual studio handles that now. Each file has property to "copy file if newer" or not. I want to remove that alltogether and make it work the same for all dev platforms. I don't want the bundle js/css files to be checked into git for VS to be able to copy them. So we will run a gulp task that creates bundle.js, bundle.css, then copies them, index.html, and images to homegenie/bin debug/release depending on build target in VS. For debug builds we add sourcemaps, for release we minify without sourcemaps. Does that seem ok?

Licensing

Do we need to copy any individual 3rd party package license files to the webapp output folder, or attribute in about dialog? Since we will stop copying the 3rd party folders in their entirety to the output folder we need to know for sure what licenses we use.

CSS bundling

I am currently testing out gulp-css-rebase-urls to be able to rewrite relative urls to match /css/bundle.css. That should make it possible to have a single css file even though the css sources have different relative roots and relative urls to images/fonts.

Making progress. Den 18 apr 2016 09:40 skrev "Alexander Sidorenko" <notifications@github.com

:

In the work project we are using npm with gulp for bundling and minification of js and css files in production. All npm modules are incuded into the repo, so team members don't need to configure enviroment except Task Runner Explorer extension which simplifies launching gulp tasks from VS and also allows to run them automatically in case any watched js/css file changed. I think this is a good idea to bundle and minify js and css, but please don't forget about source maps for js. Without them it's almost impossible to debug js in browser.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/genielabs/HomeGenie/issues/269#issuecomment-211245519

fgeorgsson commented 8 years ago

Bundling CSS brought down DOMContentLoaded to 5-6 seconds. Everything still works like before.

fgeorgsson commented 8 years ago

Still work in progress. You can view the branch here. https://github.com/pcguru/HomeGenie/tree/ui-rework-js-and-css

Comparison https://github.com/genielabs/HomeGenie/compare/ui-rework...pcguru:ui-rework-js-and-css?expand=1

genemars commented 8 years ago

cool, does the developer have to manually install external dependencies or tools to compile/debug the solution?

fgeorgsson commented 8 years ago

Yes, a develper has to have Node.js installed from https://nodejs.org/en/.

The pre-build step will install the necessary node modules and output the bundle css and js files.

cd $(ProjectDir)html
npm install
npm run build

Bounz commented 8 years ago

At work we have npm with all modules checked in repository alongside other packages. This makes it possible to run gulp scripts on the build server without installing npm, so our PreBuildEvent looks like

<PreBuildEvent>
call $(SolutionDir)packages\nodejs\npm install $(ProjectDir)
call $(SolutionDir)packages\nodejs\node.exe $(ProjectDir)node_modules\gulp\bin\gulp.js -b  $(ProjectDir) --gulpfile  $(ProjectDir)gulpfile.js clean:js
call $(SolutionDir)packages\nodejs\node.exe $(ProjectDir)node_modules\gulp\bin\gulp.js -b $(ProjectDir) --gulpfile  $(ProjectDir)gulpfile.js bundle:all
</PreBuildEvent>

I think it may be possible to include different npm binaries for each platform (Windows, Linux, Mac) into the repo. I'll try to do this for Mac.

fgeorgsson commented 8 years ago

@Bounz I appreciate the effectiveness on build servers, to include the node_modules directory in git (both build speed and reducing used bandwidth etc if you wipe the machine on each build). But git history becomes a bit polluted with node_module updates? And modules that are compiled (node-gyp) dump their binary files into their source folders sometimes. How do you know which files to gitignore? Most packages have their own .gitignore that ignores the build files sure, but some do not? Having files turning up as changed if a dev is on another platform than the last commiter isn't very nice. :D

Btw couldn't you use npm rebuild instead of npm install in your pre-build event? That way you won't use the Internet at all?

Putting call in front of the lines solved the problem @Bounz, sweet thank you! I've pushed a new version. The old link for comparison works.

Bounz commented 8 years ago

@pcguru Yes, I agree that including npm with modules pollutes the repository. Using npm install when all packages and their dependencies are already in repo will not trigger npm to use internet. May be in this case it's easier to engage each developer to install npm, than including it into the repo and configuring for 3 different platforms.

genemars commented 8 years ago

Have a look at r520

https://github.com/genielabs/HomeGenie/releases/tag/v1.1-beta.520

genemars commented 7 years ago

it's almost past one year, anyway expect a 'homegenie-ui' repo soon. The core of the new UI will be https://github.com/genielabs/zuix which is mostly based on current hg ui library, so hopefully the code 'migration' will not be too hard. It will be using Material Design Lite in place of jQuery-Mobile.

davidwallis commented 7 years ago

Gene, Bounz - A hg ui rewrite sounds like an ideal opportunity to get Appveyor building this and running any NPM build / optimisations that could be achieved?

(assuming the new framework can still benefit from this?)

Cheers

David

genielabs / HomeGenie

[Webapp] Slow load #269