The very nature of guerrilla marketing thrives on surprise, agility, and operating outside conventional channels.It’s a mindset of achieving maximum impact with minimal resources, often leveraging unconventional tactics.
DIY Website Speed and Performance Fixes
Service Workers: Your Silent Performance Ally in the Zero-Sum Latency Game
Every millisecond of render-blocking time is ground you give to a competitor who already exists somewhere in the index with a faster Core Web Vitals score. Most startup marketers obsess over TTFB and image compression, but they overlook the one layer that sits directly between the user and your origin: the service worker. This JavaScript proxy isn’t just for offline PWAs any more. Deployed correctly, it becomes a tactical caching engine that rewrites the economics of request round-trips, eliminating entire network legs for repeat visits and even first load when you precache aggressively.
The core insight is that you control the cache lifecycle at a granular level that HTTP headers simply cannot express. With a service worker, you decide whether a request hits the network, resolves from local storage, or does both simultaneously. The most effective pattern for performance is stale-while-revalidate, which delivers the cached version instantly to the user while silently fetching a fresh copy in the background. This gives you the illusion of sub-zero network times for JavaScript bundles, CSS, and even HTML documents, while maintaining data freshness for API responses. Your users see a fully interactive page in under one second because the browser never waits for a server round-trip.
To implement this without losing your mind, you can skip Workbox and hand-roll a few dozen lines of code that give you exact control over your cache strategies. The first move is to precache your core assets during the install event. This includes your critical CSS, the main JavaScript bundle, and your app shell HTML if you’re serving a single-page application. The browser downloads these once and versions them with a cache key. On subsequent loads, the fetch handler intercepts the request, checks if the URL matches an entry in your precache manifest, and serves it directly from the cache with an immediate response. No network, no TTFB, no waiting for your origin server to stitch together fragments.
The second move is to register a fetch listener that applies different strategies based on request destination. For static assets like images with immutable URLs, you can use cache-first with no revalidation. For API GET requests, stale-while-revalidate works wonders. For navigations, you want what the spec calls a navigation preload. This clever feature runs your service worker in parallel with the browser’s network request to the server, shaving off the overhead of the service worker booting up before it passes the request through. Without navigation preload, your service worker adds an extra hop to the critical path. With it, you get a near-zero penalty on top of the normal network latency, and you still maintain the ability to serve a cached document if the network fails.
The real speed hack, though, is moving from fetch interception to full page-level caching. If you serve your homepage as a static HTML document, caching that entire response in your service worker means a returning visitor gets a complete render with zero network requests for the initial document. Your Time to Interactive collapses because the parser has everything it needs immediately. You can even scope this to certain routes, like your highest-traffic marketing pages, while leaving transactional pages alone. The key is understanding how to handle cache invalidation. Version your caches with the same hash you use for your build artifacts. When you deploy a new release, bump the cache name, delete old caches, and trigger the service worker to skip waiting and take control of open tabs. This prevents the classic stale-content trap that plagues naive implementations.
Watch out for storage quotas, though. Every browser has limits on how much a service worker can store. Safari is notoriously stingy, evicting caches without warning when under pressure. To be safe, keep your precache manifest lean and prune old entries during the activate event. Also remember that service workers require HTTPS. If you’re still on HTTP, you don’t get this capability, and that alone is a reason to move to a free CDN or TLS termination layer. For startups with tight budgets, this is a purely code-level optimization that costs no server resources and scales with client capability. You are essentially renting your users’ disk space and CPU cycles to defeat latency. That is the ultimate low-cost hack: turning the user’s own device into a performance accelerator for future sessions.
Measure the effect using the Performance Navigation Timing API. Compare DOMContentLoaded and load event times before and after you inject the service worker. You will see the TTI drop, and the Lighthouse performance score will jump because the simulated first load now benefits from service worker caching during the subsequent loads. But don’t stop there. Use server logs to watch your origin request volume plummet for repeat visitors. That is the unmistakable signal that your service worker is doing its job. It turns every repeat visit into a virtual offline experience, where the network only revalidates what has actually changed. That is the fastest speed fix you can buy for zero dollars and a few hours of careful scripting.
