DEV Community: Mozamme Hoshen Chowdhury

Building Offline-First Web Apps with Service Workers

Mozamme Hoshen Chowdhury — Sun, 05 Oct 2025 07:59:09 +0000

When a web app fails the moment the connection drops, users don’t blame the network—they blame the app. We’ve all hit that wall: hit “save,” the spinner hangs, and then everything disappears behind a “You’re offline” message. That’s a trust breaker.

Offline-first development is the remedy. Modern browsers let us build apps that keep working without an internet connection, and they feel fast even when the network is slow. The linchpin is the Service Worker—a small script that runs in the background, intercepts requests, and decides whether to serve content from cache, the network, or a combination of both.

In this guide, I’ll walk through how to design and implement an offline-first architecture using Service Workers, how to choose caching strategies, how to store data locally (LocalStorage and IndexedDB), and how to ship a Progressive Web App (PWA) that users can install. Along the way, I’ll reference a real example PC Notepad a clean, distraction-free online notepad that works entirely in the browser. If you’re curious about building your own notepad online or online writing notepad that feels instant and private, you’ll see how it’s done.

What Offline-First Really Means

Offline-first is a mindset more than a library. Your app should assume the network can fail at any time and still deliver core functionality. In practice, that means:

The first load is quick because essential assets are cached.
Primary interactions work even with no signal.
Data created offline is stored locally and syncs later.
Updates roll out gracefully without breaking the experience.

This isn’t just for note apps. It’s useful for calculators, checklists, documentation browsers, and countless tools that benefit from fast, reliable UX. But online notepad experiences are a particularly good fit: opening a page, typing text, and saving locally is exactly the use case where offline-first shines.

Why Users Care (Even If They Don’t Say It)

Speed: Serving from cache is usually faster than hitting the network.
Reliability: The app “just works,” even on trains, planes, and patchy mobile networks.
Privacy: When your app stores data locally, less information travels across the wire.
Trust: A tool that never leaves the user stranded builds loyalty.

If your product competes with an online notepad free or free online notepad tool, offline-first is a differentiator: fast, private, and dependable.

Service Workers in Plain English

A Service Worker is a background script that acts like a programmable proxy between your app and the network. Once registered, it can:

Cache static assets (HTML, CSS, JS, fonts, icons)
Intercept network requests
Serve cached content when offline
Perform background syncs and handle push notifications
Enable your site to be “installable” as a PWA

The magic is that you get to pick the strategy for each request type. Static assets might be cache-first. API calls might be network-first with a cached fallback. Feeds might be stale-while-revalidate to feel instant but quietly refresh in the background.

Minimal Setup

Create service-worker.js:

// service-worker.js
self.addEventListener('install', event => {
  event.waitUntil(
    caches.open('app-v1').then(cache => {
      return cache.addAll([
        '/',
        '/index.html',
        '/styles.css',
        '/app.js',
        '/favicon.ico'
      ]);
    })
  );
});

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request).then(hit => hit || fetch(event.request))
  );
});

And register it in your main JS file:

if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker
      .register('/service-worker.js')
      .then(() => console.log('Service Worker registered'))
      .catch(err => console.error('SW registration failed:', err));
  });
}

That’s enough to cache essential assets and serve them when offline. From here, you’ll refine caching behavior per route or file type.

Choosing the Right Caching Strategy

Different data patterns call for different strategies. Here are the most common patterns and when to use them:

Strategy	How it Works	When to Use
Cache-First	Serve from cache; if missing, go to network and cache it	Static assets (JS, CSS, fonts, icons), app shell
Network-First	Try network; if it fails, serve from cache	Content that updates often (articles, user data)
Stale-While-Revalidate	Serve cached version instantly; fetch in background to update cache	Feeds, dashboards, home page lists
Cache-Only	Only serve from cache	Fully offline tools, demos, or rarely changing binaries
Network-Only	Always go to network	Real-time APIs, auth endpoints, sensitive data

Example: Network-First for API Calls

self.addEventListener('fetch', event => {
  const req = event.request;
  if (req.url.includes('/api/')) {
    event.respondWith(
      fetch(req)
        .then(res => {
          const copy = res.clone();
          caches.open('dynamic-v1').then(cache => cache.put(req, copy));
          return res;
        })
        .catch(() => caches.match(req))
    );
  }
});

Example: Cache-First for Static Assets

self.addEventListener('fetch', event => {
  const req = event.request;
  if (req.destination === 'style' || req.destination === 'script' || req.destination === 'image') {
    event.respondWith(
      caches.match(req).then(hit => hit || fetch(req).then(res => {
        const copy = res.clone();
        caches.open('static-v2').then(cache => cache.put(req, copy));
        return res;
      }))
    );
  }
});

Versioning and Cleanup

Change your cache name when you ship a new asset bundle (e.g., from static-v2 to static-v3). Then delete old caches during the activate event:

self.addEventListener('activate', event => {
  const keep = ['app-v2', 'static-v3', 'dynamic-v1'];
  event.waitUntil(
    caches.keys().then(keys =>
      Promise.all(keys.map(k => (keep.includes(k) ? null : caches.delete(k))))
    )
  );
});

Without this, users can get stuck on outdated files.

Local Data: LocalStorage vs IndexedDB

Offline-first isn’t only about assets. It’s also about user data that should survive reloads and disconnections.

LocalStorage is synchronous and simple—great for single notes, settings, or small content.

function saveDraft(text) {
  localStorage.setItem('draft', text);
}
function loadDraft() {
  return localStorage.getItem('draft') || '';
}

IndexedDB is asynchronous, structured, and better for multiple documents, search indices, or attachments.

const req = indexedDB.open('notesDB', 1);
req.onupgradeneeded = e => {
  const db = e.target.result;
  db.createObjectStore('notes', { keyPath: 'id' });
};

function putNote(db, note) {
  return new Promise((resolve, reject) => {
    const tx = db.transaction('notes', 'readwrite');
    tx.objectStore('notes').put(note);
    tx.oncomplete = resolve;
    tx.onerror = reject;
  });
}

If you’re building an online writing notepad or online notepad editor, IndexedDB gives you room to scale: multiple notes, tagging, autosave, and conflict resolution when syncing later.

A Real-World Model: PC Notepad

A practical example of these ideas is PC Notepad—a free online notepad that loads instantly, works offline, and doesn’t require sign-up. It leans on:

A Service Worker for caching the app shell and static assets
LocalStorage/IndexedDB for user content
A PWA manifest for installability
Optional client-side password lock for privacy (“online notepad with password” is a common user need)

Because data never leaves the device by default, it naturally supports use cases people search for, like “online notepad dark mode,” “online notepad shareable” (via a link or export flow when online), or “best online notepad” for distraction-free writing. If you’re comparing options like “notepad online free,” “free notepad online,” “online notepad text editor,” or even “notepad++ online,” the offline-first approach is what makes a tool feel instant and trustworthy.

Try it: open PC Notepad, write a few lines, turn off Wi-Fi, reload. The note remains. That’s offline-first working as intended.

Update UX: Telling Users When a New Version Is Ready

Offline caching means users can keep running an old bundle until you update them. A common pattern is to prompt users when the newly installed Service Worker is ready.

navigator.serviceWorker.register('/service-worker.js').then(reg => {
  reg.onupdatefound = () => {
    const worker = reg.installing;
    worker.onstatechange = () => {
      if (worker.state === 'installed' && navigator.serviceWorker.controller) {
        // Old content is in use; new content is cached
        showUpdateToast('New version available. Reload to update.');
      }
    };
  };
});

Whether your app is an online memo notepad, a handwriting notepad online concept, or a notepad online editor, this small UX detail prevents confusion and keeps the experience fresh.

Turn It Into a PWA

Add a manifest.json so users can install your app:

{
  "name": "Minimal Notes",
  "short_name": "Notes",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0a84ff",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

Link it in <head>:

<link rel="manifest" href="/manifest.json">

Users can now “Install App” on desktop or mobile. That installable feel is one reason people stick with a best online notepad candidate over a site that always feels like “just another tab.”

Testing Offline Behavior

Use Chrome DevTools to simulate offline conditions:

Open DevTools → Application tab
Check Offline under Service Workers
Reload the app and verify critical flows
Inspect Cache Storage to confirm assets are stored
Test again with Wi-Fi disabled to confirm real behavior

While testing, pay attention to autosave frequency, restore logic, and what happens if the user closes the tab mid-write. For online notepad share experiences, test how pending “share links” or exported files are queued and posted when the network returns.

Security, Privacy, and Content Rules

Service Workers require HTTPS. Use it everywhere.
Don’t cache sensitive endpoints or tokens inappropriately.
If you implement a lock or password, do it client-side with a clear model of what’s encrypted.
Consider a “Private Mode” that avoids analytics. If you offer a dark notepad online or “online notepad dark mode,” pair it with “Private Mode” in the settings to attract privacy-minded users.

This is where a simple online notepad can beat heavier solutions: your app doesn’t need to track or profile users to work. That’s a selling point.

Common Pitfalls (and How to Avoid Them)

Never updating caches

Always bump cache versions and clean old caches on activate.
1. Caching everything by default
Be selective; large caches slow down installs and consume storage.
1. Ignoring sync conflicts
If you add cloud sync later, build a simple conflict policy: most recent wins, or prompt the user.
1. No update notifications
Users won’t magically reload—tell them.
1. Testing only online
Ship with real offline testing. Pull the plug. See what breaks.

Performance Tips

Minify and compress assets (JS/CSS) before caching.
Use stale-while-revalidate for content that must feel fast but stay up-to-date.
Lazy-load large chunks—especially editors, syntax highlighters, or image tools.
Track storage use:

if (navigator.storage && navigator.storage.estimate) {
  navigator.storage.estimate().then(({ quota, usage }) => {
    console.log('Storage usage:', usage, 'of', quota);
  });
}

For an online notepad text editor or code notepad online experience, this guardrail prevents asset bloat from killing the first-run install.

For performance-focused web utilities, speed and responsiveness are part of the core experience. For example, a browser-based tool like FPS Test can help users check FPS, refresh rate, and display smoothness directly in the browser. For this kind of utility, keeping the interface fast, lightweight, and reliable is just as important as the test result itself.

Practical Use Cases

Writers and students: A fast online notepad that saves drafts automatically, works offline during commutes, and syncs later if needed.
Developers: Lightweight task notes or code snippets; some users even look for notepad++ online substitutes for quick edits.
Teams: Temporary shared notes; a shareable online notepad with read-only or editable links.
Field work: Data entry in low-connectivity areas that syncs when you’re back in range.
Personal productivity: Checklists that survive reloads and outages.

The common thread: the app feels local and dependable, yet it’s still “just a website.”

Putting It All Together

An offline-first online notepad (or any utility app) typically ships with:

Service Worker controlling caching of the app shell and routes.
LocalStorage/IndexedDB for content and settings.
Update flow that prompts users when a new version is ready.
Manifest.json for installability.
A simple, focused UI that helps users write, edit, and share without distractions.

That’s essentially the architecture behind PC Notepad—a clean, free online writing notepad that loads instantly, respects privacy, and works even if the network doesn’t. If you’re researching the best online notepad options or deciding whether to build your own, offline-first is the approach that keeps users coming back.

FAQs

How does this compare to “microsoft notepad online” or “google notepad online”?
Those are often shortcuts people type when they want a browser-based quick note. A focused online notepad PWA with offline support can be faster to reach than a full document suite, and it won’t lock notes behind an account if you design it that way.

What about themes like “black notepad online” or “online notepad dark mode”?
Themes are trivial on top of offline-first. Cache the CSS, store the preference locally, and apply it on load.

Can I add drawing features for “online notepad draw” queries?
Yes. Use a <canvas> element with simple stroke logic; store paths in IndexedDB for replay and export. Offline storage and caching work the same way.

How do I describe this to non-technical readers searching for “best free online notepad”?
Say: “It opens instantly, works without the internet, saves automatically, and respects your privacy.” That’s what most people want.

Final Thoughts

Service Workers give web developers a new baseline: fast by default, resilient by design. If you’re building a note editor, checklist, or any utility, make it offline-first and installable. Your users will feel the difference immediately.

If you want to see these ideas working in production, open PC Notepad and try it with your Wi-Fi off. It’s a simple proof that an online notepad doesn’t need a server to feel solid.

From Megabytes to Kilobytes: A Dev’s Guide to Practical Image Compression

Mozamme Hoshen Chowdhury — Tue, 23 Sep 2025 19:49:26 +0000

Introduction

Have you ever tried uploading a photo to a government portal, university application form, or job site, only to see this dreaded error:

❌ “Your file must be under 100KB.”

It doesn’t matter that your photo is crystal-clear, perfectly cropped, and 2MB in size. The site simply won’t accept it unless it fits neatly into that tiny KB box.

I’ve been there. You’ve probably been there. And as developers, we’ve definitely seen our users get stuck there.

That’s where image compression comes in.

In this article, I want to walk you through the journey of taking an image from megabytes to kilobytes in a way that’s practical, developer-friendly, and user-first. We’ll cover:

Why image compression still matters in 2025.
How lossy vs lossless compression really works.
Client-side vs server-side methods (with code!).
Trade-offs and real-world scenarios.
Best practices you can implement in your projects today.

By the end, you’ll not only know the “why” but also the “how” — with code snippets you can actually use.

Why Image Compression Still Matters in 2025

In an age of fiber internet and 5G, why are we still talking about KB-sized files? Shouldn’t everything just work with big high-res images?

Not quite.

Here’s why:

User-facing restrictions: Government portals, job sites, university forms — they often have strict file size limits. Many still say “100KB max.”
Performance: Even if you’re not bound by upload forms, smaller images = faster sites. Faster sites = happier users + better SEO.
Storage costs: If your platform handles thousands of uploads daily, reducing from MBs to KBs adds up in saved storage & bandwidth.

So yes — despite new formats like WebP and AVIF, the KB problem is alive and kicking.

Understanding Image Compression

At its core, image compression is about making files smaller without making them useless.

Lossy vs Lossless

Lossless: Shrinks the file while keeping all original data intact (e.g., PNG). No quality loss, but limited reduction.
Lossy: Discards “extra” data your eyes won’t notice (e.g., JPEG at 80% quality). Huge size savings, with some quality trade-off.

File formats matter

JPEG → Best for photos, adjustable compression.
PNG → Best for transparency, logos, lossless.
WebP/AVIF → New formats with great efficiency, but not always accepted on portals/forms.

Dimension-based vs KB-based resizing

Dimension-based: “Resize to 800×600 pixels.”
KB-based: “Resize to under 100KB.”

Developers often have to support both.

A practical first step is to reduce the image dimensions before applying KB-based compression. For example, if a photo is unnecessarily large, you can resize it with a browser-based tool like TunerPage Image Resizer, then fine-tune the final file size for upload requirements.

Client-Side Compression (in the Browser)

This is the magic of modern browsers: we can now compress images without uploading them to a server.

Why it’s awesome:

Privacy → image never leaves the device.
Speed → instant compression.
Cost → no server resources.

Here’s a simple JavaScript snippet using the Canvas API:

function compressImage(file, maxWidth, maxHeight, quality, callback) {
  const reader = new FileReader();
  reader.readAsDataURL(file);

  reader.onload = function(event) {
    const img = new Image();
    img.src = event.target.result;

    img.onload = function() {
      const canvas = document.createElement("canvas");
      let width = img.width;
      let height = img.height;

      if (width > height) {
        if (width > maxWidth) {
          height *= maxWidth / width;
          width = maxWidth;
        }
      } else {
        if (height > maxHeight) {
          width *= maxHeight / height;
          height = maxHeight;
        }
      }

      canvas.width = width;
      canvas.height = height;
      canvas.getContext("2d").drawImage(img, 0, 0, width, height);

      canvas.toBlob(
        (blob) => callback(blob),
        "image/jpeg",
        quality // e.g., 0.7 for 70%
      );
    };
  };
}

You can plug this into any web app to resize and compress images before uploading.

In fact, this browser-first approach is what powers free tools like Photo Resizer In KB, which lets users pick presets (20KB, 50KB, 100KB) without worrying about the details.

Server-Side Compression

Of course, client-side isn’t always enough. For batch jobs, automation, or enterprise apps, you’ll want server-side compression.

Example 1: Python (Pillow)

from PIL import Image

def compress_image(input_file, output_file, quality=70):
    img = Image.open(input_file)
    img.save(output_file, "JPEG", optimize=True, quality=quality)

compress_image("photo.jpg", "photo_compressed.jpg", 70)

This script reduces size by lowering JPEG quality.

Example 2: Node.js (Sharp)

const sharp = require("sharp");

sharp("photo.jpg")
  .resize(800) // max width
  .jpeg({ quality: 70 })
  .toFile("photo_compressed.jpg")
  .then(() => console.log("Done!"));

Sharp is super fast and great for production pipelines.

Trade-offs Developers Face

When compressing images, you’re always balancing:

File size vs quality (too small = ugly, too big = rejected).
Speed vs precision (client-side is faster, server-side is more flexible).
Formats (JPEG is universal, AVIF/WebP are better but not always accepted).

As devs, the challenge is choosing the right tool for the right use case.

Real-World Use Cases

Job portals → “Upload your passport photo under 100KB.”
Government portals → Rigid KB requirements.
E-commerce → Preview images need to load fast.
Social media → Compress before sharing.
Mobile apps → Reduce upload times on poor connections.

Best Practices for Developers

Always compress before upload.
Offer presets (20KB, 50KB, 100KB).
Validate size server-side.
Respect privacy — delete after processing.
Test across formats (JPEG, PNG, WebP).

Conclusion

From megabytes to kilobytes — it’s a journey we’ll keep making, whether we’re building apps or just filling out forms.

As developers, we owe it to users to make that journey smoother. That means offering easy presets, optimizing images behind the scenes, and respecting privacy.

The next time you see that dreaded “File must be under 100KB” message, remember: with the right code and the right approach, it doesn’t have to be painful.