Keeping a website performant is mostly about not letting things rot.
I spend most of my week digging into server logs and realizing someone deployed a query that joins three tables without an index. That's the reality of it. You install something, it works for six months, and then slowly the database starts churning through requests like it's wading through mud. By the time people notice the site is slow, there's usually a trail of bad decisions stacked on top of each other. This phrase keeps coming up in search results and it means whatever people need it to mean in context. What matters is the actual work, not the wording around it. Most people skip this part because setting up monitoring feels like bureaucracy. It's not. It's the only way to know whether your changes are helping or making things worse. Lighthouse gives you a snapshot, but snapshots lie. You need continuous data. I use a combination of synthetics and real-user monitoring. Synthetics tell you what's broken. Real-user data tells you who's affected by it.
PageSpeed Insights runs the same test every time from the same location. That's useful for regression checking but useless for understanding why your actual users are experiencing slowness. The gap between lab data and field data is where most maintenance problems live.
Critical render path optimization.
First Contentful Paint and Largest Contentful Paint are the metrics that matter most for perceived performance. Everything else is secondary. I had a project recently where the LCP was 4.2 seconds and the page had a 98 performance score in Lighthouse. The issue was a hero image served at 2400 pixels wide when it displayed at 800 on screen. No responsive image srcset. Just one massive JPEG loading on every request. The fix took about twenty minutes. Implemented responsive images, added a webp fallback, and set proper width and height attributes. LCP dropped to 1.3 seconds. The performance score went to 62 because fixing one thing exposed five other small issues. That's normal. Fix the big ones first, then iterate.
Get the Full Details
Database queries are where performance dies.
Every content management system eventually becomes a query trap. The WordPress wp_postmeta table is the classic example. Meta fields stored as key-value pairs instead of normalized columns. A simple query that should take milliseconds becomes a full table scan. I found one site running twenty-three queries per page load just for post metadata. The hosting server had 64 cores and it was still choking. The solution wasn't fancy. Transient caching for repeated queries, object caching with Redis, and restructuring the schema for the most-hit queries. I also removed three plugins that were each firing their own set of unnecessary queries. That last part is always the most painful because those plugins were doing things the developer liked. But they were generating 4,000 queries per hour on a low-traffic page.
CDNs are not a silver bullet.
I see a lot of people throw Cloudflare at a problem and call it solved. A CDN helps with static asset delivery and DDoS mitigation. It does nothing for your backend processing time. If your API endpoint takes two seconds to respond, a CDN in front of it will still return a two-second response. The cache TTL just needs to be set correctly so you're not hitting the origin on every request. The edge case I always run into is API-heavy SPAs. The content is dynamic, the CDN can't cache much, and the origin server bears the full load. For those situations, the answer is usually API response caching at the edge or pre-rendering pages. I configured Vercel's ISR on a project once and cut average response times from 800ms to 120ms by generating static snapshots every six hours instead of rendering on every request.
JavaScript bundle size is still a problem.
We keep pretending this is solved. It's not. A fresh React app with default tooling ships roughly 150 kilobytes of JavaScript before any application code loads. On a slow 3G connection that's over four seconds of parsing and execution before the user sees anything interactive. Code splitting helps. Lazy loading routes helps more. Tree shaking depends on whether your bundler is actually configured to do it. I audited a dashboard application last month. The bundle was 340 kilobytes gzip-compressed because someone had imported the entire date-fns library instead of individual functions. The fix was a one-line change in the import statement. The bundle dropped to 89 kilobytes. That's the kind of thing that happens constantly because bundler configuration is not obvious to most developers.
Server-side rendering versus static generation.
This is the decision that determines your entire architecture. SSR gives you fresh content on every request. SSG gives you cached HTML at the edge. The wrong choice here causes cascading problems. I've seen e-commerce sites using SSR for product pages that never change during a browsing session. Those pages should be static. The server was handling ten thousand renders per minute for content that was identical across every request. Switching to SSG with incremental regeneration cut the server load by ninety percent. The product pages regenerated once per hour instead of per request. The only thing that stayed dynamic was the cart and checkout flow, which needed real-time data anyway.
Maintenance schedules that actually work.
Weekly audits of slow queries, monthly bundle size reviews, quarterly infrastructure cost checks. Most teams skip the weekly part because it feels tedious. That's why their databases degrade gradually without anyone noticing until something breaks. Set up automated alerts for query response times over five hundred milliseconds. Set up a monthly report that tracks your JavaScript bundle size trend. If it's growing every month, something is wrong. I also track Time to First Byte separately from Total Blocking Time. TTFB tells you about server responsiveness. TBT tells you about client-side work. When both are high, you have a fundamental architecture problem. When only one is high, the fix is usually straightforward.
