Js Redirects

Avoid JavaScript-based redirects

JavaScript redirects force an additional round-trip after the initial page load, significantly increasing the time users spend waiting for content.

Quick Reference

• Use 301 or 302 server-side redirects instead of window.location
• JS redirects delay page load as the browser must first download and execute the script
• Client-side redirects can negatively impact SEO and indexability

Check

Check the project for instances where JavaScript is being used for page-level redirects (e.g., window.location).

Fix

Replace JavaScript-based redirects with server-side 301 or 302 redirects in your web server or edge configuration.

Explain

Explain why server-side redirects are faster and more SEO-friendly than client-side JavaScript redirects.

Code Review

Review the routes, assets, and loading behavior that affect Avoid JavaScript-based redirects. Flag exact files, requests, or rendering steps that add unnecessary network, CPU, or layout cost, and describe the measurement method used to confirm the issue.

---

For full implementation details, code examples, and framework-specific guidance, see references/rule.md.

Rule page: https://frontendchecklist.io/en/rules/performance/js-redirects

Avoid JavaScript-based redirects

Detects JavaScript resources that return 3XX redirects to reduce latency

Priority: medium · Difficulty: intermediate · Time: 10 min

--- JavaScript redirects (using window.location, window.location.href, or window.location.replace) are inefficient and add unnecessary latency to the user experience.

Code Examples

#

Avoid Client-Side Redirects

// ❌ Bad: Redirecting via JavaScript
if (userIsLoggedIn) {
  window.location.href = '/dashboard';
}

Use Server-Side Redirects

// ✅ Good: Server-side redirect (Next.js Example)

  if (userIsLoggedIn) {
    return {
      redirect: {
        destination: '/dashboard',
        permanent: false,
      },
    };
  }
}

HTML Meta Redirects

<!-- ⚠️ Avoid if possible, but better than JS -->
<meta http-equiv="refresh" content="0; url=https://example.com/">

Why It Matters

Server-side redirects are the baseline because web.dev's performance guidance and crawler behavior both reward fewer client-side hops before the final content is visible.

• Browser Processing: For a JS redirect, the browser must request the page, download the HTML, parse it, and then execute the script before initiating the redirect.
• Latency: This adds at least one full round-trip of latency compared to a server-side redirect, which happens immediately.
• SEO/Crawler Impact: While some modern search engines can follow JavaScript redirects, server-side 301 redirects are much more reliable for transferring SEO value (link equity).
• User Perception: Users may see a momentary "flash" of the original page before the redirect occurs, which is jarring.

Best Practices

✅ Server-Level Redirects: Use your web server configuration (e.g., .htaccess for Apache, nginx.conf for Nginx) or edge configuration (Cloudflare, Vercel). ✅ Handle at Edge: For dynamic redirects based on user state, try to handle them using Edge Functions to minimize the round-trip distance. ✅ Use 301/302 Status Codes: Use the correct HTTP status codes to communicate to both browsers and crawlers whether the redirect is permanent or temporary.

Tools & Validation

• Browser DevTools Network tab to check for 3xx responses.
• Use curl -I "$ORIGIN" or the live target URL to see the redirect headers.
• Ahrefs Redirect Checker
• HTTP Status Code Checker

Standards

• Use web.dev: Learn Performance as the standard for measuring the final production behavior, not just local synthetic output.
• Use Chrome Developers: Lighthouse overview as the standard for measuring the final production behavior, not just local synthetic output.

Verification

Automated Checks

• Measure the affected page or flow in Lighthouse, PageSpeed Insights, or DevTools and confirm the targeted metric improves.
• Inspect the network waterfall or performance timeline to confirm the intended resource or execution change actually took effect.

Manual Checks

• Verify the change on a throttled mobile profile, not just local desktop.
• If this rule maps to a budget or Web Vital, confirm the page now stays within that threshold.