Advanced: Mod Performance Tuning

Key Concepts

Secure Sandbox

PixieBrix executes text templates and Javascript code in a secure sandbox embedded in the browser extension's offscreen document:

Content Script → Offscreen Document → Sandboxed Iframe → Offscreen Document → Content Script

Messaging the sandbox introduces CPU and memory overhead to serialize/deserialize data across the messenger boundaries.

Best Practices and Tips

Prefer variable expressions over text templates

Variable expressions, e.g., @foo.bar or @mod.myModVar?.someProperty, do not require a call to the sandbox because they do not require code execution.

Merge sequential Run JavaScript Function bricks into a single brick

Each call to Run JavaScript Function requires a call to the sandbox. If you have multiple Run JavaScript Function bricks in a sequence, consider rewriting using a single brick that returns an object with properties.

Avoid passing extraneous data to the Run JavaScript Function brick

Where possible, use variable expressions to select data to pass to the Run JavaScript Function brick:

Remove unused brick output variables

When evaluating text templates, PixieBrix passes all available variables. Therefore, to reduce data transferred to the sandbox, remove unused Output Variables:

Use nesting when operating on large data that's not required by subsequent bricks

When evaluating text templates, PixieBrix passes all available variables. If you read a large value, that value is seen by subsequent bricks at the same scope-level.

To performantly operate on a large value in the middle of mod component, nest it using the Run Bricks brick (or other control flow brick, e.g., Try-Catch). The subsequent bricks will only see the data returned from the control flow brick.

As an alternative to using nested control flow, you can overwrite the value of the variable by assigning a brick output to the same variable name.

Use the "Get shared page state" brick to efficiently select subsets of mod variables

When evaluating a text template with a @mod reference, PixieBrix transfer all mod variable state to the sandbox. That's inefficient when working with large mod variable states.

To reduce the data transmitted, use the "Get shared page state" brick to take a snapshot of a subset of mod variables, and assign them to a local variable:

Toggle off non-event data for Trigger input for rapid triggers and/or heavy-weight pages

By default, PixieBrix includes element data in the @input variable for bricks. This includes data about the target element, e.g., which for Page Load and similar triggers is the entire document. For heavy pages, that can be a lot of data/information.

Therefore, for rapid triggers and/or triggers that might run on heavy-weight pages, toggle of the default input data in the Trigger configuration:

If you need the URL or other page metadata that's generally provided in the @input, add the Context reader brick.

Avoid inefficient button location and Trigger selectors

PixieBrix supports jQuery extensions for ease of automation. However, the jQuery selector extensions not supported by native web APIs, e.g., the MutationObserver API. The PixieBrix Page Editor will warn you when using a non-native selector for a button location or trigger, for example: :contains , that will prevent native web APIs from being used.

Follow best practices for writing performant CSS3 selectors