Python 3.15 lazy imports cut a 512 ms cold start to 32 ms on the route that skips boto3

The 16x figure ^[5] is the startup cost of imports the health route never used. Under eager loading, Python pulled in 551 modules that path never touched before returning its JSON body ^[6]. Lazy loading took 480 ms off that route ^[20]. The two heaviest libraries, boto3 and SQLAlchemy, add up to about 365 ms in the post's import profile. That is roughly 71% of the eager 512 ms ^[22].

The /s3 route is the figure for a request that does real work. It saved 253 ms, a 41% cut or about 1.7x ^[21]. All of that came from the four libraries the route never loads, and it still pays for boto3 ^[8]. The author wrote: "Lazy imports move the cost to the first use. They do not delete it." ^[9]

For the 16x to carry over to a serverless cold start, the first request a fresh process handles has to stay off the heavy imports. Health checks benchmark well because they do almost nothing. We'd expect a function whose cold processes first serve a probe or a light route to land near the 32 ms row. A function whose first request calls S3 should land near the 361 ms row, with boto3 loading on that request ^[9]. The post timed a container ^[4]. It did not test a hosted function runtime or report billing.

Beyond the per-import keyword ^[19], the post documents a global switch. Setting `python -X lazy_imports=all` or `PYTHON_LAZY_IMPORTS=all` makes every import lazy, and `sys.get_lazy_imports()` then returns "all" ^[10]. Pairing that with `sys.set_lazy_imports_filter()` keeps chosen modules eager: the filter is consulted only for imports that would be lazy, and a False return holds the module eager ^[13]. The modules to hold back are the ones whose import does work. Plugin registration, model registries, monkeypatching and logging configuration done at import time will not run until something touches the module ^[15]. Of the global mode, the author wrote: "Good for an experiment in staging, risky as a default on day one." ^[11] Two forms cannot be lazy at all. `lazy from x import *` and `lazy from __future__ import ...` are syntax errors ^[16].

In our view the keyword is the right place to start. Each lazy line is explicit and shows up in code review ^[19]. On this handler, two of the five lines cover most of the measured import time ^[22]. Whether the work justifies its own budget line depends on how often a cold process's first request lands on a light route.