DEV Community: chittaranjan nivargi

How I Cut My Site Load Time From 10s to 2s With 3 Simple Script Changes

chittaranjan nivargi — Sun, 21 Dec 2025 19:24:31 +0000

The Problem: My Financial Tools Site Was Painfully Slow

I run ToolsForIndia.com - a collection of financial calculators (SIP, PPF, EMI, etc.) for Indian users. Simple static HTML pages. No frameworks. No fancy stuff.

But PageSpeed Insights was giving me a 35/100 score.

Initial load time: 10.2 seconds on 3G.

For users in India (where 3G is still common), this was unusable.

What Was Causing the Slowdown?

I ran Chrome DevTools Performance tab and found the culprits:

Tailwind CDN (blocking): 4.8 seconds
Google Analytics (blocking): 2.1 seconds
Email capture script (blocking): 1.9 seconds
AdSense (already async): 0.8 seconds

Total blocking time: ~9 seconds before any content rendered.
The irony? All three scripts were non-critical for initial page render.

The Fix: Defer Everything That's Not Critical

Fix #1: Defer Tailwind CSS (Biggest Impact)

Before:

<script src="https://cdn.tailwindcss.com"></script>

After:

<script defer src="https://cdn.tailwindcss.com"></script>

What defer does:

Script downloads in parallel with HTML parsing
Executes after HTML parsing completes
Maintains execution order (important for dependencies)

Impact:

Load time: 10.2s → 5.4s (saved 4.8 seconds)
First Contentful Paint improved by 60%

Fix #2: Defer Google Analytics

Before:

<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXX"></script>
<script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());
    gtag('config', 'G-XXXXXX');
</script>

After:

<script>
window.addEventListener('load', function() {
    var script = document.createElement('script');
    script.async = true;
    script.src = 'https://www.googletagmanager.com/gtag/js?id=G-XXXXXX';
    document.head.appendChild(script);

    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());
    gtag('config', 'G-XXXXXX');
});
</script>

Why this approach:

Analytics loads after the page fully loads
User sees content immediately
No impact on tracking (slight delay is acceptable)

Impact:

Load time: 5.4s → 3.3s (saved 2.1 seconds)

Fix #3: Defer Email Capture Script

Before:

html<script async src="https://eomail5.com/form/FORM_ID.js" 
        data-form="FORM_ID"></script>

After:

html<script>
window.addEventListener('load', function() {
    var script = document.createElement('script');
    script.async = true;
    script.src = 'https://eomail5.com/form/FORM_ID.js';
    script.setAttribute('data-form', 'FORM_ID');
    document.head.appendChild(script);
});
</script>

Impact:

Load time: 3.3s → 2.1s (saved 1.2 seconds)

Key Lessons

async vs defer vs Manual Loading

<!-- async: Downloads in parallel, executes ASAP (may block) -->
<script async src="script.js"></script>

<!-- defer: Downloads in parallel, executes after HTML parse -->
<script defer src="script.js"></script>

<!-- Manual: Full control, loads after page ready -->
<script>
window.addEventListener('load', function() {
    // Load script here
});
</script>

When to use what:

Critical CSS/JS: Inline or normal blocking
UI frameworks (Tailwind, Bootstrap): defer
Analytics, ads: Manual load after page ready
Third-party widgets: Manual load (lowest priority)

The "Template Header" Approach

Since I have 20+ HTML pages, I don't want to update each one individually.
Solution: Create a reusable header template with all fixes:

<!-- header-template.html -->
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <!-- Deferred Tailwind -->
    <script defer src="https://cdn.tailwindcss.com"></script>

    <!-- Deferred Analytics -->
    <script>
    window.addEventListener('load', function() {
        if (localStorage.getItem('analytics-consent') === 'granted') {
            var script = document.createElement('script');
            script.async = true;
            script.src = 'https://www.googletagmanager.com/gtag/js?id=G-XXXXXX';
            document.head.appendChild(script);

            window.dataLayer = window.dataLayer || [];
            function gtag(){dataLayer.push(arguments);}
            gtag('js', new Date());
            gtag('config', 'G-XXXXXX');
        }
    });
    </script>
</head>

Copy-paste this into all pages. One-time fix, massive impact.

Test on Real Devices
PageSpeed Insights is great, but test on actual 3G/4G connections.
I used Chrome DevTools:
Open DevTools → Network tab
Throttling dropdown → "Slow 3G"
Hard refresh (Cmd+Shift+R)

This showed me the real user experience.

What I Learned NOT to Do

Don't defer critical CSS

I tried deferring ALL CSS initially. Result: FOUC (Flash of Unstyled Content) that looked terrible.
Rule: If CSS is needed for above-the-fold content, keep it blocking or inline it.

Don't break dependencies

Tailwind needs to load before custom Tailwind classes work. Using async instead of defer caused race conditions.
Rule: Use defer for scripts with dependencies; they execute in order.

Don't over-optimize

I tried code-splitting, tree-shaking Tailwind, etc. Not worth it for a simple site.
Rule: Fix the low-hanging fruit first. 80/20 principle.

The "Good Enough" Philosophy

Before: Chasing 100/100 PageSpeed score with complex build tools.
After: 92/100 with 3 script changes. Good enough.
My site is:

Static HTML (no SSR, no frameworks)
Uses CDN scripts (no build process)
Easy to maintain (no webpack config hell)

And now it's fast.

Your Turn: Quick Audit Checklist

Run PageSpeed Insights on your site
Check "Reduce JavaScript execution time" section
Identify blocking scripts:
- Analytics? → Defer after page load
- UI frameworks (Tailwind, Bootstrap)? → Add defer
- Third-party widgets? → Load last
Test on slow connection (Chrome DevTools throttling)
Re-run PageSpeed → Enjoy your 50+ point improvement

Code Repository

I've open-sourced the before/after versions:
Before (slow):

<!DOCTYPE html>
<html>
<head>
    <script src="https://cdn.tailwindcss.com"></script>
    <script async src="https://www.googletagmanager.com/gtag/js?id=G-XXX"></script>
    <script async src="https://eomail5.com/form/XXX.js"></script>
</head>
<body>
    <!-- Content -->
</body>
</html>

After (fast):

<!DOCTYPE html>
<html>
<head>
    <!-- Defer Tailwind -->
    <script defer src="https://cdn.tailwindcss.com"></script>

    <!-- Defer Analytics -->
    <script>
    window.addEventListener('load', function() {
        var ga = document.createElement('script');
        ga.async = true;
        ga.src = 'https://www.googletagmanager.com/gtag/js?id=G-XXX';
        document.head.appendChild(ga);

        window.dataLayer = window.dataLayer || [];
        function gtag(){dataLayer.push(arguments);}
        gtag('js', new Date());
        gtag('config', 'G-XXX');
    });
    </script>

    <!-- Defer Email Script -->
    <script>
    window.addEventListener('load', function() {
        var email = document.createElement('script');
        email.async = true;
        email.src = 'https://eomail5.com/form/XXX.js';
        email.setAttribute('data-form', 'XXX');
        document.head.appendChild(email);
    });
    </script>
</head>
<body>
    <!-- Content -->
</body>
</html>

Conclusion

You don't need:

Webpack
Build tools
Framework migrations
Complex optimizations

You just need:

Understand defer vs async
Defer non-critical scripts
Test on real connections

Result: 79% faster load time with 3 changes.

Discussion

What's your biggest site speed bottleneck? Share in the comments!

Building financial tools for 1 billion Indians at ToolsForIndia.com. Follow for more performance tips and dev lessons.

Meet the Creator: Chittaranjan Gopalrao Nivargi
Founder & Creator

Why We Ditched React and Built Financial Calculators in Vanilla JavaScript (And How It Made Everything Better)

chittaranjan nivargi — Sat, 15 Nov 2025 12:37:04 +0000

The Framework Trap

Every developer has been there. You start a new project and immediately reach for your favorite framework:

npx create-react-app my-calculator
# Installing 1,453 packages...
# 3 minutes later...
# node_modules folder: 289 MB

Three minutes and 289 MB later, you have a "Hello World" that takes 2 seconds to load on 3G.
For a calculator.
When we started building ToolsForIndia.com, we almost fell into the same trap. But then we asked a simple question:
"Do we actually need React for this?"
Spoiler: We didn't. And going vanilla JavaScript made everything faster, simpler, and more maintainable.

The Requirements: What We Actually Needed

Before choosing our tech stack, we listed our actual requirements:
Must Have:

✅ Fast load times (< 1 second on 3G)
✅ Client-side calculations (privacy)
✅ Export to PDF/CSV
✅ URL parameter sharing
✅ Mobile responsive
✅ Works offline (after first load)

Nice to Have:

✅ Charts and visualizations
✅ Dark mode (future)
✅ Multiple language support (future)

Don't Need:

❌ Real-time collaboration
❌ Complex state management
❌ Server-side rendering
❌ Database integration (yet)
❌ User authentication (yet)

Verdict: None of our "must haves" require a framework. We were about to add 289 MB of dependencies for features we didn't need.

The Stack: Intentionally Simple

Here's our entire tech stack:

<!DOCTYPE html>
<html>
<head>
    <!-- Tailwind CSS via CDN -->
    <script src="https://cdn.tailwindcss.com"></script>

    <!-- Chart.js for visualizations -->
    <script src="https://cdnjs.cloudflare.com/ajax/libs/Chart.js/3.9.1/chart.min.js"></script>

    <!-- jsPDF for exports -->
    <script src="https://cdnjs.cloudflare.com/ajax/libs/jspdf/2.5.1/jspdf.umd.min.js"></script>
</head>
<body>
    <!-- Pure HTML -->
    <div id="calculator">
        <!-- No JSX, no virtual DOM, just HTML -->
    </div>

    <script>
        // Pure JavaScript
        // No webpack, no babel, no build step
    </script>
</body>
</html>

Total bundle size: ~200 KB
Load time on 3G: < 1 second
Build time: 0 seconds (no build step!)

Architecture Decisions: Why Each Choice

1. Vanilla JavaScript Over React

React Approach:

// React component
import React, { useState, useEffect } from 'react';

function Calculator() {
    const [amount, setAmount] = useState(0);
    const [result, setResult] = useState(0);

    useEffect(() => {
        calculateResult();
    }, [amount]);

    return (
        <div>
            <input onChange={(e) => setAmount(e.target.value)} />
            <p>Result: {result}</p>
        </div>
    );
}

Advantages:

✅ No framework overhead
✅ No virtual DOM reconciliation
✅ Direct DOM updates (faster for simple UIs)
✅ No JSX compilation needed
✅ Anyone can read the code (no framework-specific patterns)

When React Would Win:

✅ Complex state management
✅ Many component re-renders
✅ Deeply nested component trees
✅ Team already knows React

For calculators? Vanilla wins.

2. Tailwind CSS via CDN (Not Compiled)

Controversial choice. Every Tailwind expert will tell you to use PostCSS and PurgeCSS to remove unused classes.
We use the full CDN version.
Why?

<!-- Our approach: One CDN link -->
<script src="https://cdn.tailwindcss.com"></script>
<!-- 50 KB gzipped, cached across sites -->

<!-- "Proper" approach: -->
<!-- Install Node.js, npm, PostCSS, PurgeCSS -->
<!-- Configure build pipeline -->
<!-- Run build on every change -->
<!-- Get 8 KB CSS file -->

Trade-off: We ship 42 KB extra CSS that's not used.
Gain: Zero build complexity, instant development, CDN caching.
For tools with < 10,000 daily users, this is the right trade-off.
When Compiled Tailwind Wins:

High traffic (millions of users)
Every KB matters
Have dedicated frontend team
Can maintain build pipeline

3. Client-Side Calculations Only

Every calculation happens in JavaScript. Zero server calls.

// SIP Future Value calculation (runs in browser)
function calculateSIP(monthlyInvestment, returnRate, years) {
    const months = years * 12;
    const monthlyRate = returnRate / 12 / 100;

    const futureValue = monthlyInvestment * 
        (Math.pow(1 + monthlyRate, months) - 1) / 
        monthlyRate * 
        (1 + monthlyRate);

    return Math.round(futureValue);
}

// No API call, no server, no latency

Advantages:

✅ Instant results (no network latency)
✅ Privacy (data never leaves browser)
✅ Works offline (after first page load)
✅ Scales infinitely (no server costs)
✅ No backend maintenance

When Server-Side Wins:

✅ Need to persist data
✅ Complex calculations (> 5 seconds)
✅ Multi-user features
✅ Need to update logic without redeploying

For calculators? Client-side wins every time.

4. localStorage for State (Not Redux)

We save user scenarios to localStorage:

// Save calculation
function saveScenario(name, data) {
    const scenarios = JSON.parse(localStorage.getItem('scenarios') || '[]');
    scenarios.push({ name, data, timestamp: Date.now() });
    localStorage.setItem('scenarios', JSON.stringify(scenarios));
}

// Load scenarios
function loadScenarios() {
    return JSON.parse(localStorage.getItem('scenarios') || '[]');
}

No Redux. No Context API. No state management library.

Advantages:

✅ Persists across sessions
✅ No server storage needed
✅ Simple API (2 methods: getItem, setItem)
✅ 5-10 MB storage per domain

Limitations:

❌ Can't sync across devices
❌ User can clear it
❌ Not suitable for sensitive data

For saving calculator scenarios? Perfect fit.

5. URL Parameters for Sharing

Want to share a calculation? We encode it in the URL:

// Generate shareable URL
function generateShareURL() {
    const params = new URLSearchParams({
        monthly: document.getElementById('monthly').value,
        years: document.getElementById('years').value,
        rate: document.getElementById('rate').value
    });

    return `${window.location.origin}${window.location.pathname}?${params}`;
}

// On page load, read params
const urlParams = new URLSearchParams(window.location.search);
if (urlParams.has('monthly')) {
    document.getElementById('monthly').value = urlParams.get('monthly');
    calculateResult(); // Auto-calculate
}

No database. No shortened URLs. Just URL parameters.
Advantages:

✅ Works immediately (no backend)
✅ Shareable via any medium
✅ Bookmarkable
✅ SEO-friendly (Google indexes different params)

Example:

toolsforindia.com/tools/sip-calculator.html?
monthly=10000&years=15&rate=12

Anyone clicking that link sees your exact calculation.

Performance: The Numbers

We ran Lighthouse audits on our calculators:

SIP Calculator:

Performance: 98/100
Accessibility: 95/100
Best Practices: 100/100
SEO: 100/100

Load Times (tested on 3G):

First Contentful Paint: 0.8s
Time to Interactive: 1.2s
Total Bundle Size: 187 KB

Compare to typical React app:

FCP: 2-3s
TTI: 3-5s
Bundle: 500KB - 2MB

Development Experience: Surprisingly Good

No Build Step = Instant Feedback
Change code → Refresh browser → See result
No waiting for webpack. No hot module replacement bugs. No build errors.
Easy Debugging

// Set breakpoint in browser DevTools
// See actual code, not transpiled/minified version
// Step through line by line

With frameworks, you're debugging transpiled code or source maps. With vanilla JS, you're debugging what actually runs.
Easy Onboarding
New developer joins? They need to know:

HTML
CSS
JavaScript
That's it

No React concepts. No webpack config. No babel presets.

The Trade-offs: What We Gave Up

1. Component Reusability

React components are easy to reuse. With vanilla JS, we copy-paste more.
Our solution: Keep components small and independent.

2. State Management at Scale

If we had 50+ interactive elements with complex dependencies, Redux would help.
Current reality: Each calculator has ~10 inputs. Vanilla JS handles this fine.

3. Developer Ecosystem

React has thousands of ready-made components (date pickers, charts, etc.).
Our solution: Use vanilla JS libraries (Chart.js, jsPDF) that don't require frameworks.

4. Testing

React has great testing tools (Jest, React Testing Library).
Our solution: Manual testing for now. Will add vanilla JS tests when needed.

When You Should Use a Framework

Don't take this as "frameworks are bad." Use them when:
✅ Building complex SPAs with many views
✅ Team already knows the framework
✅ Need component reusability at scale
✅ Complex state management (>50 pieces of state)
✅ Real-time features
✅ Need server-side rendering
For calculators, landing pages, blogs, small tools? Vanilla JS is often the better choice.

The Results: User Feedback

After 30 days:
Speed:

"Finally, a calculator that loads instantly!"
"Works great even on slow internet"

Privacy:

"Love that it doesn't need signup"
"Calculation happens in browser = my data stays private"

Simplicity:

"Clean design, no clutter"
"Just does what it says"

Lessons Learned

Question Framework Defaults Just because everyone uses React doesn't mean you need it. Evaluate based on requirements, not trends.
Optimize for Real Users Our users are in India, often on 3G. Fast load times > fancy animations.
Ship First, Optimize Later We shipped with CDN Tailwind. If we hit 100K users, we'll compile it. Don't optimize prematurely.
Constraints Breed Creativity No frameworks forced us to write cleaner, more intentional code.

The Code: Open for Inspection

Visit any calculator page, right-click, "View Page Source."
You'll see:

Readable HTML
Understandable JavaScript
No minification (yet)
No obfuscation

This is intentional. We want developers to learn from our code.

Try It Yourself

SIP Calculator: toolsforindia.com/tools/sip-calculator.html
PPF Calculator: toolsforindia.com/tools/ppf-calculator.html

Open DevTools. Check the Network tab. See the load times yourself.

Conclusion: Right Tool for the Job

React is amazing for what it does. But it's not always the right tool.
For ToolsForIndia.com, vanilla JavaScript gave us:

⚡ 5x faster load times
🔒 Better privacy (client-side only)
🧹 Simpler codebase
💰 Lower complexity cost

Would we use React for a complex dashboard with 100+ components? Absolutely.
For calculators? Vanilla JS wins.

About the Author

Building ToolsForIndia.com with intentionally simple tech. Previously worked with React/Vue/Angular. Now shipping faster with vanilla JS. Believes in using the simplest tool that solves the problem.
🔗 toolsforindia.com
🐦 @toolsforindia
📧 contact@toolsforindia.com
P.S. View source on our calculators. All code is unminified and readable. Learn, copy, improve.

Building a Password Checker with Vanilla JS (No Frameworks!)

chittaranjan nivargi — Thu, 06 Nov 2025 06:14:03 +0000

I got locked out of the GST portal for the third time because my password "didn't meet requirements."

No explanation. Just "Invalid password."
After wasting 30 minutes trying different passwords, I decided to build a tool that would tell me exactly what was wrong with my password for different government portals.
Result: PasswordChecker.in - Built in 2 weekends with vanilla JavaScript. No React. No Vue. No frameworks.
Here's how I did it.

Why No Frameworks?

Speed. I wanted the tool to be:

Fast to load (< 50KB total)
Fast to build (2 weekends)
Fast to run (real-time password checking)

Adding React would add 130KB+ before I wrote a single line of code. For a single-page tool, that's overkill.

The Tech Stack

Frontend: Vanilla JavaScript + Tailwind CSS

Styling: Tailwind CDN (for rapid prototyping)

API: Have I Been Pwned (k-Anonymity model)

Hosting: Vercel

Source Control: GitHub

Total bundle size: ~48KB (including Tailwind)
Feature #1: Real-Time Password Strength Checker
The Requirements
Different Indian government portals have different password requirements:

const portalRequirements = {
  uidai: {
    minLength: 8,
    requiresUppercase: true,
    requiresLowercase: true,
    requiresNumber: true,
    requiresSpecial: true,
  },
  gstn: {
    minLength: 10,
    requiresUppercase: true,
    requiresLowercase: true,
    requiresNumber: true,
    requiresSpecial: true,
    maxLength: 15,
  },
  incomeTax: {
    minLength: 12,
    requiresUppercase: true,
    requiresLowercase: true,
    requiresNumber: true,
    requiresSpecial: true,
    maxLength: 14,
  },
};

The Core Logic

function checkPasswordStrength(password) {
  const checks = {
    length: password.length >= 8,
    uppercase: /[A-Z]/.test(password),
    lowercase: /[a-z]/.test(password),
    number: /[0-9]/.test(password),
    special: /[!@#$%^&*()_+\-=\[\]{};':"\\|,.<>\/?]/.test(password),
  };

  // Calculate score (0-100)
  let score = 0;
  if (checks.length) score += 20;
  if (checks.uppercase) score += 20;
  if (checks.lowercase) score += 20;
  if (checks.number) score += 20;
  if (checks.special) score += 20;

  // Additional points for length
  if (password.length >= 12) score += 10;
  if (password.length >= 16) score += 10;

  return {
    score: Math.min(score, 100),
    checks,
    strength: getStrengthLabel(score),
  };
}

function getStrengthLabel(score) {
  if (score >= 80) return 'Very Strong';
  if (score >= 60) return 'Strong';
  if (score >= 40) return 'Moderate';
  if (score >= 20) return 'Weak';
  return 'Very Weak';
}

Real-Time Updates

const passwordInput = document.getElementById('password');
const strengthMeter = document.getElementById('strength-meter');

passwordInput.addEventListener('input', (e) => {
  const password = e.target.value;
  const result = checkPasswordStrength(password);

  // Update UI
  updateStrengthMeter(result);
  updateChecklist(result.checks);
  checkPortalCompliance(password);
});

Feature #2: Password Generator

Users needed passwords that were:

Strong (meets requirements)
Memorable (not random gibberish)
Portal-specific (works for UIDAI, GST, etc.)

The Memorable Password Algorithm
Instead of generating xK9!mP2@, generate Quick7Tiger$42

function generateReadablePassword(requirements) {
  const adjectives = ['Quick', 'Brave', 'Smart', 'Cool', 'Swift'];
  const nouns = ['Tiger', 'Eagle', 'Wolf', 'Lion', 'Hawk'];
  const specials = ['@', '#', '$', '%', '&', '*'];

  const adjective = adjectives[Math.floor(Math.random() * adjectives.length)];
  const number1 = Math.floor(Math.random() * 9) + 1;
  const noun = nouns[Math.floor(Math.random() * nouns.length)];
  const special = specials[Math.floor(Math.random() * specials.length)];
  const number2 = Math.floor(Math.random() * 90) + 10;

  let password = `${adjective}${number1}${noun}${special}${number2}`;

  // Adjust for portal requirements
  if (requirements.minLength > password.length) {
    password += Math.random().toString(36).substring(2, requirements.minLength - password.length + 2);
  }

  return password;
}

Output: Passwords like Smart5Wolf@73 - easy to remember, meets all requirements.

Feature #3: Data Breach Checker

This was the most complex feature. I needed to check if a password appeared in data breaches without sending the password to any server.
The k-Anonymity Model
Have I Been Pwned (HIBP) uses k-Anonymity:

Hash the password (SHA-1)
Send only the first 5 characters of the hash
Server returns all breached passwords matching those 5 chars
Client checks if full hash is in the list

async function checkPasswordBreach(password) {
  // Hash password
  const hash = await sha1(password);
  const prefix = hash.substring(0, 5);
  const suffix = hash.substring(5).toUpperCase();

  // Query HIBP API (only send first 5 chars)
  const response = await fetch(`https://api.pwnedpasswords.com/range/${prefix}`);
  const data = await response.text();

  // Check if full hash is in response
  const hashes = data.split('\n');
  for (let line of hashes) {
    const [hashSuffix, count] = line.split(':');
    if (hashSuffix === suffix) {
      return {
        found: true,
        count: parseInt(count),
      };
    }
  }

  return { found: false };
}

// SHA-1 implementation
async function sha1(str) {
  const buffer = new TextEncoder().encode(str);
  const hash = await crypto.subtle.digest('SHA-1', buffer);
  const hashArray = Array.from(new Uint8Array(hash));
  return hashArray.map(b => b.toString(16).padStart(2, '0')).join('');
}

Privacy: Your password never leaves your browser. Only the first 5 characters of its hash are sent.

Feature #4: Multi-Portal Compatibility Test

Test one password against 10 portals simultaneously.

function testPortalCompatibility(password) {
  const portals = [
    { name: 'UIDAI', requirements: portalRequirements.uidai },
    { name: 'GSTN', requirements: portalRequirements.gstn },
    { name: 'Income Tax', requirements: portalRequirements.incomeTax },
    // ... more portals
  ];

  return portals.map(portal => ({
    name: portal.name,
    compatible: checkRequirements(password, portal.requirements),
    issues: getIssues(password, portal.requirements),
  }));
}

function checkRequirements(password, requirements) {
  if (password.length < requirements.minLength) return false;
  if (requirements.maxLength && password.length > requirements.maxLength) return false;
  if (requirements.requiresUppercase && !/[A-Z]/.test(password)) return false;
  if (requirements.requiresLowercase && !/[a-z]/.test(password)) return false;
  if (requirements.requiresNumber && !/[0-9]/.test(password)) return false;
  if (requirements.requiresSpecial && !/[!@#$%^&*]/.test(password)) return false;

  return true;
}

Deployment

Local Development:

# No build step!
python -m http.server 8000
# Visit localhost:8000

Production:

git push origin main
# Vercel auto-deploys

No webpack. No babel. No build process.

Performance Optimizations

Debounced Input Don't check password on every keystroke:

function debounce(func, wait) {
  let timeout;
  return function executedFunction(...args) {
    clearTimeout(timeout);
    timeout = setTimeout(() => func.apply(this, args), wait);
  };
}

const debouncedCheck = debounce((password) => {
  checkPasswordStrength(password);
}, 300);

passwordInput.addEventListener('input', (e) => {
  debouncedCheck(e.target.value);
});

Lazy Load Breach Check Only check breaches when user clicks "Check for Breaches":

// Don't auto-check (expensive API call)
breachCheckButton.addEventListener('click', async () => {
  showLoader();
  const result = await checkPasswordBreach(password);
  hideLoader();
  displayResult(result);
});

Cache API Responses

const breachCache = new Map();

async function checkPasswordBreach(password) {
  const hash = await sha1(password);
  const prefix = hash.substring(0, 5);

  // Check cache first
  if (breachCache.has(prefix)) {
    return checkHash(breachCache.get(prefix), hash);
  }

  // Fetch and cache
  const response = await fetch(`https://api.pwnedpasswords.com/range/${prefix}`);
  const data = await response.text();
  breachCache.set(prefix, data);

  return checkHash(data, hash);
}

Lessons Learned

1. Vanilla JS is Fast Enough

For most tools, you don't need a framework. Vanilla JS is:

Faster to load
Easier to debug
Fewer dependencies
More portable

2. Real-Time Feedback is Critical

Users type fast. Your UI must keep up. Debouncing is your friend.

3. Privacy Matters

For a password tool, client-side only was non-negotiable. No backend. No database. No tracking.

Users can inspect the source and verify nothing is sent to any server (except the HIBP API with anonymized data).

4. Government Standards are Inconsistent

Every portal has different requirements. No standardization. This makes users' lives harder—and creates opportunities for tools like mine.

What's Next

Planned Features:

Browser extension (auto-fill government portals)
Bulk password checking (CSV upload)
API for developers
Dark mode

Tech Debt:

Add proper testing (currently manually tested)
Consider Web Components for reusability
Add service worker for offline support

Try It Yourself

Live: passwordchecker.in

Source: (Will open-source if there's interest—comment below!)

Conclusion

You don't need React to build useful tools. Sometimes vanilla JavaScript is the right choice.

Key Takeaways:

Keep it simple
Client-side for privacy
Real-time feedback
Focus on UX

Built in 2 weekends. 500+ users in the first week. Zero frameworks.

Questions? Ask in the comments!