Stop Your APIs From Sucking at Cold Starts

Cold starts mean your API is basically dead in the water for the first few seconds. No persistent processes, no warm servers - just you, Lambda, and the sound of users bouncing while AWS decides to wake up your function.

Every time Lambda downloads 600KB of Express garbage, I lose money and patience. Hono's 12KB isn't just a nice-to-have - it's the difference between a usable API and watching users bail during that painful first request.

Bundle Size Impact on Cold Starts

These numbers are from actual production deployments, not synthetic benchmarks:

• Cloudflare Workers: Hono ~100ms, Express 2+ seconds of pure suffering
• AWS Lambda: Hono ~500ms, Express hits 3-4 seconds (and sometimes just times out)
• Vercel Edge: Same story, different platform

Cold starts are random as hell - same function can take 200ms or 3 seconds depending on AWS's mood, your region, and whether Mercury is in retrograde. But smaller bundles consistently perform better across this chaos.

Common Cold Start Performance Killers

Here's what'll fuck your cold starts (learned the hard way):

• AWS SDK v2 - This ancient piece of shit adds 100MB. Use v3 or hate your life
• Database connections at startup - PostgreSQL pooling doesn't work in serverless. Found this out at 3am
• 128MB Lambda memory - Whoever set this default should be fired. Use 512MB-1GB or watch everything crawl
• Prisma at startup - 200MB+ schema loading killed production twice for me

GitHub issues are full of people who imported their entire ORM at the module level and wondered why Lambda timed out. Don't be that person.

Runtime Setup Options

Cloudflare Workers - Fast as hell but picky:

import { Hono } from 'hono'
import { compress } from 'hono/compress'

const app = new Hono()
app.use('*', compress())

export default app

No filesystem, no Node.js APIs, no bullshit. Perfect for APIs that just serve JSON and don't need to read files.

Bun - Benchmarks look amazing, reality is messier:

import { Hono } from 'hono'
import { serveStatic } from 'hono/bun'

const app = new Hono()
app.use('/static/*', serveStatic({ root: './public' }))

export default {
  port: 3000,
  fetch: app.fetch,
}

Bun breaks on minor version updates. Only use if you enjoy debugging mysterious runtime failures.

Node.js - Boring and reliable:

import { serve } from '@hono/node-server'
import { Hono } from 'hono'

const app = new Hono()
serve(app)

Slower startup, but shit actually works. Use this unless you have a specific reason not to.

Memory Management on Serverless

Express drags in 31 dependencies that each have their own dependency hell. Hono has zero. This shit matters more than you think.

Memory fuckups that'll kill your Lambda:

• Global variables that grow - Stored user data in global scope, OOMed after 2 hours
• Buffering 50MB responses - Tried to return a full CSV, Lambda just died
• Prisma schema loading - 200MB consumed before handling a single request

app.get('/export-data', async (c) => {
  // Don't load this shit unless you need it
  const { generateReport } = await import('./report-generator')
  
  return c.stream(async (stream) => {
    await generateReport(stream)
  })
})

Lazy imports saved my ass when CSV exports started OOMing Lambda. Load heavy shit only when you actually need it.

Router Performance Characteristics

Hono has multiple routing strategies because one size doesn't fit all. Express uses one router that gets sluggish around 100+ routes - noticed this when our admin panel started feeling like molasses.

• RegExpRouter: Default, compiles to regex patterns
• LinearRouter: Simple sequential matching for small apps
• SmartRouter: Picks the best strategy automatically

Express routing gets slower with every route you add. I saw admin dashboards with 200+ routes take 50ms just to figure out which handler to call.

Hono's routing stays consistent whether you have 10 routes or 1000. Express... doesn't.

Middleware Performance Disasters

Middleware runs in order before your route handler. Fuck up the order, fuck up your performance. Learned this when health checks started taking 200ms because auth middleware was running on everything.

// This'll kill your performance
app.use('*', authenticateUser()) // Auth runs on health checks like an idiot
app.use('*', validateRequest()) // Validation on static files? Really?

// Do this instead
app.use('/api/*', authenticateUser()) // Auth only where you need it
app.get('/health', (c) => c.text('OK')) // Health checks should be fast AF

I spent 3 days figuring out why health checks were slow - turns out auth middleware was running on everything. Don't be me.

Middleware mistakes that'll ruin your day:

• Database queries in CORS middleware (why the fuck would you do this?)
• JWT verification on public endpoints
• Parsing request bodies on GET routes

Response Streaming or Die

Tried to return a 50MB CSV once. Lambda just died with an OOM error. Streaming saved my ass and probably my job.

app.get('/export', async (c) => {
  // This'll OOM your Lambda real quick
  // const data = await loadAllData()
  // return c.json(data) // 💀
  
  // Stream that shit instead
  return c.stream(async (stream) => {
    for await (const row of getDatabaseRows()) {
      await stream.write(JSON.stringify(row) + '
')
    }
  })
})

Database Connections on Edge Are a Nightmare

Connection pooling doesn't work on edge because everything dies after each request. Found this out when production went down because I tried to use a traditional Postgres pool.

This doesn't work on edge (learned the hard way):

// Connection pools are a lie on edge
import { Pool } from 'pg'
const pool = new Pool({ max: 20 }) // This does nothing

app.get('/users', async (c) => {
  const client = await pool.connect() // Times out randomly
  const result = await client.query('SELECT * FROM users')
  client.release()
  return c.json(result.rows)
})

Use HTTP APIs instead:

// This actually works on edge
app.get('/users', async (c) => {
  const response = await fetch('https://db-api.example.com/users', {
    headers: { 'Authorization': `Bearer ${DB_TOKEN}` }
  })
  return c.json(await response.json())
})

PlanetScale, Supabase, and Turso use HTTP because TCP connections are fucked on edge. Just accept it and move on.

HTTP Caching (Don't Fuck This Up)

Caching user data globally is a great way to show Alice's profile to Bob. I've seen this happen in production and it's not pretty.

Cache this stuff all day:

// Static config data
app.get('/api/config', (c) => {
  c.header('Cache-Control', 'public, max-age=3600')
  return c.json({ version: '1.0', features: ['auth', 'api'] })
})

NEVER cache user data:

// Seriously, don't cache this
app.get('/api/profile', async (c) => {
  // c.header('Cache-Control', 'max-age=3600') // 💀 RIP privacy
  const user = await getCurrentUser(c)
  return c.json(user)
})

Performance Debugging at 3am

Timing middleware saved my ass when trying to figure out which endpoint was fucking up our response times:

app.use('*', async (c, next) => {
  const start = Date.now()
  await next()
  const ms = Date.now() - start
  
  // Only log the slow shit
  if (ms > 100) {
    console.log(`SLOW AS FUCK: ${c.req.method} ${c.req.path} - ${ms}ms`)
  }
})

Production Deployment (Where Everything Breaks)

Environment detection that actually works:

// This breaks on edge runtimes
if (process.env.NODE_ENV === 'production') { /* nope */ }

// This works everywhere
const isDev = typeof window === 'undefined' && process?.env?.NODE_ENV !== 'production'

Memory leaks that'll kill your function:

• Global arrays that never stop growing (did this once, OOMed after 4 hours)
• Event listeners you forgot to clean up
• Database connections on Node.js that never close
• Timers that keep running after requests end

// This'll OOM your function eventually
const requestLog = [] // Grows forever

app.use('*', (c, next) => {
  requestLog.push(c.req.path) // Memory leak in action
  return next()
})

If your function works fine for an hour then dies, you probably have a memory leak in global scope.