Slow Website? How to Improve Page Speed and Core Web Vitals
Practical optimizations for TTFB, LCP, CLS, images, caching, and SSR to speed up web applications.
Erlan Carreira
Software Engineer & Entrepreneur
A slow website should be addressed with measurement, not with a random list of plugins. The safest path is to separate real user data from lab tests, locate the time-consuming step, and change one variable at a time. This tutorial shows how to do this without hiding the problem.
Direct answer: what to do when the site is slow
Test the URL on PageSpeed Insights on mobile and desktop. Note LCP, INP, CLS, and TTFB, open the Lighthouse diagnostics, and check the Network tab of the browser. Then fix the resource that forms the LCP first, reduce blocking JavaScript, stabilize element dimensions, and improve cache or server. Publish, measure again, and compare under the same conditions.
Understand the numbers before optimizing
PageSpeed combines two types of information. Field data comes from the Chrome UX Report and represents real visits from the last 28 days when there is a sufficient sample. Lab data simulates a visit and helps reproduce bottlenecks. A high score in the lab does not replace the real experience.
| Metric | Good | What usually worsens it |
|---|---|---|
| LCP | up to 2.5 s | heavy main image, font, slow CSS or server |
| INP | up to 200 ms | long JavaScript, heavy component, excess third parties |
| CLS | up to 0.1 | image without size, late banner, font swap |
These limits are evaluated at the 75th percentile. Fixing only the homepage may not resolve an entire group of URLs with the same template.
Step 1: reproduce the problem
Open an incognito window, disable extensions, and test the page on a network comparable to that of the audience. In Chrome DevTools, open Network, check Disable cache, and reload. Sort by duration and size. Observe the HTML document, the main image, fonts, CSS, JavaScript, and external calls.
Also use:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s Total: %{time_total}s\n" https://exemplo.com/paginaA high TTFB points to server, database query, remote function, or cache. A fast HTML followed by many seconds until the main image points to the front-end or media.
Step 2: fix the LCP
Find out which element is the LCP in the report. If it is an image, deliver AVIF or WebP in the correct visual size, specify width and height, use srcset, and do not apply lazy loading to the image that appears immediately. A preload only helps when the browser would discover the resource late; overused, it competes for bandwidth with essential items.
If the LCP is text, check fonts and CSS. Host only the weights used, prefer WOFF2, and set up a display strategy that does not leave the text invisible. Carefully remove unused CSS and load critical styles early.
Step 3: reduce the INP
Click on controls during a recording in the Performance tab. Long tasks block the main thread. Break down large processing, defer scripts that do not participate in the first interaction, and avoid recalculating the entire interface when only a part has changed.
Chat scripts, maps, video, A/B testing, and advertising also consume processing. Load them when needed and measure the cost of each provider. For AdSense, reserve ad space in advance and avoid inserting blocks that shift content.
Step 4: eliminate layout shifts
Set dimensions or aspect-ratio for images, videos, and ads. Do not inject warnings above the content after the page has appeared. For fonts, choose a system alternative with similar proportions. Reproduce the page slowly: the element that jumps often reveals the cause of the CLS.
Step 5: work on cache and server
Versioned files can receive long cache; dynamic HTML requires a policy consistent with content updates. Use CDN for public content, compress responses, and remove unnecessary redirects. On the back-end, log query times and external calls. Do not increase machine resources without knowing if the bottleneck is CPU, database, network, or code.
Validation checklist
- compare before and after on the same URL and device;
- test internal pages, not just the homepage;
- confirm that images remain sharp;
- check login, form, and menu after reducing scripts;
- monitor field data for at least 28 days;
- set up alerts for build and size regressions.
For a broader rebuild, see institutional site or landing page. If the bottleneck is in integrations, understand how to monitor APIs.
Frequently asked questions
Does installing cache solve any slow site?
No. Cache can reduce server and transfer, but it does not fix excessive JavaScript, disproportionate media, or layout shifts.
Is a score of 100 mandatory to appear on Google?
No. Relevance and quality remain fundamental. The goal is to provide a good experience and achieve consistent metrics, not to chase an isolated score.
Primary sources
Erlan Carreira
Software Engineer & Entrepreneur
Specialist in software development, automation, and SaaS. I write about technology, digital business, AI, and engineering practices for teams committed to execution excellence.