Pug Template Compilation Caching in Express Serverless Functions: Cold-Start vs Warm-Invocation Trade-offs

Answer to the Core Questions

1. Re‑using a pre‑compiled function from app.locals or res.locals?

Express’s app.render will always invoke the internal Pug compiler unless the cache:true option is enabled. The compiler looks up a global pug.cache object keyed by the template path. A function you attach to app.locals or res.locals is never consulted by the view engine, so the template will still be re‑compiled on the first render.

2. Scope of the compiled function when cache:true is set?

The cached function lives in the process‑wide pug.cache object. All concurrent invocations that share the same container instance see the same cache entry, so a subsequent request in the same instance is a cache hit. The cache is not per‑request.

3. Supported warm‑up pattern?

Yes. A dedicated “warm‑up” handler that renders every template (or calls pug.compileFile for each file) can populate the cache before real traffic arrives. Because the cache is per‑process, the first real request after the warm‑up will hit the cache and avoid recompilation.

Practical Steps for a Serverless Express Deployment

1. Enable caching in your Express setup:

   app.set('view engine', 'pug');
   app.set('views', path.join(__dirname, 'views'));
   // Express 4.x
   app.set('view cache', true);
   // Express 5.x – optional, but shows the object form
   app.set('view', { cache: true });
   

2. Pre‑compile the most frequently used templates at module load (optional but reduces the first‑render cost before the cache is hit):

   const pug = require('pug');
   const compiledHome = pug.compileFile('views/home.pug');
   app.locals.compiledHome = compiledHome;
   

   Note: this step is only a micro‑optimization; the view engine will still call pug.compile unless cache:true is set.

3. Create a warm‑up route that renders each template once:

   app.get('/warmup', (req, res) => {
     const templates = ['home', 'about', 'contact'];
     templates.forEach(name => {
       res.render(name, {}); // renders and stores in cache
     });
     res.send('Warm‑up complete');
   });
   

   Deploy the function and invoke /warmup immediately after deployment or when you know the container will stay warm.

4. Measure the benefit:

   • Invoke a real request before warm‑up and log the time.
   • Invoke the same request after warm‑up and compare.
   • Optionally, inspect pug.cache after rendering: console.log(Object.keys(pug.cache));

5. Handle template updates:

   • If you deploy a new version of a template, clear the cache entry: delete pug.cache[templatePath];
   • Or restart the container (most serverless runtimes do this automatically on deploy).

Assumptions & Caveats

• These insights are based on Express 4.x and 5.x behavior; confirm against your exact version.
• Serverless runtimes that do not preserve the Node.js process between invocations (e.g., some Azure Functions configurations) will not retain the cache across cold starts.
• Large template sets can increase memory usage on cold start; monitor process.memoryUsage() if cost is a concern.
• If you need to serve dynamic content that changes often, consider invalidating the cache after a set period.

Diagnostic Question

Could you confirm which Express major version you’re using? The app.set('view cache', true) syntax differs slightly between 4.x and 5.x and may affect the exact cache keying mechanism.