Diagnosis
Field data from the Chrome UX Report where available, plus lab profiling, waterfall analysis, main-thread traces and server response timing, to separate a slow server from a slow page.
Performance, Security & Care
Website speed optimization
Speed work fails when it is done by checklist. Someone enables every toggle in a performance plugin, the score goes up, and the site feels the same, because the actual bottleneck was a 4 MB hero image, or a database query without an index, or a third-party script blocking the main thread for 800 milliseconds.
The method that works is unexciting: measure with real data, find the largest single cost, fix that, measure again. Usually two or three changes account for most of the improvement.
How I work on it
Process
Adjusted to the job, but this is the shape it usually takes.
-
Measure honestly
Establish a baseline on the pages that matter commercially, not just the homepage.
-
Fix the biggest cost first
One change at a time so each improvement is attributable and reversible.
-
Re-measure
Confirm the change helped in the field, not only in a lab tool on fast Wi-Fi.
-
Protect the gains
Performance budgets and a note in the handover, so the improvement is not undone by the next plugin install.
Questions
Things people ask
Core Web Vitals are a real but modest ranking signal, and the field data Google uses is not the same as a lab score. Chasing 100/100 has diminishing returns; getting LCP under 2.5 seconds and eliminating layout shift for actual visitors is where the value is, mostly in conversion rather than ranking.
Possibly. Time-to-first-byte separates the two: if the server takes 1.5 seconds to produce the HTML, it is a backend problem regardless of what the host says. If TTFB is fast and the page still is not, the problem is in the frontend.
Almost always. The exception is heavy third-party embeds and carousels, sometimes the honest recommendation is to remove a feature, and that is your decision to make with the numbers in front of you.