Skip to main content
Beta: Front-End Checklist is currently in beta. Some issues are still being fixed. Thanks for your patience.

Avoid JavaScript-based redirects

Detects JavaScript resources that return 3XX redirects to reduce latency

Utilities
Quick take
Typical fix time 10 min
  • 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
Why it matters: JavaScript redirects force an additional round-trip after the initial page load, significantly increasing the time users spend waiting for content.

Rule Details

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)
export async function getServerSideProps() {
  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 (opens in new tab) 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

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.

Use with AI

Copy these prompts to use with your AI assistant, or install the MCP server to use directly from Claude, Cursor, or Windsurf.

Check

Verify implementation

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

Fix

Auto-fix issues

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

Explain

Learn more

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

Review

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.

Sources

References used to support the guidance in this rule.

Further Reading

Tools and supplementary material for exploring the topic in more depth.

PageSpeed Insights
pagespeed.web.devTool

Rules that often go hand-in-hand with this one.

Optimize Google Tag Manager implementation

Configure Google Tag Manager efficiently to minimize its impact on page load speed and main-thread blocking.

Performance
Reduce Time to First Byte (TTFB)

Measures and optimizes server response time (TTFB) to ensure a fast initial response

Performance
Enable browser caching

Cache-Control and ETag headers are properly configured for static resources.

Performance
Convert animated GIFs to video

Large animated GIFs are replaced with more efficient video formats like MP4 or WebM to reduce page weight.

Performance

Was this rule helpful?

Your feedback helps improve rule quality. This stays internal for now.

Loading feedback...
0 / 385