Feedback request: UX + performance review of two Manifest V3 extensions

[Salaria Labs]

Hi everyone,

I’m looking for feedback from experienced extension developers on a couple of small
Chrome extensions I built recently using Manifest V3.

Both were built to solve personal pain points, and I’m especially interested in
feedback around:
- MV3 best practices
- content script performance
- permissions scope
- UX/onboarding improvements

1) LinkedIn JobLens  
A client-side extension that filters LinkedIn job search results
(promoted jobs, Easy Apply roles, already-seen/applied jobs).
No scraping, no background polling — purely DOM-based filtering.

Chrome Web Store:
https://chromewebstore.google.com/detail/linkedin-joblens-%E2%80%94-smart/ffkelfoaaejkhdldmlbnglhpgpobiigp

2) ChatGPT Prompt Buttons  
A lightweight extension that adds reusable prompt buttons to ChatGPT
to avoid retyping common prompts. Uses local storage only.

Chrome Web Store:
https://chromewebstore.google.com/detail/chatgpt-prompt-buttons-%E2%80%93/ibpaonngaabikigmifpnajnnhoccmmbm

I’m not trying to promote these here — genuinely looking for guidance
from folks more experienced with Chromium extensions.

Any thoughts on architecture, UX tradeoffs, or things you’d do differently
would be really appreciated.

Thanks in advance,
Salaria Labs

[woxxom]

To improve performance you should measure it in devtools performance profiler and see if there's anything worth optimizing.

1. handleUrlChange misses many events because spoofing the original methods only works in the [unsafe] MAIN world. Instead, you can either use `navigation.onnavigate` event in Chrome or simply compare location.href to an old value inside your MutationObserver callback. Once you have this you may be able to remove setInterval polling entirely.

2. UX/onboarding can be improved by implementing a workaround for Chrome's user-hostile lack of automatic injection of content scripts in the existing tabs upon extension installation/upgrade, see https://stackoverflow.com/a/11598753. You'll need a background script for that, but since it only listens to onInstalled event fired upon install/upgrade it's not wasteful.

3. You can explicitly disconnect your MutationObserver when modifying DOM and re-start it afterwards to avoid triggering it unnecessarily.