Two numbers to count before you add another node

The editing surface does not show cost

Connecting nodes feels uniform in weight. In the compiled result, work that runs per fragment and work computed once are completely different costs, and on mobile the fragment side is usually what hurts.

Two numbers to count: how many times the fragment reads a texture, and how many variants this graph compiles into.

Procedural patterns are not cheaper than textures

Building noise or a repeating pattern from nodes looks light because it ships no texture. In practice it becomes a function evaluated per pixel, and it frequently costs more than one texture read. Baking it into a texture usually wins.

1. Mark the fragment nodes that apply across the whole screen.
2. Find the ones that do not change over time.
3. Bake those into a texture.

One keyword is a factor of two

Each keyword doubles the combinations. Two is four times, three is eight. That number shows up directly in build size and in the hitch at first use.

// Before adding a keyword, look at how many you already have
// Read the variant count in the inspector, then compile for the real target
#pragma multi_compile _ _RIM_ON
#pragma multi_compile _ _DISSOLVE_ON   // already four times
[Compile] target GLES3: 96 variants
[Compile] target Vulkan: 96 variants
[Warn]    first draw compiled a variant at runtime

Expected result and next step

Knowing the variant count and being able to justify it finishes this stage. If you cannot justify it, trade keywords for separate materials. Warming variants to remove the first hitch gets its own post.