Making it faster
Freeze the heavy nodes, author small, and stay procedural until the chain actually needs pixels.
Only what changed recooks. Editing one parameter leaves the rest of the graph cached and recomputes the affected nodes alone. Everything below follows from that.
Freeze the expensive nodes
A node whose result is no longer changing does not need to recook: a simulation you have dialled in, a one-time scatter, an imported mesh. Cycle its cook badge to F for Freeze, which pins the last cooked output and serves it regardless of input or timeline.
This is the biggest lever. A frozen node costs nothing and everything downstream still updates.
Anything time-driven recooks whenever the playhead moves, including a Particle Sim sim, Video, and animated noise. If you need only one moment of it, freeze it on the frame you like and keep working.
Cook policy covers the full set of policies and how to choose between them.
Author small, render big
There is no preview-resolution control in the viewport, so the sizes you set on the graph are the sizes that get computed. Lower the Canvas resolution, a Rasterize node's output size or a Volume's grid while you work, and raise them at the end. The export panel carries its own resolution and quality settings, so a small working size does not limit the final render.
Counts behave the same way. Rough in a Points node or a particle sim at a low count, get the look right, then raise the count at the end. Most simulation cost scales directly with the number of elements being solved.
Stay procedural until you need pixels
Points, curves, Analytic shapes and Distance Fields are cheap to edit and resolution-independent. An Analytic shape is described by maths rather than pixels, so it stays sharp at any zoom and costs little to change.
Rasterising to a Raster, rendering a Volume or committing a Field to a grid fixes the resolution, and the grid has to be recomputed whenever anything upstream changes. Push those conversions as late in the chain as they will go.
Wiring a field into something that needs pixels bakes it automatically, at a fixed size you cannot reach: the converter is spliced into a cook-local copy of the graph and never appears in it. When several nodes downstream sample the same field, put a Rasterize node in yourself. Its resolution_mode and the res_width / res_height / res_scale beneath it are the size the bake actually runs at. See Fields & sampling.
Three more Rasterize controls multiply that cost, and it is worth knowing which one you have turned up. supersample renders at N times the size before downsampling, so 2× is four times the pixels. When you wire a plane in to slice a field or a volume, samples is how many depths are read through the slab for each pixel, and projection is what is done with them; leave samples at 1 for a flat slice and raise it only once the look needs the depth. Both are per-pixel work on top of whatever the content already costs.
GPU-bound and CPU-bound
Which one you are hitting tells you what to cut.
GPU-bound, the usual case: large canvas and volume sizes, heavy rasterising, many lights, big particle counts. Fixes are lower resolution, reduced counts, simpler materials.
CPU-bound: large Collections processed element by element, heavy Expression logic on big point counts, importing or parsing big files every frame.
The The performance panel shows total frame time. To find which node is spending it, hover a node's output socket: the read-out there carries that node's cook time.
The first time a new effect appears it may stutter for a frame while the shader behind it compiles. Compiled shaders are cached on disk and survive a restart, so the cost is normally paid once per machine. That cache is budgeted at 256 MB and is pruned along with the rest of the disk tier when the machine runs short of memory, so a shader you have not used in a long time can compile again. The browser has no such cache at all, so a web export pays the full cost on every load. See Memory & budgets.
Checklist
When a graph feels sluggish:
Hover output sockets to find the node with the highest cook time.
If its result is static, freeze it with a cook policy.
Lower authored resolutions and rough in counts low.
Move any pixel conversion (rasterise, render, bake) as late in the chain as possible.
Bypass branches you are not looking at.