Nativefier: Responsiveness has deteriorated

[berry]

Responsiveness has deteriorated

I am sorry this a somewhat vague description of the issue I am experiencing. I have nativefied Gmail. In a previous version of nativefier it worked flawlessly. Switching between apps on OS X and coming out of sleep mode... and my Nativefied Gmail responded quickly. Now in version 6.13.0 this is not the case anymore. When coming out of sleep mode, it takes dozens of seconds before I can use Gmail. Clicking on tabs and e-mails within Gmail always has a lag of something like a second. This wasn't the case before.

Steps to Reproduce Issue

See above.

Specifications

• Version of Nativefier (run $ nativefier --version): v6.13.0
• Version of Node.js (run $ node --version): v0.12.7
• OS: Mac OS X 10.11.4

[joeyvandijk]

I have to say that I do not experience this lag when I have 1 app open made with node-nativefier. But I do when I have 4 apps open that are made with node-nativefier. Can it be caused by shared memory / resources in Electron when having multiple created apps open?

[berry]

Exactly! I have made one Nativefier app for GMail, one for Google Drive and then I also have the Slack app (also an Electron app). I regularly have to kill apps and restart them again to get to be responsive again. I mailed to Slack support... they admitted that the Slack app has some memory leaks and they are working on it. But, does a memory leak in Slack effect other Electron apps?

[joeyvandijk]

I used Gmail twice (personal + business), hangouts and asana but previously
it worked fine but one of the last releases of node-nativefier or electron
has broken something. But "something" is the annoying part not knowing
where to start looking.
On May 2, 2016 11:21, "Berry" [email protected] wrote:

Exactly! I have made one Nativefier app for GMail, one for Google Drive and
then I also have the Slack app (also an Electron app). I regularly have to
kill apps and restart them again to get to be responsive again. I mailed to
Slack support... they admitted that the Slack app has some memory leaks and
they are working on it. But, does a memory leak in Slack effect other
Electron apps?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/jiahaog/nativefier/issues/191#issuecomment-216168583

[lexelby]

I'm also seeing this problem, also with multiple electron-based apps running simultaneously. At first, each app is plenty fast and responsive. But after an hour or so, they bog down until I press ctrl-R to reload. I've nativefied gmail Inbox, hipchat, and hangouts, and I also have spotify and sometimes slack running. I'm running in Linux.

When I enable developer tools in one of my nativefied apps and check the profiler tab, the majority of the time is listed under "(program)". Not sure what that means.

[lexelby]

I suspect this commit: https://github.com/jiahaog/nativefier/commit/eeb661b6cd82a3f21f5adbf0d1389cf2804fd16b

I can see in my javascript console that the css is being injected over and over. I think the CSS is piling up on each XMLHttpRequest (rather than replacing each time) and giving the browser too much work to do.

[lexelby]

@berry @joeyvandijk Please give my development branch a try: https://github.com/lexelby/nativefier/tree/development

Note that I also threw in a commit that changes how nativefier decides which links to open in an external browser. Feel free to revert if you don't like that.

For info on how to test my branch, look here: https://github.com/jiahaog/nativefier/blob/development/docs/development.md

[berry]

Hi @lexelby,

I installed your dev branche. Till now everything "feels" allright. Time will tell. I will report back later.

[lexelby]

Thanks! I've also got it running -- should know for sure whether it helps within a couple of hours.

[lexelby]

I'm quite sure that fixed the problem. I'm not sure what to do about the "flash of unstyled content" that the above commit supposedly fixed, but I don't see it.

[berry]

I have been working with your dev branch and every thing keeps running very smoothly. It indeed seems to solve the problem. Hopefully, this fix will be merged soon ;-)

[jiahaog]

Yup, thank you @lexelby for the fix!

[joeyvandijk]

Works for me too after working with it 1 day and 3 different nativefied apps, so great & thanks!

[lexelby]

Yay!

[joeyvandijk]

I presume something has been wrongly merged or not updated, while I am seeing again deteriorated responsiveness when using multiple windows when using nativefier v7. @lexelby @jiahaog any ideas what went wrong with the new release (v7)?

[denisbr]

Yes, with nativefier v7 and different Electron versions, the resulting app-bundles are unusable.
I suggest re-opening this issue.
Examples of apps that are super slow:
https://inbox.google.com (built with only the URL and an icon parameter, both latest and Electron 0.37.2 as an attempt at fixing it)
https://gmail.com (again built with no special params)

[denisbr]

I reverted this https://github.com/jiahaog/nativefier/commit/c3ae29a0ead409b7847417df0e2b2ff193615bfa
but after testing, both problem apps are still very slow. If anything they seem to be slightly more responsive initially, and then deteriorate quickly into a sluggish mess.

[jiahaog]

Sorry for the delay in checking this out! I've realised that the injection of css triggers after every ajax response, which really slows down performance of the page. I've added #214 which appears to fix the issue, please check out the commit and let me know if it persists, or I'll merge it in soon if all is well!

[denisbr]

@jiahaog Thanks! The commit seems to improve performance indeed. If I notice gradual degradation during the day I'll report back.

[denisbr]

I'm afraid Google Inbox is still acting up and being extremely slow. Initial load and first few email views were ok, then when returning to it it's sluggish again.
Anything I can do to provide useful debug information for you?

[eladnava]

Just tried generating a YouTube app using the fix/performance-issues branch but unfortunately the performance issues are still there, mostly when scrolling the page down / hovering over the seek bar of the currently-playing YouTube video.

[jiahaog]

@denisbr @eladnava Hmm, are you all building the app with the --inject flag?

[eladnava]

@jiahaog Nope, what am I supposed to be injecting? I'm simply trying to use Nativefier with YouTube and experiencing performance issues:

nativefier www.youtube.com

[jiahaog]

I can't seem to reproduce this with inbox or youtube on the new branch... I believe the problem could be due to the CSS being repeatedly injected, but I've coded it such that if the --inject flag is not passed, the necessary callbacks which seem to cause the performance issues are not set. Could you try and see if there are any differences with and without setting the --inject flag to some random css file?

[eladnava]

@jiahaog I hadn't passed the --inject flag at all and still got the performance issues (4 days ago). Performance issues are noticeable after the app runs for a long time (e.g. a few hours or a day).

[jiahaog]

Hmm, the performance issues are not showing up for me on youtube when I play a video on #214. Could @denisbr @eladnava could you provide me with the following:

Specifications

Version of Nativefier (run $ nativefier --version):
Version of Node.js (run $ node --version):
OS:

I've also updated #214 with some debug statements. Could you also try building a page for a problematic website and providing me with the output in the developer console? (accessible from the app menu)

[eladnava]

@jiahaog Excellent news!

Maybe I built nativefier incorrectly last time I checked, but I just tried again and it appears that all performance issues are gone for me!

Tested on YouTube, Google Keep, Inbox, Google Photos, and WhatsApp Web. No more janky scrolling / bad FPS!

These are the commands I ran this time to build an app using the fix/performance-issues branch:

# Delete old versions
npm uninstall -g nativefier

# Clone and build
git clone https://github.com/jiahaog/nativefier.git
cd nativefier
git checkout fix/performance-issues 
npm run dev-up
npm link

# Generate the app
nativefier www.youtube.com

Can anyone else who experienced performance issues run these commands and check whether they're fixed for them as well?

Here are my system specs, in case that helps in any way:

• Version of Nativefier (run $ nativefier --version): v7.0.0
• Version of Node.js (run $ node --version): v4.4.5
• OS: OS X El Capitan
• Architecture x64

Thanks again for solving this @jiahaog!

[denisbr]

Hi, sorry for not replying earlier, but we're in the middle of a massive move.
I've rebuilt nativefier like @eladnava suggested above, and rebuilt my app-bundles. I'll report back after using them for a while.

• Version of Nativefier (run $ nativefier --version): v7.0.0
• Version of Node.js (run $ node --version): v6.2.0
• OS: OS X El Capitan 10.11.5 (15F34)
• Architecture x64

[eladnava]

Just wanted to report that after 15 hours of using the apps, I can confirm that the performance issues have definitely been fixed (at least for me) 😄

[denisbr]

I can add to this now, after having used my nativefied Inbox and other apps for a couple of days, responsiveness seems good! 👍

[jiahaog]

Alright awesome, thanks!

[jiahaog]

I've pushed the fix in 7.0.1!

[eladnava]

You rock! 😎

[lexelby]

@jiahaog
This still injects the CSS many times. If there are any Ajax calls before did-finish-load, then each one results in a new copy of the CSS being injected. Lots of CSS piling up is what caused the performance degradation since each copy of the rule has to be evaluated on every DOM change. In my test, the current version injects the CSS 38 times before Slack loads.

Here's a way that seems to successfully inject CSS (using injected JS) once without performance issues:

var injectedCSS = `
html {
    font-size: 22px !important;
}

.channels_list_holder ul li a {
    padding: 0 0.25rem 0 0.2rem !important;
}

a.channel_name, a.im_name {
    font-size: 19px !important;
}

#quick_switcher_label {
    font-size: 18px !important;
}
`;

$("<style></style>").appendTo("head").html(injectedCSS);

I don't see a FOUC with this, but then again I've never seen the FOUC, so someone else will have to test.

Credit to this page for the injection JS: http://blog.lacour.me/making-slack-night-mode

[jiahaog]

@lexelby You're absolutely right, the current implementation is a simply a sufficient (if mediocre) workaround to deal with the FOUC.

Having said that, the FOUC only occurs for less than a second, and is more noticeable when you apply styles that change the layout of the content. Could you try something like

* {
    font-size: 50px
}

and see if this implementation of adding the css to the head prevents the FOUC? Thank you so much!

[lexelby]

As far as I can tell, I _think_ the FOUC is avoided. I ended up using your test but with !important to override any styles of the page under test.

I modified my JS to look like this, because otherwise it won't work on pages without jquery loaded:

var style = document.createElement("STYLE");
style.innerHTML = injectedCSS;
document.getElementsByTagName('head')[0].appendChild(style);

With that, I don't get a FOUC at all.

I guess we'd probably need to make this a bit more robust by adding a head tag if one doesn't already exist.