Need help fixing my web app after recent update

Apps
1

After a recent update, my web app started acting weird: some pages load slowly, certain buttons don’t respond, and users are reporting random errors in the console. I tried rolling back a few changes, clearing caches, and checking my server logs, but I still can’t pinpoint what’s causing these issues. Can someone help me figure out what I should check next and how to systematically debug and stabilize my web app so it works reliably again?

2

First step, get data instead of vibes.

  1. Turn on errors and logging
    • In browser devtools, Network tab, check slow pages.
    Look for
  • Long TTFB (server issue)
  • Big JS bundles or large images
    • In Console, filter by “Error” and “Warning”.
    Copy the exact stack traces.
    • In your backend logs, match timestamps from slow requests.

  1. Narrow down the update
    You said you rolled back “a few” changes. Try a real binary search on commits.
    • Check out commit from 2 weeks before the issue. Test.
    • Move forward halfway. Test again.
    Repeat until you pin the bad commit.
    This is much faster than random rollbacks.

  2. Check front end regressions
    Typical causes after updates:
    • New event listeners on buttons not attached because:

  • Wrong selector
  • Code runs before DOM ready
  • Component unmounted or conditional render changed
    • Version bumps of libs like React, Vue, jQuery, Axios, some UI kit.
    Look for breaking changes in release notes.
    • New global error handler swallowing errors.
    Comment out any window.onerror or error boundary and see if behavior changes.

Concrete steps:
• For a broken button, open devtools, Event Listeners tab. Confirm a click handler exists.
• Run getEventListeners($0) in console after selecting the button.
• Manually trigger the handler function in console with mock params, see if it throws.

  1. Check network and API changes
    Random console errors often come from API mismatches.
    • In the Network tab, watch for 4xx or 5xx on slow or broken views.
    • Compare response shape to what the frontend expects.
    For example, code expecting data.items and API now returns data.results.
    • If you changed CORS, auth headers, or cookies, verify:
  • Cookies are sent with Secure and SameSite set correctly.
  • No mixed content after a TLS config change.
  1. Performance issues
    • Look at the Performance tab, record a run on a slow page.
    See if the time is in:
  • Scripting (big loops, heavy rendering)
  • Rendering (layout thrash, heavy DOM)
  • Idle (server response slow)
    • Common recent-update issues:
  • Infinite re-renders after a state logic change.
  • New polling interval set too low, spamming API.
  • Large third party script added synchronously.

  1. Cache and deploy layer
    Not only browser cache.
    Check:
    • CDN or reverse proxy cache rules changed?
    • Stale JS served from CDN while HTML points to new assets?
    Mismatch versions can cause random runtime errors.
    • Ensure asset filenames are hashed and HTML references match the deployment.

  2. Reproduce systematically
    • Get exact browser + OS from users.
    • Try to reproduce on:

  • Latest Chrome
  • A “slow” device or throttled CPU / network
    • Turn on “Preserve log” in console.
    • Record one clear sequence:
  1. Go to page X
  2. Click button Y
  3. See error Z in console
  1. If you use a framework
    React:
    • Check for warnings about keys, controlled vs uncontrolled, strict mode double invoke.
    • Watch for state updates in useEffect without dependencies, leading to loops.

Vue:
• Watch computed props that mutate state.
• Check for deprecated APIs if you updated Vue version.

Angular:
• Check for change detection errors in console.
• Look for async pipe or subscription changes.

  1. Quick triage trick
    Create a temp branch and:
    • Comment out new features or big refactors.
    • Deploy to a staging URL.
    • Share with an affected user and see if issues vanish.
    If they do, the bug sits inside the part you commented.

  2. Share more details if you want:
    • Framework and versions
    • Example console error text
    • Screenshot or HAR from Network tab
    With those, folks can point at a concrete root cause instead of guessing.

3

The stuff from @viajantedoceu is solid, but I’d attack this a bit differently so you don’t get stuck in “infinite debugging mode”.

First, stop changing prod blindly. Spin up a local or staging env that matches prod as close as you can:

  1. Same env vars
  2. Same build pipeline (same Node version, bundler config, minification)
  3. Same backend version / DB schema

A lot of “random” console errors only show up after minification or when env flags change.

1. Check your build artifacts, not just the code

Recent update + random console errors + some buttons dead smells like a bad bundle or mismatched assets.

  • Open the HTML source of the slow page and check your JS file names.
  • Compare those to what’s actually served by your server/CDN.
    • If you see app.abc123.js in HTML but server gives app.def456.js or a 404, you’ll get weird runtime behavior.
  • Disable source maps temporarily and see if behavior changes. Corrupt maps or weird sourceMap config can break some error tooling.

Also, if you added tree shaking or changed bundler config, you may have shaken away side‑effect imports that were actually needed to wire up event handlers.

2. Feature flags / config toggles

Recent releases often sneak in:

  • “Quick toggle” features behind env flags
  • New API base URLs
  • Different auth / cookie names

Check your:

  • .env vs .env.production vs CI/CD secret values
  • Any runtime config JSON your app fetches at startup

Example problem: frontend expects FEATURE_X_ENABLED=true, but prod has true as string and your check is if (FEATURE_X_ENABLED === true). Suddenly half the UI logic silently skips.

3. DOM-related regression checks

Instead of just seeing if a handler exists like suggested, verify the DOM and state flow:

  • On a broken button, in devtools:
    • Run document.activeElement after clicking. If something weird is stealing focus or overlaying elements, click might not hit the intended button.
    • In the Elements tab, toggle :hover / :active and check for z-index or pointer-events issues.
  • If you recently changed CSS frameworks or global styles, look specifically for:
    • pointer-events: none on ancestors
    • position: absolute overlays covering the button
    • opacity: 0 but still intercepting clicks

A lot of “button doesn’t respond” bugs end up being CSS, not JS.

4. Database and schema side

Slow pages and random errors right after a deploy can also be:

  • New queries without proper indexes
  • N+1 queries introduced by a “small” ORM refactor
  • Changed column defaults that break serialization

Check:

  • DB slow query logs for the exact routes that correspond to slow pages
  • If any migration ran with:
    • New ORDER BY or JOIN on unindexed columns
    • Casting / JSON columns changed

You can profile one of the slow endpoints directly from the backend and compare with a fast one from before the update if you have APM or query logs.

5. Look for partial rollbacks / mixed code paths

You said you tried rolling back “a few changes”. That is often worse than no rollback.

  • Verify that frontend version and backend version are compatible:
    • If frontend expects api/v2 but some routes still point to v1, random console errors and type mismatches will pop up.
  • Check any shared types / DTOs or OpenAPI / Swagger contracts. If you updated only one side of the contract, you’ll see intermittent issues based on which feature path is hit.

If possible, either:

  • Roll back the entire app to a known good tag
    or
  • Move everything forward and fix incompatibilities deliberately

Half-rollbacks create “Schrödinger’s bug”.

6. Instrumentation instead of guessing

If you don’t already have this:

  • Add a global window.onunhandledrejection and window.onerror that sends errors to your backend temporarily.
  • Log:
    • location.href
    • user agent
    • anonymized user id or session id
    • the stack trace and message

Then you can group errors and see:

  • “This specific stack trace is happening only on Safari 16”
  • “This occurs only on the dashboard page with feature X enabled”

This beats manually asking users “what happened?” 20 times.

7. Performance from the code perspective

Instead of only looking at browser Performance tab like mentioned:

  • Check if you recently:
    • Enabled React strict mode in prod by mistake
    • Switched to client-side rendering where it used to be SSR
    • Added a heavy dependency (date libraries, chart libs, rich text editors)

Quick isolation trick:

  • In a staging build, comment out imports of recently added big libs and replace them with placeholders.
  • If the slow page suddenly becomes fast, you know which dependency to profile.

Also, verify that you’re not accidentally running dev mode in prod. For example:

  • React dev build
  • Vue with devtools / warnings enabled
  • Webpack dev server proxy used in a weird way

Those can kill performance instantly.

8. Deployment pipeline sanity check

Since caches and basic rollback attempts didn’t help, check:

  • Did CI switch Node versions, or did you change target in TS/Babel so older browsers choke?
  • Any post-deploy hook that modifies files, injects SRI hashes, or rewrites URLs that could corrupt bundles?
  • Are you gzipping/brotli correctly or serving a truncated bundle?
    • Compare file size on disk vs what Network tab shows. Truncated JS will often throw random syntax/runtime errors.

If you can share:

  • A single example console error string
  • One specific slow URL and whether it’s slow on first load vs navigation
  • Framework / stack (React/Vue/Angular/SPA with vanilla, etc.)

people can probably point to a much more specific root cause instead of generic “check logs” advice.