Apply modern web development best practices for security, compatibility, and code quality. Use when asked to "apply best practices", "security audit", "modernize code", "code quality review", or "check for vulnerabilities".

Best practices Modern web development standards based on Lighthouse best practices audits. Covers security, browser compatibility, and code quality patterns. Evidence led audit workflow When a rendered page is available: 1. Run a live Lighthouse Best Practices audit when that capability is available; with Chrome DevTools MCP, use lighthouse audit . Use navigation mode for a normal page load or snapshot mode when the current state must be preserved. 2. Inspect the listed console and network failures and fetch individual details only when they support a finding. 3. Supplement runtime evidence with dependency, header, configuration, and source inspection; Lighthouse is not a complete security assessment. 4. Fix the implicated code, re run the same audit, and keep security findings separate from style preferences. If live tools are unavailable, use the Lighthouse CLI plus focused dependency and header checks. Never report a high Lighthouse score as proof that the application is secure. Security Read [the security reference](references/SECURITY.md) when security is in scope or a live audit surfaces a related failure. It covers HTTPS/HSTS, CSP and Trusted Types, Subresource Integrity, headers, dependencies, sanitization, and cookies. At minimum: Use HTTPS without mixed content. Add HSTS only after confirming every relevant subdomain supports HTTPS. Treat a strict CSP as defense in depth. Prefer nonces or hashes and test with report only before enforcement. Sanitize untrusted HTML and protect DOM XSS sinks. Prefer text APIs when markup is not required. Pin and review third party code. Use SRI where the delivery model supports it and keep dependencies patched. Verify response headers at runtime. Source configuration alone does not prove what the deployed page sends. Browser compatibility Doctype declaration Character encoding Viewport meta tag Feature detection Polyfills (when needed) Prefer bundling polyfills at build time (Babel/SWC + core js , or @vitejs/plugin legacy ) targeted by your supported browsers list. This eliminates the runtime check entirely and avoids shipping polyfill bytes to modern browsers. If you must load a polyfill at runtime, append a script element — never use document.write (it blocks the parser and is broken in async/deferred contexts): Never load polyfills from a third party CDN you don't control. The polyfill.io service was [compromised in mid 2024](https://sansec.io/research/polyfill supply chain attack) in a supply chain attack and used to serve malware to ~100k sites. Self host, or use a vetted mirror (e.g. [Cloudflare's cdnjs polyfill build](https://blog.cloudflare.com/polyfill io now available on cdnjs reduce your supply chain risk/)) — and pin the version with [Subresource Integrity]( subresource integrity sri for third party scripts). Deprecated APIs Avoid these Event listener passive Console & errors No console errors Error boundaries (React) Global error handler Source maps Production configuration Strip sourcesContent from production maps when uploading to your error tracker. By default, bundlers embed the full original source inside the .map file — anyone who obtains the map (including via a misconfigured upload step) gets your unminified code. Configure your bundler to omit sourcesContent , or use a Sentry/Bugsnag CLI flag that does so when uploading. For Vite, prefer sourcemap: 'hidden' over 'true' so the // sourceMappingURL= comment isn't emitted into the bundle. Performance best practices Avoid blocking patterns Efficient event handlers Memory management Code quality Valid HTML Semantic HTML Image aspect ratios Permissions & privacy Request permissions properly Permissions policy Audit checklist Security (critical) [ ] HTTPS enabled, no mixed content [ ] No vulnerable dependencies ( npm audit ) [ ] CSP headers configured (with frame ancestors , base uri , form action ) [ ] require trusted types for 'script' enforced (or report only during rollout) [ ] Third party <script / <link rel="stylesheet" pinned with SRI hashes [ ] Security headers present (HSTS, X Content Type Options, Referrer Policy) [ ] No exposed source maps (and sourcesContent stripped from uploaded ones) Compatibility [ ] Valid HTML5 doctype [ ] Charset declared first in head [ ] Viewport meta tag present [ ] No deprecated APIs used [ ] Passive event listeners for scroll/touch Code quality [ ] No console errors [ ] Valid HTML (no duplicate IDs) [ ] Semantic HTML elements used [ ] Proper error handling [ ] Memory cleanup in components UX [ ] No intrusive interstitials [ ] Permission requests in context [ ] Clear error messages [ ] Appropriate image aspect ratios Tools Tool Purpose npm audit Dependency vulnerabilities [SecurityHeaders.com](https://securityheaders.com) Header analysis [W3C Validator](https://validator.w3.org) HTML validation Live Lighthouse audit (Chrome DevTools MCP: lighthouse audit ) Rendered Best Practices checks for agents Lighthouse CLI Best Practices audit fallback [Observatory](https://observatory.mozilla.org) Security scan References [MDN Web Security](https://developer.mozilla.org/en US/docs/Web/Security) [OWASP Top 10](https://owasp.org/www project top ten/) [Web Quality Audit](../web quality audit/SKILL.md)

best-practices