Any up-to-date performance best-practices?

Is there anything like this for web-extensions?
https://developer.mozilla.org/en-US/Add-ons/Performance_best_practices_in_extensions

And is there any way to measure an add-ons performance?
I found this article:
https://blog.mozilla.org/addons/2011/04/01/improving-add-on-performance/
Which leads to this add-on, which is four years out-of date:
https://addons.mozilla.org/en-US/firefox/addon/about-startup/

Do you guys have any experiences of what makes add-ons slower? (except dom-mutation listeners and mouse-motion listeners)

Info: My add-on uses content-scripts on every page, as it supports translating text using certain mouse-actions. Also, I haven’t noticed any performance issues, but some of my users said it slowed firefox down (not sure if it was fixed with the web-extension port though).

For example, I’m really interested if these hurt performance:

  • I add multiple content-scripts to my page (some libraries are in separated into different files)
    – Also, each of these js files has a license in the header
    – Will firefox compile and cache them once or will they be parsed on every page-load?
    – So could I improve performance by compiling my content-scripts into one compressed file with no comments?
  • I always load all of these content-scripts when a page is loaded, as I have no idea how to load files delayed… would it help to wait for the mouse-action before I load the other js files?
  • could it help to move functionality to the background-script (if possible) and use sendMessage instead?

This is the current state of my web-extension port:
https://github.com/Lusito/dict.cc-translation/tree/feature/web-extension

Any hints on improving the performance of my add-on are very much appreciated.

2 Likes

I think it is a bit early to tell. Firefox currently hosts WebExtensions in the main process, but plans to move them in their own processes the same way chrome does it. And chrome it is pretty hard to write slow stuff. Here is an example:

I have an add-on working on YouTube. Its primary functionality is to queue the playback of the videos in all open tabs. And it also does quite some DOM manipulation and adds custom CSS and event handlers.
In total, that is around 7k lines of code across 30 files in the background and 5k lines in 25 files for each tab as content script.
Restarting the add-on, that is, removing all event listeners, CSS, and DOM-nodes in the tabs, unloading the background page, loading the background page, calling tabs.executeScript() for all files and tabs, awaiting their load (attaching listeners, requesting data from the indexedDB in the background, adding DOM-Nodes, inserting styles, attaching to and pausing the YouTube player, reporting the current video to the background page) and displaying the open videos in an interactive playlist takes less than 10 seconds. With more than 100 open Tabs. If I only have a single tab open it is literally to quick to take the time.

So what I am saying is, you can hardly add too many content script in chrome. It’s fast anyway.

Doing the same in Firefox 54 takes more than two minutes.

While this certainly isn’t representative for Firefox’s overall speed it demonstrates that it really makes a big difference whether you have a seperate extension process and 100 content processes or the extension running in the browser process and only a single content process.

So unless there are massive performance problems, just wait for Firefox to roll out multiple content and extension processes and see if that helps.

1 Like