Forem: Touseef Ibn Khaleel

Why We Ditched iFrames for Our Testimonial Widget (And Wrote 1,000 Lines of Vanilla JS Instead)

Touseef Ibn Khaleel — Wed, 29 Apr 2026 18:27:41 +0000

Every embeddable widget tutorial recommends an iFrame. Drop it in, it's isolated, it can't affect the host page, done. We followed that advice for the first version of Proofly's Wall of Love embed. It lasted about three weeks before we tore it out.

The problems weren't subtle. They showed up immediately, in the first round of user testing, on every host site that wasn't a plain white page.

What broke

Height synchronization. An iFrame doesn't know how tall its content is unless you tell it. Our Wall of Love renders a grid of testimonial cards — the number varies by plan, the cards vary in height based on how long the testimonial text is, and the layout reflows when the viewport changes. Keeping the iFrame height synchronized with its content required a postMessage listener inside the frame, a ResizeObserver watching the content, and a handler outside the frame that updated the height style in response. This worked until it didn't — race conditions on initial load, missed resize events on certain mobile browsers, and a 300ms flash of the wrong height on every page load.

Scroll isolation on mobile. Touch-scroll on iOS inside an iFrame is famously broken. Depending on how the iFrame is sized and positioned, the user either scrolls the frame content, scrolls the parent page, or both fight each other in a way that makes the section feel stuck. We tried -webkit-overflow-scrolling: touch and various overflow combinations. Nothing was clean.

Background color bleed. iFrames have a default white background. If the host page section has a dark or colored background, the iFrame box shows as a white rectangle until the content loads, then snaps to transparent (if you've set background: transparent on the frame body). The flash is ugly. More importantly, some host configurations — Webflow, certain WordPress themes — override the iFrame background regardless of what we set inside it.

Any one of these would have been acceptable to ship around. All three together meant the embed looked bad in ways we couldn't fully control.

What we built instead

The replacement is a script tag that, when loaded, injects the widget directly into the host page's DOM. No iFrame. The host page just needs a container div with a data-proofly-wall attribute:

<div data-proofly-wall="your-embed-slug"></div>
<script src="https://proofly.shipquick.app/embed.js" async></script>

The embed script does the following on load:

(function() {
  const containers = document.querySelectorAll('[data-proofly-wall]');
  containers.forEach(container => {
    const slug = container.getAttribute('data-proofly-wall');
    if (!slug) return;
    initWall(container, slug);
  });
})();

initWall fetches the wall data from our API using the embedSlug as the only credential, builds the DOM, injects the styles, and appends everything to the container. The slug is a random 16-character string — unguessable, not rotatable, and intentionally not tied to an auth session. If someone steals your embed slug, the worst outcome is they display your testimonials on their site, which is not a meaningful threat model.

Scoping CSS without Shadow DOM

The first thing you reach for when you need style isolation is Shadow DOM. We looked at it. The browser support is fine in 2026. The problem is that Shadow DOM makes it hard to let host page fonts inherit into the widget, which matters for design-conscious customers who want the testimonial cards to match their site's typography.

Instead, every CSS rule in the embed is prefixed with .proofly-root:

.proofly-root {
  font-family: inherit;
  box-sizing: border-box;
}

.proofly-root .wall-grid {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
  gap: 1rem;
}

.proofly-root .testimonial-card {
  background: var(--proofly-card-bg, #ffffff);
  border-radius: var(--proofly-radius, 8px);
  padding: 1.25rem;
}

CSS custom properties (--proofly-card-bg, --proofly-radius, etc.) let customers theme the widget from their host page without us needing to expose a configuration API. They set variables on the container and the widget inherits them.

The inject-once check is simple:

function injectStyles() {
  if (document.getElementById('proofly-embed-styles')) return;
  const style = document.createElement('style');
  style.id = 'proofly-embed-styles';
  style.textContent = EMBED_CSS; // minified at build time
  document.head.appendChild(style);
}

The slug as the security model

The Wall of Love is intentionally public — the whole point is to display approved testimonials to anyone who visits the host page. There's no sensitive data in the embed response. The embedSlug isn't a secret key; it's more like a stable, opaque identifier.

async function fetchWallData(slug) {
  const res = await fetch(`https://proofly.shipquick/app/embed/${slug}`);
  if (!res.ok) return null;
  return res.json();
}

The API endpoint for embed data is public and rate-limited but not authenticated. It returns only the approved testimonials for that wall — no user data, no account information. If a customer wants to take their wall private (hide it without deleting it), they can disable the embed from their dashboard, which stops the endpoint from returning data for that slug.

The ~1,000 lines

The file is currently 1,140 lines, including comments. The bulk of it is:

The card renderer (~200 lines): handles text cards, video thumbnail cards, audio cards, and star ratings
The grid layout manager (~150 lines): responsive column logic, masonry-style height balancing, lazy loading
The CSS injection (~180 lines): the full stylesheet, minified at build time
Video modal (~200 lines): click-to-expand video playback, keyboard close, scroll lock while open
Utilities (~100 lines): debounce, intersection observer for lazy loading, DOM helpers
Initialization and public API (~150 lines): initWall, the data- attribute scanner, the window.Proofly object It's vanilla JS — no bundler, no framework dependencies. This was a deliberate choice. The embed runs on every customer's host site, which might be a React app, a Webflow site, a plain HTML page, or a WordPress theme from 2019. Shipping a dependency graph into that environment is asking for conflicts. Vanilla JS with no imports is the safest thing to put in someone else's page.

What the iFrame would have gotten right

I want to be fair to the alternative. An iFrame would have handled:

Complete CSS isolation. The host page's resets and overrides can't touch iframe content.
JavaScript isolation. A bug in our widget code can't throw an error that breaks the host page. With our inline script, a runtime error in initWall could theoretically interrupt a host page script that runs after ours. The JavaScript isolation point is real and we take it seriously. The embed script has a try/catch around the entire initialization:

try {
  initWall(container, slug);
} catch (e) {
  console.warn('[Proofly] Widget failed to initialize:', e);
  // silent failure — the container just stays empty
}

A failed widget initialization shows an empty div, not a broken page. That's the best we can do without the sandbox boundary.

Whether it was worth it

For our use case: yes. The height sync and mobile scroll problems were visible on every non-trivial host page. The background flash was the kind of thing that makes a product look unpolished in a demo. None of those go away with an iFrame without significant complexity.

The tradeoff is 1,140 lines of code we own and have to maintain, plus occasional CSS conflict reports from customers on unusual host configurations. We'd rather have the better default experience and handle edge cases than have the worse default experience and blame the iFrame.

If you're building an embeddable widget and your content is truly static — fixed height, no user interaction, no dark mode — an iFrame is still the answer. For anything dynamic, the direct DOM approach is worth the extra work.

From Lag Spike to Lightning Fast: The Engineering Behind Gaze Guard's Massive Performance Overhaul

Touseef Ibn Khaleel — Thu, 15 Jan 2026 17:47:19 +0000

As developers, we know the pain of a slow browser extension. The moment a tool designed to help you starts hogging resources, it becomes a liability. That was the challenge we faced with Gaze Guard, our image classification extension. The initial, naive implementation — a simple "scan everything all the time" approach — was functional but created noticeable performance bottlenecks on image-heavy sites.

We decided to go back to the drawing board and completely re-engineer the core scanning logic. The goal was simple: deliver powerful, real-time image classification with near-zero impact on the user's browsing experience. This article breaks down the eight key architectural changes that transformed Gaze Guard from a resource hog into a performance powerhouse.

1. Viewport-Based Scanning: The IntersectionObserver Revolution

The most significant change was moving away from classifying every image on the page immediately. This led to massive, synchronous classification spikes on page load.

The Fix: We adopted a viewport-based scanning strategy using the IntersectionObserver API.

Lazy Discovery: Images are only processed when they come near the viewport, using a generous rootMargin.
Minimal Workload: As soon as an image is handled (blurred or cleared), it is immediately unobserved. This keeps the observer's workload small and prevents the system from being overwhelmed by hundreds or thousands of off-screen elements.

This change alone eliminated the "big synchronous classification spikes" that plagued the previous version, ensuring a smooth initial page load.

2. Event-Driven DOM Updates: Replacing Polling with MutationObserver

The old architecture relied on "aggressive interval scanning" — a fixed timer that constantly woke up to check for new images. This is a classic anti-pattern for performance.

The Fix: We replaced polling with an event-driven approach using MutationObserver.

Initial Scan: A single, non-recurring scanImagesOnce() handles the initial page content.
Dynamic Content: For sites with infinite scroll or dynamic feeds, a MutationObserver watches for added nodes. It only scans the subtrees of the newly added elements.
Throttling: To handle bursts of DOM changes, the observer's callback is debounced by 100ms, collapsing multiple mutations into a single, efficient scan.

The result is that work only happens when the page actually changes, eliminating the constant, unnecessary overhead of fixed timers.

3. Batching and Throttling the ML Pipeline

Even with smart discovery, the machine learning classification process is the heaviest part of the workload. Running a large batch of classifications synchronously will inevitably freeze the UI.

The Fix: We introduced batching and cooperative scheduling for the ML pipeline.

Batch Processing: Images waiting for classification are put into an analysisQueue. The processQueue() function handles them in small batches (e.g., BATCH_SIZE = 5).
Yielding to the Browser: Crucially, between batches, the process yields to the browser using a tiny setTimeout(..., 5) and tf.nextFrame(). This allows layout and paint operations to run, keeping the UI responsive and preventing jank.
Timeouts: Each classification is wrapped in a timeout (TIMEOUT_MS = 3000). This prevents "stuck" images (due to slow network or bad CORS) from blocking the entire queue.

4. Caching Classification Results to Avoid Rework

Why classify the same image twice? On sites with repeated elements, or during back/forward navigation, re-running the ML model is pure waste.

The Fix: A robust, multi-layered verdict cache.

In-Memory Cache: srcVerdicts provides fast, O(1) lookups for the current session.
Persistent Cache: persistentVerdicts stores results in chrome.storage.local, ensuring that if a user navigates away and comes back, or even restarts the browser, known images are instantly recognized.

When an image is spotted, the extension checks the cache first. If a verdict exists, it immediately applies the blur or clears the image, skipping the entire classification pipeline.

5. Smarter and Cheaper DOM Operations (Micro-Optimizations)

Performance often comes down to avoiding expensive browser operations, particularly those that trigger layout thrashing (reflows).

Optimization	Old Approach (Expensive)	New Approach (Efficient)	Why it Matters
Image Dimensions	Accessing `element.width/height`	Using `naturalWidth / naturalHeight`	Accessing `element.width/height` can force a synchronous layout/reflow.
Background Images	Using `getComputedStyle`	Using only inline `element.style.backgroundImage`	`getComputedStyle` can also trigger reflows, while inline style access is cheap.
Irrelevant Content	Scanning all images	Skipping images smaller than 16x16px	Avoids wasting cycles on icons, tracking pixels, and other irrelevant elements.
Vector Graphics	Feeding SVGs to the raster classifier	Short-circuiting SVGs as "safe"	Prevents feeding vector graphics into a model designed for raster images, saving classification time.
DOM Traversal	`querySelectorAll('*')` deep scan	Targeted `findAllImages()` strategy	The previous deep scan was explicitly marked as "too expensive" and replaced with a targeted search for `<img>` tags and selective iframe handling.

6. More Efficient Model and Backend Usage

The machine learning model itself needs to be managed efficiently.

Model Caching: The NSFWJS model is loaded once and cached in memory, preventing repeated heavy initializations.
TensorFlow Backend: ensureTfReady() is used to enable TensorFlow.js production mode and allow it to select the best available backend (WebGL, WASM, etc.), rather than forcing a slower CPU-based backend.
Clean Cleanup: Dangerous blanket cleanup calls like tf.disposeVariables() (which could wipe model weights) were removed, ensuring the model stays "warm" and ready for immediate use.

7. Background Fetching for Problematic Images

Some images, particularly those with strict CORS policies or special hosting, can fail to load in the content script, leading to repeated, failing attempts.

The Fix: We defer to the background service worker (background.js).

For images that fail to load directly, the content script sends a message to the background worker, which fetches the image and returns a data URI. This offloads network details and retries to Chrome's more robust extension architecture, keeping the main content script simpler and less prone to getting stuck.

8. Turning Off Heavy Work on Unsupported Contexts

Finally, we prevent the extension from running in contexts where it can't or shouldn't work, such as PDF viewers.

Robust Detection: A comprehensive isPdfEnvironment() check detects PDF viewers based on URLs, content types, and embedded tags.
Immediate Stop: When a PDF is detected, stopAll() is called immediately. This cancels all observers, clears queues, and removes any existing blur markers, eliminating all overhead in a context where image classification is not useful.

Conclusion: Performance as a Feature

The performance improvements in Gaze Guard are not just a nice-to-have; they are a core feature. By applying principles of lazy loading, event-driven architecture, cooperative scheduling, and aggressive caching, we've managed to integrate a heavy machine learning workload into the browser without compromising the user experience.

This journey highlights that in extension development, optimizing for the DOM and the browser's event loop is just as critical as optimizing the core algorithm. We hope this deep dive provides valuable insights for anyone building performance-sensitive tools for the web.

Gaze Guard: Your Privacy-First AI Shield Against Unwanted Online Content

Touseef Ibn Khaleel — Wed, 14 Jan 2026 11:00:51 +0000

In today's digital landscape, the internet is an indispensable tool, but it often comes with the unwelcome surprise of inappropriate or distracting imagery. Whether you're browsing for work, studying, or simply enjoying your leisure time, encountering explicit or sensitive content can be jarring and disruptive. Traditional content filters often fall short, either by compromising your privacy or failing to keep up with the dynamic nature of the web. This is where Gaze Guard, a revolutionary Chrome extension, steps in to redefine your online experience with intelligent, privacy-focused content moderation.

Why Traditional Content Filters Miss the Mark

Many existing content filtering solutions operate by sending your browsing data, including images, to external servers for analysis. While this approach can block some content, it introduces significant drawbacks:

• Privacy Compromise: Your images and browsing habits are transmitted to third parties, raising legitimate concerns about data privacy and security.

• Performance Lag: The constant back-and-forth communication with remote servers can lead to noticeable delays, slowing down your browsing and making real-time content moderation less effective.

• Outdated Blacklists: Relying on static blacklists means these filters often fail to catch newly emerging or dynamically generated inappropriate content, leaving gaps in your protection.

Gaze Guard was engineered from the ground up to overcome these limitations, offering a superior, user-centric solution.

The Power of On-Device AI: Unmatched Privacy and Speed

The true innovation behind Gaze Guard lies in its groundbreaking use of on-device AI. This means all image analysis and content detection happen directly within your Chrome browser, eliminating the need to send any data to external servers. This commitment to local processing ensures your privacy remains absolute while delivering lightning-fast performance.

At its core, Gaze Guard leverages a sophisticated tech stack:

• TensorFlow.js: The robust open-source library that enables machine learning models to run efficiently within the browser environment.

• NSFWJS: A specialized, pre-trained model built on TensorFlow.js, expertly designed for accurate detection of Not Safe For Work (NSFW) content across various categories.

• MobileNet V2: A lightweight yet powerful neural network model, optimized for performance on client-side devices. This ensures Gaze Guard can classify images in real-time without bogging down your system.

This powerful combination allows Gaze Guard to intelligently identify and blur inappropriate images as you browse, all without ever compromising your data or slowing down your internet speed. It's a genuine privacy-focused AI content filter that puts you in control.

Seamless Integration and Intuitive Control

Gaze Guard is designed for effortless integration into your daily browsing routine. Once installed, it works silently in the background, constantly scanning for potentially sensitive content. However, you're always in command:

• Real-time Blurring: Images identified as inappropriate are instantly blurred, providing an immediate visual shield.

• Customizable Sensitivity: Adjust the detection threshold to match your personal comfort level, making the blurring more or less aggressive as needed.

• Category Selection: Choose which specific categories of content (e.g., Porn, Hentai, Sexy) you wish to have blurred.

• Click-to-Reveal: Accidentally blurred an image you wanted to see? Simply click on it to temporarily reveal the content, giving you full control.

Under the hood, Gaze Guard employs smart optimizations like MutationObserver to detect dynamically loaded images and IntersectionObserver to only process images currently in your viewport. This ensures comprehensive coverage without wasting resources on unseen content.

Open Source: Transparency You Can Trust

In an age where trust is paramount, Gaze Guard stands out with its commitment to transparency. The entire project is open source, meaning its code is publicly available for anyone to inspect and verify. This not only fosters community collaboration but also provides undeniable proof of its privacy claims – no hidden data collection, just pure, on-device protection.

Explore the codebase and contribute to its development on GitHub: https://github.com/realtouseef/gaze-guard

Elevate Your Browsing Experience Today

Say goodbye to unexpected distractions and reclaim your online peace of mind. Gaze Guard offers a robust, intelligent, and completely private solution to content moderation. It's more than just an extension; it's your personal guardian, ensuring a safer and more focused browsing environment.

Ready to experience the future of content filtering? Add Gaze Guard to your Chrome browser today:

Install Gaze Guard from the Chrome Web Store

Transform your browsing with the power of on-device AI – discreet, fast, and utterly private. Get Gaze Guard and browse with confidence.

Keywords: Chrome extension, AI content filter, privacy-focused, NSFW blocker, on-device AI, blur inappropriate images, content moderation, TensorFlow.js, NSFWJS, MobileNet V2, web privacy, safe browsing.

Gaze Guard: How On-Device AI is Revolutionizing Content Moderation in Your Browser

Touseef Ibn Khaleel — Wed, 14 Jan 2026 10:24:29 +0000

In an increasingly digital world, navigating the vast ocean of online content can sometimes feel like walking through a minefield. Unwanted or inappropriate imagery can pop up unexpectedly, disrupting workflows or causing discomfort. While many content filters exist, they often rely on server-side processing, raising privacy concerns and introducing latency. This is where Gaze Guard, an innovative Chrome extension, steps in, offering a refreshing, privacy-first approach to content moderation right within your browser.

GitHub: https://github.com/realtouseef/gaze-guard

The Problem with Traditional Content Filters

Before diving into Gaze Guard's solution, it's worth considering the limitations of conventional content filtering. Most solutions involve sending your browsing data, including images, to external servers for analysis. This process comes with inherent drawbacks:

Privacy Concerns: Transmitting images to third-party servers means your browsing habits are no longer entirely private. For many, this is a significant compromise.
Latency and Performance: The round trip to a server for analysis introduces delays, leading to a noticeable lag in content filtering, especially on dynamic web pages.
Dependence on Blacklists: Many filters rely on pre-defined blacklists of URLs. This approach struggles with new or dynamically generated content, often failing to catch emerging inappropriate material.

Gaze Guard was conceived to address these issues, providing a robust, real-time, and entirely private content filtering experience.

The Brains Behind the Blur: On-Device AI

The core innovation of Gaze Guard lies in its commitment to on-device AI. Instead of sending your data elsewhere, the heavy lifting of image analysis happens directly within your Chrome browser. This is made possible by a powerful combination of technologies:

• TensorFlow.js: This library allows machine learning models to run entirely in the browser, leveraging the user's local computing power.

• NSFWJS: Built on top of TensorFlow.js, NSFWJS is a specialized library designed for detecting Not Safe For Work (NSFW) content.

• MobileNet V2: Gaze Guard utilizes a lightweight yet effective pre-trained model called MobileNet V2. Optimized for edge devices, it strikes an excellent balance between classification accuracy and computational efficiency.

This trio enables Gaze Guard to perform real-time image classification without ever sending your images to an external server.

Deconstructing Gaze Guard: An Architectural Deep Dive

To truly appreciate Gaze Guard, let's examine its architecture, as revealed by its open-source GitHub repository. The extension is built upon the modern Chrome Extension Manifest V3, ensuring it adheres to the latest security and performance standards.

The Manifest: The Extension's Blueprint

The manifest.json file is the heart of the extension, defining its properties and permissions. Gaze Guard's manifest reveals several key aspects:

• Permissions: It requests activeTab and storage to save user settings locally. Crucially, it does not request broad access to your browsing history.

• Content Scripts: The manifest injects libs/nsfwjs.min.js, tf.min.js, styles.css, and content.js into every web page. This means the AI model and the core logic are loaded directly into the context of the page you're viewing.

• Background Service Worker: background.js runs in the background, handling events and managing the extension's state.

The Content Script: The On-Page Sentinel (content.js)

The content.js file is the most critical component, responsible for the real-time detection and blurring of images. Its sophisticated logic ensures efficient content moderation:

Model Loading: Upon page load, content.js initializes and loads the NSFWJS model. Since the model files are bundled with the extension, this process is fast and doesn't require external network requests.
Image Detection: The script scans the DOM for <img> tags and background images. To handle dynamic content like infinite scrolling feeds, it employs a MutationObserver to detect new images as they are added.
Performance Optimization with IntersectionObserver: Gaze Guard uses an IntersectionObserver to only process images that are currently within the user's viewport. This significantly reduces unnecessary processing, leading to a smoother browsing experience.
Classification Logic: Once an image is detected in the viewport, it's converted into a tensor and analyzed by the model. If the probability for categories like Porn, Hentai, or Sexy exceeds the user-defined threshold (defaulting to 50%), the image is flagged.
Censoring Action: For flagged images, Gaze Guard applies a CSS class, gaze-guard-blur, which visually blurs the content. A thoughtful feature allows users to click on a blurred image to temporarily reveal it.
Intelligent Caching: To avoid redundant work, Gaze Guard stores classification "verdicts" in chrome.storage.local. If the same image URL is encountered again, the extension quickly retrieves its previous verdict without re-running the AI model.

The Background Script: The Silent Manager (background.js)

While content.js is on the front lines, background.js operates behind the scenes. Its primary responsibilities include:

Settings Management: It acts as the central hub for storing and retrieving user preferences, such as sensitivity and selected categories.
CORS Bypass: Gaze Guard includes a mechanism in background.js to fetch images that might otherwise be blocked by Cross-Origin Resource Sharing (CORS) policies, converting them into Data URLs for safe processing by the content script.

The Unseen Benefits: Privacy and Performance

Gaze Guard's design prioritizes the user in several ways:

• Uncompromised Privacy: Your images and browsing data never leave your browser. There are no external servers to trust and no third parties analyzing your content.

• Blazing Fast Performance: By eliminating network latency and optimizing image processing with IntersectionObserver and caching, Gaze Guard delivers near real-time moderation.

• Always Up-to-Date: Unlike blacklist-based filters, the AI model can adapt to new content patterns, making it more resilient to novel forms of inappropriate imagery.

• Transparency: Being open-source, anyone can inspect the code and verify its privacy claims, fostering trust and community involvement.

Conclusion

Gaze Guard stands out as a pioneering example of how on-device AI can empower users with greater control over their digital environment while upholding the highest standards of privacy. By bringing sophisticated machine learning directly into the browser, it offers a powerful, efficient, and transparent solution to the pervasive challenge of unwanted content. It's more than just an extension; it's a personal guardian for your gaze, ensuring a safer and more comfortable browsing experience without compromising your data.

In an era where digital privacy is paramount, Gaze Guard offers a glimpse into a future where intelligent tools work for us, on our terms, right where we need them most.