Visit the new site! Link Search Menu Expand Document

Optimizing Addon Performance

This page was compiled primarily using community feedback from multiple sources. As a result, some information may be generalized, subjective, or conflicting. Always use your own best judgement when optimizing your addons. This page is not a substitute for testing your addon on a wide range of devices.

Table of contents
  1. Optimizing Addon Performance
  2. Performance Cost by Subsystem
    1. Biomes and Features
      1. Biomes
      2. Features
    2. Blocks
      1. Materials
      2. Quantity and Type
      3. Updates
    3. Commands
      1. Quantity and Type
      2. Selectors
      3. Tags vs. Scoreboards
    4. Entities
      1. Components
      2. Dummy Entities
      3. Geometry
        1. Bones
        2. Elements
      4. Materials
      5. Quantity
    5. Lighting
      1. Map Considerations
      2. Sources
        1. Comparison Table
    6. Molang
      1. Recursion
      2. Structs
      3. Variables
    7. Textures
      1. Quantity
      2. Resolution
    8. Sounds
      1. Count
      2. Compression
      3. Streaming
    9. Redstone
      1. Chunk Boundaries
      2. Command Blocks
    10. Ticking Areas

Performance in addons is particularly important, as the most technically impressive addon is largely useless if the majority of the player base cannot experience it. When developing addons, it should always be considered that many Bedrock players will be experiencing your addon on a significantly lower power device than you are developing on. This is especially true for mobile users. Therefore, addons should be developed with performance in mind, and tested for performance on lower end devices when possible.

This guide is a non-exhaustive list of specific performance considerations separated by the various subsystems of Bedrock Edition. No single point should be taken as a hard and fast rule. Rather, these performance considerations should help you to recognize potential areas for improvement.

Performance Cost by Subsystem

Biomes and Features


  • The biome system is generally efficient
  • Large values for heightmaps are usually handled gracefully
  • The component climate creates large particle storms


  • Biomes generally cause less lag than feature generation
  • Hundreds of iterations per chunk of a multi-block feature have been achieved at low performance cost
  • Thousands of iterations per chunk of multi-block features negatively impact gameplay
  • Hundreds of thousands of iterations per chunk of a single-block feature have been achieved at low performance cost



  • The minimum needed material type with regards to rendering should always be utilized
    • alpha_blend performance is worse than alpha_test, which is worse than opaque

Quantity and Type

  • Flowing liquids should be avoided and minimized


  • Block updates should be minimized


Quantity and Type

  • Minimize the number of commands run per tick
    • /effect and /gamemode run every tick are avoidable and have a major performance impact
  • Large clones and fills during runtime should be avoided
    • Breaking these larger operations into multiple commands distributed over multiple ticks will avoid lag spikes


  • Care should be taken to ensure a function is not executed on too many entities, and therefore too many times
  • Executing a scoreboard command outweighs the cost of running an entity selector multiple times
  • Using c=1 to ensure the selector stops when it finds one entity may improve performance
  • When executing multiple commands with the same selector, use a function instead to avoid repeatedly resolving the same selector

Tags vs. Scoreboards

  • Scoreboards perform better at a large scale than tags


  • Entities generally have one of the largest performance impacts by subsystem, and thus should be minimized where possible


  • Pathfinding on flying mobs has a significant performance cost
  • Flying mobs in general encounter performance problems
    • Faking flying mobs via animation should be considered if possible

Dummy Entities

  • Dummy entities generally have equal performance impact to proper entities, except when excluding heavy components like pathfinding



  • No performance impact has been observed regarding bone count


  • Element count is not generally an issue, except in extreme cases when thousands of elements are reached


  • The minimum material required to achieve a desired effect to should always be used
  • When in doubt, refer to the material definition files to get an idea of the costs of various materials, taking the material inheritance system into account


  • Loaded entities at any given time should be minimized
    • Below 30 is optimal


Map Considerations

  • Hollow areas will cause lag due to lighting calculations
    • Avoid this by filling in unused enclosed areas
  • Keeping the map set to day or night will avoid lighting recalculation


  • Bedrock lighting is calculated dynamically, meaning different light sources have different performance costs
    • Light blocks are the most performant because they lack particles, rendering, and special state logic
    • Torches are the least performance because they emit particles, render, and have special state logic dependent on what block they connect to
    • Custom light blocks with minimal components are a reasonable compromise between performance and aesthetics

Comparison Table

Light Source Score Redstone Updates Animted Texture Light Updates Tick Updates Particles Renders
Light Blocks 1 False False True False False False
Lanterns 4 False True True True False True
Custom Blocks 2 False False True False False True
Mushrooms 3 False False True True False True
Redstone Lamps 3 True False True False False True
Glowstone 3 True False True True False True
Sea Lanterns 4 False True True True False True
Torches 4 False False True True True True
Redstone Torches 5 True False True True True True



  • Minimize use of recursion when possible
  • Especially deep nested loop structures will cause performance issues
  • Use break to escape loops when possible


  • Avoid making structs too deep, as there is a performance cost with each layer


  • Use temp variables when possible to minimize variables loaded in memory
  • Consider how often variables are calculated based on script type



  • No more than 3000 textures should be used
    • This is due to limits imposed by Render Dragon
    • Render Dragon has a 4096 texture quantity limit, and there are 800 vanilla textures as of 1.16


  • The maximum texture resolution is 16384x16384
  • The recommended maximum texture resolution is 4096x4096 to maintain compatibility with low end devices
  • Keep in mind that textures are atlased, and larger textures can mess with atlas generation on lower end devices
  • Only make textures as large as needed to convey the detail needed at the needed distance



  • Total registered sounds are reported to have an impact on performance


  • Sound compression is extremely beneficial to pack size
  • This is especially noticeable on older and low power devices, such as the Switch
  • The FMod simple API utilized by Bedrock decompresses all sounds into WAV before loading into RAM, meaning no CPU performance improvement in this respect
    • If audio is streamed, this does not occur


  • As general guidance, sounds over 500kb in size or 1 minute in length should be streamed


Chunk Boundaries

  • Crossing chunk boundaries with redstone should be avoided

Command Blocks

  • When creating large command block chains, stack vertically and in a single chunk
  • Minimize command block use in favor of functions and behaviors where possible

Ticking Areas

  • Total chunks is of greater concern than ticking areas
  • Dynamic areas should be avoided unless necessary
  • Best practice is minimizing the ticking area to one chunk if possible
    • All always-on redstone should fit in this ticking chunk
  • Unload ticking areas when they are no longer needed, testing via /testforblock