How to Read a Gas Report Before Deployment
Every student in our Gas Optimization Lab receives the same instruction on day one: do not deploy to mainnet until you can explain every line in your gas report. Here is what that means in practice.
Start with deployment cost, not execution cost
Most engineers focus on how much each function call will cost users. That matters, but deployment cost is paid once and is often larger than expected. Look at the constructor and any initialization functions first. If deployment exceeds your budget, no amount of execution optimization will help.
Identify the top three expensive functions
Sort by average gas used, not total gas. A function called rarely but expensively is less urgent than one called on every user interaction. In student projects we frequently see mapping writes inside loops — the report makes this visible as a spike in SSTORE operations.
Check storage vs computation ratio
Storage writes cost orders of magnitude more than arithmetic. If your report shows high SSTORE counts relative to ADD or MUL operations, look for opportunities to pack variables into single slots or defer writes until batch boundaries.
Ignore vanity metrics
Total gas across all test runs is misleading if your test suite does not reflect production call patterns. Weight the report by expected call frequency in your actual use case.
When to stop optimizing
We tell students to stop when further changes would sacrifice readability without meaningful savings. A 200-gas reduction on a function called once per day is not worth obscuring your access control logic.