In early 2025, we at Hackathon Raptors organized the BrowserBuddy Hackathon (February 3–11, 2025)—an event challenging developers to build efficient browser extensions within Google’s Manifest V3 constraints. Although Manifest V3 has been the standard for Chrome extensions for several years now, many developers continue to struggle with its limitations.
Technical Leadership and Expertise
Our technical advisor and judge for the hackathon, Denys Sidorov, brought critical expertise as a Senior Software Engineer with extensive experience in event-driven architectures and performance optimization. His guidance on service worker lifecycle management and efficient data handling within Manifest V3’s constraints proved invaluable for the organizing team and participants. Throughout the event, Denys’s techniques for resource optimization and insights on efficient coding patterns—developed through his work at companies like Retriever and RelationDesk—helped shape our evaluation metrics and technical requirements.
Why Browser Extensions?
We chose browser extensions as the hackathon’s focus because they operate under stringent resource constraints and strict security policies. Manifest V3 further elevates these demands by limiting background page usage and requiring service workers. Developers in the hackathon needed to tackle:
- Event-Driven Architecture: Handling real-time changes, such as tab activation or user input, without consuming excessive CPU cycles.
- Strict Permissions: Manifest V3 only grants certain privileges, forcing a more thoughtful approach to data access and storage.
- Performance Trade-Offs: Every script and network call can affect page load times, so participants had to optimize code for minimal overhead.
These constraints align well with real-world production scenarios, where memory usage, security, and usability often become critical bottlenecks.
Influences from Denys Sidorov
Denys has worked on frontend optimization and API performance at companies like Retriever and RelationDesk. His background shaped the technical bar for BrowserBuddy in several key areas:
- Manifest V3 Usage
- Service workers replace background pages, requiring an asynchronous event-based approach.
- Denys stressed the importance of fully embracing these changes to future-proof participants’ skills.
- Efficient Data Handling
- He encouraged lean data storage—local storage, IndexedDB, or minimal server calls—so the extension remains responsive.
- Teams needed to measure memory overhead, ensuring they didn’t burden the browser.
- Analytics That Matter
- Basic metrics (e.g., session duration) were just a starting point. Denys pushed for advanced visualizations or predictive insights.
The Technical Bar: What We Looked For
Our guidelines covered three major areas:
- Manifest V3 Compliance
- Correct use of service workers, minimal permission sets, and event-driven scripts.
- Adherence to Chrome’s documented security best practices, such as avoiding overly broad host permissions.
- Performance & Resource Management
- Extensions should run without significantly affecting page load times or memory usage.
- We asked participants to capture metrics like peak CPU usage, memory overhead, and the number of network requests to confirm efficiency.
- Analytics & Data Output
- Submissions needed to provide clear, actionable data, not just raw logs.
- Visual or numeric representations (e.g., charts, dashboards) were highly encouraged.
Example: Focus Time Tracking
Below is a minimal snippet that logs session durations per tab. Teams commonly extended this logic with local storage, scheduled data aggregation, or predictive modeling:
class FocusTracker {
constructor() {
this.startTime = null;
this.focusData = [];
}
startTracking() {
this.startTime = Date.now();
chrome.tabs.onActivated.addListener(this.handleTabSwitch.bind(this));
}
handleTabSwitch(activeInfo) {
const duration = (Date.now() - this.startTime) / 1000;
this.focusData.push({ tabId: activeInfo.tabId, duration });
this.startTime = Date.now();
}
getAnalytics() {
return this.focusData.reduce((acc, entry) => acc + entry.duration, 0);
}
}This approach uses Chrome’s event APIs to track time without constant polling. This architecture effectively leverages the constraints of Manifest V3, ensuring background tasks run only when triggered by specific events.
How We Evaluated Submissions
We used a scoring rubric to balance technical execution, analytics depth, and practical application:
- Technical Execution (40%)
- Code readability, maintainability, and correctness under Manifest V3.
- Resource usage, including peak memory footprint and CPU utilization.
- Analytics & Data Handling (30%)
- Collection, storage, and visualization of meaningful metrics.
- Clarity in data representation: a chart that quickly shows daily focus time per tab.
- Practical Application (30%)
- Direct relevance to user needs: does it address productivity, security, or another real-life gap?
- Potential for further development or integration with larger systems.
Performance Formulas
Beyond the fundamental ratio we used for overall efficiency, we also introduced additional metrics:
- Efficiency Score
Efficiency Score = (Requests Processed / CPU Cycles) × Data Accuracy
It helps measure the trade-off between performance overhead and the correctness of analytics. - Memory Overhead
Memory Overhead = (Extension’s Peak Memory / Browser Memory Baseline) × 100%
Assesses how much the extension inflates the browser’s normal resource usage.
Combining these formulas with qualitative factors (like user-friendliness) gave us a clearer picture of each project’s strengths and weaknesses.
Our Internal Preparation
- Topic Validation: We tested various Manifest V3 features in-house, confirming that security and performance restrictions would challenge participants without being unreasonably complex.
- Resource Provision: Participants received quick-start examples, official Chrome docs, and recommended libraries (like amCharts or Chart.js). These resources aimed to reduce boilerplate overhead.
- Stretch Goals: We encouraged advanced teams to explore AI-driven analysis (e.g., local classification of browsing patterns), or worker threads for parallel data processing.
Results and Lessons
During the hackathon, we saw innovative approaches to focus tracking, real-time analytics, and task automation. Submissions that excelled typically:
- Used service workers effectively, with no persistent background pages.
- Maintained a low Memory Overhead ratio while still producing insightful analytics.
- Presented data in dashboards that balanced clarity with technical depth.
By emphasizing Manifest V3 and resource-aware design, the BrowserBuddy Hackathon helped participants practice building robust, secure software for modern web environments. The most successful teams demonstrated service worker lifecycle management mastery, achieving average memory footprints 42% lower than typical extensions while maintaining responsive user interfaces. Several teams implemented advanced optimization techniques such as dynamic module loading and strategic use of IndexedDB for efficient data persistence. Notably, the winning team’s extension processed over 10,000 tab events per minute while maintaining CPU utilization below 2% and achieving a 94ms average response time for user interactions.
These technical achievements underscore the value of working within constraints rather than fighting against them. By the end of the hackathon, 78% of participants reported increased confidence in building performant Manifest V3 extensions, with 65% indicating they planned to refactor existing projects to incorporate the resource optimization patterns they learned. This aligns with Hackathon Raptors’ philosophy of pushing developers to adopt best practices and refine their engineering skills through practical, challenging technical scenarios that mirror real-world development constraints.
Next in Our Raptors Internal Series
Stay tuned for “Scalability Under Pressure” where our infrastructure team explains how to manage sudden traffic spikes and ensure the high availability of production services.