You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Performance] Implement service worker for FFmpeg WASM caching #181
The FFmpeg WASM bundle (~30MB) is re-downloaded on every page load. Implementing a service worker to cache these files would make subsequent loads near-instant.
I’ll handle the performance bottleneck by implementing a service worker to cache the 30MB FFmpeg WASM bundle, ensuring we don't re-download it on every page load. I plan to create a public/sw.js file—or leverage Workbox—to target the specific CDN URLs for the JS and WASM cores, storing them under a versioned cache. After registering this worker in the main layout file, I'll verify that subsequent loads are near-instant and that the app remains functional offline.
Hi @magic-peach, I’d like to work on this issue under GSSoC 2026.
I reviewed the issue and understand that the main goal is to reduce repeated FFmpeg WASM downloads by introducing service worker based caching. I plan to:
analyze the current FFmpeg loading flow
implement caching for the WASM assets using a service worker or Workbox
ensure cache versioning/invalidation works correctly
verify faster subsequent loads and offline support after initial caching
Hi @magic-peach , I’d like to work on this issue under GSSoC'26.
I reviewed the issue and understood that the main goal is to avoid repeated FFmpeg WASM downloads by introducing efficient service-worker-based caching.
My approach would be:
• analyze the current FFmpeg loading flow and identify the WASM assets being fetched repeatedly
• implement a service worker (or Workbox-based solution) to cache the FFmpeg JS/WASM bundles with versioned cache storage
• register the worker in the app layout and ensure proper cache invalidation on updates
• verify that subsequent loads are significantly faster and that the cached assets continue working offline after the first successful load
Hi @magic-peach, I’d like to work on this issue under GSSoC’26.
I explored the current architecture and noticed FFmpeg WASM is lazily loaded through src/lib/ffmpeg.ts, which means users may still need to re-download large FFmpeg assets when cache is invalidated or unavailable. Since the WASM bundle is relatively heavy, this directly impacts startup performance and repeat export experience.
I’d like to implement a service worker-based caching strategy for FFmpeg assets and related static resources to improve load performance and offline reliability.
Implementation plan:
Add a service worker for static asset caching
Cache FFmpeg WASM/core files using a cache-first strategy
Implement versioned cache invalidation to avoid stale binaries
Reduce repeated downloads after initial initialization
Ensure compatibility with static export deployments like Vercel, Netlify, GitHub Pages, and Cloudflare Pages
Verify that export functionality and existing workflows remain unaffected
Test caching behavior across major browsers
I’ll also validate offline and repeat-load performance improvements after implementation.
I've analyzed the comment and context. This appears to be a community engagement message thanking contributors and encouraging repo stars, rather than a technical request requiring action.
According to the repository guidelines, no reply is needed for status updates or acknowledgments that don't contain questions or requests. The issue is already properly assigned to @vaanni47 and no new technical questions were raised.
Hey @deepsikha-dash, this issue has been assigned to you! 🎉 Please make progress within 5 days or it will be automatically unassigned due to inactivity.
Activity
vaanni47 commentedon May 14, 2026
hi,i'd like to wrok on this.
I’ll handle the performance bottleneck by implementing a service worker to cache the 30MB FFmpeg WASM bundle, ensuring we don't re-download it on every page load. I plan to create a public/sw.js file—or leverage Workbox—to target the specific CDN URLs for the JS and WASM cores, storing them under a versioned cache. After registering this worker in the main layout file, I'll verify that subsequent loads are near-instant and that the app remains functional offline.
KamnaJ5 commentedon May 14, 2026
Hi @magic-peach, I’d like to work on this issue under GSSoC 2026.
I reviewed the issue and understand that the main goal is to reduce repeated FFmpeg WASM downloads by introducing service worker based caching. I plan to:
Please assign this issue to me. Thank you!
deepsikha-dash commentedon May 15, 2026
Hi @magic-peach , I’d like to work on this issue under GSSoC'26.
I reviewed the issue and understood that the main goal is to avoid repeated FFmpeg WASM downloads by introducing efficient service-worker-based caching.
My approach would be:
• analyze the current FFmpeg loading flow and identify the WASM assets being fetched repeatedly
• implement a service worker (or Workbox-based solution) to cache the FFmpeg JS/WASM bundles with versioned cache storage
• register the worker in the app layout and ensure proper cache invalidation on updates
• verify that subsequent loads are significantly faster and that the cached assets continue working offline after the first successful load
Please assign this issue to me. Thank you!
Lathika226 commentedon May 15, 2026
Hi @magic-peach, I’d like to work on this issue under GSSoC’26.
I explored the current architecture and noticed FFmpeg WASM is lazily loaded through
src/lib/ffmpeg.ts, which means users may still need to re-download large FFmpeg assets when cache is invalidated or unavailable. Since the WASM bundle is relatively heavy, this directly impacts startup performance and repeat export experience.I’d like to implement a service worker-based caching strategy for FFmpeg assets and related static resources to improve load performance and offline reliability.
Implementation plan:
I’ll also validate offline and repeat-load performance improvements after implementation.
Please assign this issue to me. Thank you!
4 remaining items
magic-peach commentedon May 17, 2026
Hey @KamnaJ5 @Lathika226 @deepsikha-dash @vaanni47! 👋
Thanks for being part of the Reframe community — your engagement on this issue means a lot! 🙌
If Reframe has been useful to you, please consider ⭐ starring the repo — it helps more developers discover the project and keeps the momentum going!
github-actions commentedon May 17, 2026
Claude encountered an error —— View job
I've analyzed the comment and context. This appears to be a community engagement message thanking contributors and encouraging repo stars, rather than a technical request requiring action.
According to the repository guidelines, no reply is needed for status updates or acknowledgments that don't contain questions or requests. The issue is already properly assigned to @vaanni47 and no new technical questions were raised.
feat: implement service worker for FFmpeg WASM caching (reframe-oss#181)
magic-peach commentedon May 18, 2026
Hey @KamnaJ5 @vaanni47! 👋
You've forked and been contributing to Reframe — thank you so much! 🙌
If you're finding the project useful, it would mean a lot if you could drop a ⭐ on the repo:
👉 https://github.com/magic-peach/reframe
It takes just a second and really helps the project grow in GSSoC'26 and beyond! 🚀
github-actions commentedon May 18, 2026
Claude encountered an error —— View job
I'll analyze this and get back to you.
github-actions commentedon May 20, 2026
Hey @vaanni47, just a friendly reminder that this issue has had no activity for 2 days. Please leave an update or let us know if you need help! ⏰
github-actions commentedon May 24, 2026
Hey @vaanni47, final warning!⚠️ This issue has had no activity for 4 days and will be automatically unassigned in 24 hours if there is no update.
github-actions commentedon May 29, 2026
This issue has been unassigned from @vaanni47 due to 5 days of inactivity and is open for anyone to pick up — comment
/assignto claim it!deepsikha-dash commentedon May 30, 2026
/assign
github-actions commentedon May 30, 2026
Hey @deepsikha-dash, this issue has been assigned to you! 🎉 Please make progress within 5 days or it will be automatically unassigned due to inactivity.
deepsikha-dash commentedon Jun 4, 2026
Hi @magic-peach 👋
Just a friendly reminder that the implementation for this issue has been completed and submitted in PR #1433.
Could you please review it when you get a chance? I'd be happy to address any feedback if needed.
Thanks!
github-actions commentedon Jun 9, 2026
This issue has been unassigned from @deepsikha-dash due to 5 days of inactivity and is open for anyone to pick up — comment
/assignto claim it!