Behind the complaint "my website is slow" there are usually four causes: heavy images, ad pixels and analytics scripts that load the moment the page opens, animations that hide content, and weak server settings. To find the cause, measure your site in Google PageSpeed Insights in mobile mode and check the LCP, INP and CLS metrics. After Advertol fixed animations that started hidden, scripts that loaded instantly, and its server settings on its own website, the homepage's mobile score rose from 72 to 91 in September 2026.
Key takeaways:
- For a good page experience, Google wants LCP within 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1.
- The PageSpeed score is a lab test; the Core Web Vitals assessment is based on real Chrome users' data from the last 28 days.
- In August 2026, mobile devices accounted for 51.53% of web traffic in Azerbaijan, so measure speed on mobile first.
- In September 2026, advertol.az's homepage mobile score rose from 72 to 91, its desktop score from 89 to 100, and service pages that previously received no score at all scored 99 on the mobile test.
- The three fixes that usually pay off fastest: don't start above-the-fold content invisible, defer pixels and analytics, and compress and prioritise the main image.
- In Deloitte's global study for Google, speeding up a mobile site by 0.1 seconds raised retail conversions by 8.4%.
How is website speed measured, and what should you check in PageSpeed?
Website speed is measured in Google's free PageSpeed Insights tool (pagespeed.web.dev), and the report shows two separate results: real-user data and a lab test. Base your decision on the first result, and look for the cause in the second.
Field data is the real experience of Chrome users on your site over the last 28 days, drawn from the Chrome UX Report database (Google for Developers). The "Core Web Vitals Assessment" block at the top of the report is based on this data. If there isn't enough data for a specific page, PageSpeed shows the result for the whole domain instead; if that's missing too, field data doesn't appear at all. This is normal for new sites with little traffic.
Lab data is the result of Lighthouse loading the page once on a simulated device and network. The 0–100 performance score comes from here: 90 and above is good, 50–89 needs improvement, below 50 is poor. The lab result varies slightly from test to test, because network and server load vary.
Run the measurement in this order:
- Enter the page's URL at pagespeed.web.dev and check the "Mobile" result first.
- Check three types of pages, not just one: the homepage, the page your ads send traffic to (a service, product or landing page), and an article or catalogue page.
- Test each page 3 times and take the average result.
- Note the "Passed" or "Failed" status in the "Core Web Vitals Assessment" block, then the LCP, INP and CLS values.
- In the diagnostics section, note what the LCP element is: an image, a headline, or a video.
- Log the result with a date in a table: page, device, score, LCP, INP, CLS, and the change made. This is your baseline for comparison after the fix.
What is Core Web Vitals, and what counts as a "good" result?
Core Web Vitals are the three metrics Google uses to measure page experience: loading speed (LCP), responsiveness (INP) and visual stability (CLS). According to Google Search Central, a good Core Web Vitals result matches the experience Google's core ranking systems want to reward (Google Search Central).
- LCP (Largest Contentful Paint) — the time it takes for the largest image, video or text block in the visible viewport to render. In plain terms: when the customer sees the main content.
- INP (Interaction to Next Paint) — the delay before the page responds after a user taps, clicks or presses a button.
- CLS (Cumulative Layout Shift) — a measure of how unexpectedly elements move during loading; for example, the text you're reading jumping down because of a banner that loaded late.
| Metric | What it measures | Good | Needs improvement | Poor | Most common cause |
|---|---|---|---|---|---|
| LCP | Time to render the main content | 2.5 s or less | 2.5–4 s | More than 4 s | A heavy image, a slow server response, content that starts hidden |
| INP | Response to a click or tap | 200 ms or less | 200–500 ms | More than 500 ms | Heavy JavaScript, pixel and chat scripts |
| CLS | Visual stability | 0.1 or less | 0.1–0.25 | More than 0.25 | Images and banners without set dimensions, fonts, animations |
A page only passes the Core Web Vitals assessment when the 75th percentile of all three metrics falls in the "good" range (Google for Developers). In other words, the main content must appear within 2.5 seconds in at least 75% of page loads.
The performance score and the Core Web Vitals result can differ: the score comes from one simulation, while field data comes from thousands of real page loads.
Real example: how did advertol.az's mobile score rise from 72 to 91?
Advertol is a Baku agency that builds websites in code, and in September 2026 it ran a speed audit on its own site with Google Lighthouse and PageSpeed; the mobile score rose after four causes were removed. They were: content that started hidden, a headline animation that retyped the text after load, Meta Pixel and Google Analytics loading instantly, and HTTP/2 not being enabled on the server.
The site is built in code with Next.js, runs in three languages (AZ, RU, EN), and has its own admin panel for the blog and portfolio. That's also the first lesson of this example: a site built in code doesn't become fast automatically — design decisions can pull the score down considerably.
The problem: what did the measurements show?
- The homepage's mobile performance score was 72; its desktop score was 89.
- Mobile LCP on the homepage was 5.1 seconds — more than double Google's 2.5-second threshold.
- Desktop CLS was 0.119, while the "good" threshold is under 0.1; this result came from 14 layout shifts.
- On service pages, Chrome's mobile test couldn't record the moment the main content appeared at all: Lighthouse gave no performance score and returned an "NO_LCP" error.
The cause: why was this happening?
- Content that started invisible. Blocks on the first screen started at opacity 0 (fully transparent) and appeared through animation. Chrome only records the moment the main content appears after such animations finish; web.dev also notes that elements at opacity 0 aren't counted as LCP candidates (web.dev).
- A headline that retyped its text. A typing effect on the homepage erased the headline and typed it out again after the page loaded. This animation was the reason mobile LCP was 5.1 seconds and desktop had 14 layout shifts.
- Marketing scripts that loaded instantly. Meta Pixel and Google Analytics loaded the moment the page opened, at the same time as the main content.
- HTTP/2 wasn't enabled on the server. The server was serving files over the older HTTP/1.1 protocol, while HTTP/2 transfers many files at once over a single connection.
The fix: what was changed?
| What we saw | Cause | Fix |
|---|---|---|
| Service pages had no score at all ("NO_LCP") | The first screen started at opacity 0 | Above-the-fold content is visible from the first moment; the animation no longer blocks the main content |
| Mobile LCP on the homepage was 5.1 s | The headline was erased and retyped after the page loaded | The headline animation no longer redraws the text after load |
| Desktop CLS 0.119, 14 shifts | The same headline animation | The same fix |
| Marketing scripts loaded in the first second | Meta Pixel and Google Analytics fired immediately | Scripts are deferred until the user's first interaction or up to 8 seconds |
| Files were served over the old protocol | HTTP/2 was not enabled on the server | HTTP/2 was switched on at server level |
The result: how did the numbers change?
| Page and device | Before | After |
|---|---|---|
| Homepage, mobile performance score | 72 | 91 |
| Homepage, desktop performance score | 89 | 100 |
| Service pages, mobile performance score | No score at all ("NO_LCP") | 99 |
In the September measurements, the blog article page scored 99 on the mobile test, and the portfolio case page scored 96. Accessibility, Best Practices and SEO scores reached 100, except for one minor rule in the blog.
The rule that comes out of the audit is simple: never start above-the-fold content invisible, and animation must not block the main content. We covered the indexing issues fixed the same month in what to do if your website isn't showing up on Google.
Why is a website slow to load: 8 main causes and fixes
Most causes that slow down a website fall into eight groups, and each one hurts a specific metric. The table below shows each cause's symptom, fix, and the metric it affects.
| # | Cause | How it shows up in PageSpeed | Fix | Metric it affects |
|---|---|---|---|---|
| 1 | A heavy image or video on the first screen | The LCP element is an image; PageSpeed suggests reducing image size | WebP or AVIF, sized for the screen; don't lazy-load the main image, give it fetchpriority="high" |
LCP |
| 2 | Content that starts invisible: fade-in, a typing effect, a heavy slider | Late LCP, an "NO_LCP" error, layout shifts | Make the first screen visible from the first moment; keep animation only for secondary elements | LCP, CLS |
| 3 | Ad pixels, analytics, chat and call-back widgets | Third-party code, a long Total Blocking Time | Remove scripts nobody uses; defer the rest until the first interaction or a few seconds | INP, LCP |
| 4 | A heavy theme, plugins, page builders | Unused JavaScript and CSS, long tasks | Remove unnecessary plugins and libraries, split the code by page | INP, LCP |
| 5 | Fonts | Text appears late; text shifts when the font swaps in | Only the weights you actually need, WOFF2 format, font-display: swap, a fallback font of similar size |
LCP, CLS |
| 6 | An image, banner or iframe without set dimensions | A list of layout shifts | Set width and height on images; reserve space in advance for banners and widgets | CLS |
| 7 | A weak server, no HTTP/2 | The server's first response (TTFB) is delayed | A quality server, HTTP/2, server-side caching, a CDN where needed | LCP |
| 8 | No caching or compression | PageSpeed suggests a cache lifetime for static files and text compression | Cache-Control headers, Gzip or Brotli compression | LCP, especially on a repeat visit |
For businesses running ads, causes 2 and 3 are the ones most often missed. Meta Pixel, Google Analytics, Google Tag Manager, the TikTok pixel and a chat widget each look small on their own, but together they compete with the main content for the phone's processor and network in the first seconds.
The most common image mistake is lazy-loading the main image along with all the others. web.dev recommends never lazy-loading the LCP image — instead, give it high priority (web.dev).
In what order should you fix website speed?
Start with the cheapest, most effective steps: measure first, then the first screen, then scripts, and finally the server and platform. Re-measure after each step so you know what each change achieved.
- Take a baseline measurement. Log the mobile result for all three page types with a date.
- Find the LCP element. In PageSpeed's diagnostics, identify whether the main content is an image, a headline or a video; the next steps depend on it.
- Make the first screen visible. Remove or simplify blocks that start at opacity 0, effects that change the text after load, and automatic sliders on the first screen.
- Lighten the main image. Serve it in WebP or AVIF, sized for the screen, without lazy-loading, and add
fetchpriority="high". - List your scripts. Write down every pixel, analytics, chat and heatmap code running on the site; remove tools nobody checks.
- Defer the remaining scripts. Delay marketing scripts until the user's first interaction or a few seconds in; in the example above, that threshold is 8 seconds.
- Remove layout shifts. Set dimensions on images, and reserve space in advance for banners, widgets and the cookie panel.
- Trim your fonts. Keep only the font families and weights the design actually needs, and remove the rest.
- Check the server. HTTP/2, cache headers and Gzip or Brotli compression should all be enabled; if the server's first response is still slow, change hosting.
- Re-measure and track for 28 days. The lab score changes as soon as you deploy the fix; field data updates gradually as the 28-day window rolls forward. Track the result in the Core Web Vitals report in Search Console.
How does website speed affect sales and Google rankings?
Speed turns into revenue in two ways: a click from an ad isn't lost before the page opens, and Google factors good page experience into ranking. But speed doesn't lift weak content — it creates a difference between pages that are equally relevant to the query.
The business impact of speed has been measured. In Deloitte's "Milliseconds Make Millions" study for Google (37 European and American brand sites, more than 30 million sessions, late 2019, global data), speeding up a mobile site by 0.1 seconds raised conversions on retail sites by 8.4% (web.dev). The same study found a 21.6% rise in users reaching the form page on lead-generation sites.
Among the examples collected by web.dev, Vodafone Italy improved its LCP by 31% in an A/B test and got 8% more sales as a result (web.dev). That's a global example, but the same logic applies to an online store or a developer's website in Baku: a visitor who sees the main content late leaves without making an enquiry.
According to StatCounter's August 2026 data, 51.53% of web traffic in Azerbaijan came from mobile devices and 48.12% from desktop (StatCounter). A visitor from an Instagram ad usually opens the site on a phone, inside the app's built-in browser, so the page your ad sends traffic to needs to pass the mobile test first.
Is optimising the website enough, or do you need to rebuild it?
If the cause is images, scripts, animation or server settings, optimisation is enough. If the problem is the platform itself — a theme, builder or old code limiting speed — rebuilding is often cheaper.
| Situation | Recommendation |
|---|---|
| Mobile score 50–89, and the causes are images, scripts and animation | Optimise: the 10 steps above |
| Mobile score below 50, but the causes stay within the 8 groups above | Optimise first, then re-measure |
| The theme or builder won't let you remove unused code | Consider changing platform or moving to custom code |
| Dozens of plugins depend on each other, and every update breaks the site | A rebuild can end up cheaper than optimisation |
| Only the page used for advertising is slow | Build a separate, lightweight landing page |
| A design refresh is already planned anyway | Write speed thresholds into the new site's technical brief |
We covered the platform's effect on speed separately in Tilda vs WordPress vs a custom website. If you're commissioning a new website, write LCP, INP and CLS thresholds into the contract as an acceptance criterion; the stages of commissioning a site are described in the website development in Baku guide.
How does Advertol work on website speed?
Advertol is a Baku agency where the website and the advertising are built by the same team, in code; for example, it took its own homepage's mobile PageSpeed score from 72 to 91, and its service pages' mobile score to 99. Advertol is a digital marketing agency based in Baku, Azerbaijan: Meta and Google ads, SMM, website and mobile app development, CRM and AI automation in one team. Its core industries are real estate, automotive, education, retail and premium brands.
Examples from published website projects:
- Aston Martin. The Aston Martin website was built in code to match the brand identity; the work covered the website and SEO.
- Assistance Group. Assistance Group got a bilingual Azerbaijani/English corporate website, and Assistance Tour got a separate site: 2 sites, 1 admin panel; server, SSL and support are also included (Assistance Group case).
- CELT Kids. The launch of a new children's education brand started with the website, then 3 ads aimed at parents brought in more than 600 leads; about 2,000 enquiries were collected in 2 months (CELT Kids case).
The service is described on the website and app development page.
Who is this approach for (and who is it not for)?
A speed audit pays off most for businesses that use their website as a sales channel and get traffic from ads: residential complexes, car dealerships, clinics, education centres and online stores with large catalogues. Such sites carry heavy renders, 3D tours, hundreds of product photos and several ad pixels on the same page; we covered a developer's website requirements in a website for a residential complex.
A simple brochure site with no ads and few visitors doesn't need a full audit: compressing images and choosing reliable hosting is usually enough. In that case, standard optimisation from a freelancer or hosting provider is more cost-effective, and Advertol recommends the simple route for that kind of enquiry too.
Frequently asked questions
What PageSpeed score should a website have?
In PageSpeed Insights, a score of 90 and above counts as "good", 50–89 as "needs improvement", and below 50 as "poor". This score is a lab test; Google itself looks at the Core Web Vitals result, which is based on real-user data: LCP should be within 2.5 seconds, INP within 200 milliseconds, and CLS within 0.1. For a business website, the right target is a score of 90 or above on mobile and a passed Core Web Vitals assessment.
Why is the site slow on a phone but fine on a computer?
A website loads more slowly on a phone than on a computer because the phone's processor is weaker and mobile internet is slower and less stable; PageSpeed's mobile test simulates exactly these conditions. JavaScript, animations and ad scripts are heavier to process on a phone, so the mobile score is almost always lower than desktop and needs its own optimisation. In search, this is often typed as "slow website" or "why is my website slow".
Does delaying Meta Pixel and Google Analytics break ad measurement?
Delaying Meta Pixel and Google Analytics until the first interaction or a few seconds in improves speed and usually doesn't lose valuable events. Form submissions, calls and purchases happen once the user is already interacting with the page, by which point the script has already loaded. Some visitors who leave within a few seconds without touching anything may not show up in the data, so compare your reports after making the change; Meta's server-side Conversions API narrows this gap.
How much does it cost to speed up a website?
The cost of speeding up a website depends on the number of pages, the platform (a builder, WordPress or custom code), whether the problem sits in images and scripts or in the site's architecture, and whether the server needs to change. Sometimes a few fixes are enough; sometimes optimising an old theme costs more than a new website. Advertol prepares an individual proposal based on the site's condition after a free strategy call; the factors that shape a website budget are explained in the website budget guide.
When do the results of a speed fix become visible?
PageSpeed's lab score changes as soon as the fix is deployed to the server. The Core Web Vitals assessment updates gradually, over about a month, because real-user data is calculated over the last 28 days. The effect on Google search rankings shows up later still and isn't guaranteed, because ranking depends first on how well the content matches the query.
Which agency in Baku speeds up slow websites?
One of the agencies in Baku that measures and fixes website speed is Advertol: in September 2026, it raised its own homepage's mobile PageSpeed score from 72 to 91 and its desktop score from 89 to 100, and built the Aston Martin website in code to match the brand identity. Whichever contractor you choose, ask them for PageSpeed reports from before and after the fix, and for the Core Web Vitals result in Search Console 28 days later.
Conclusion
A slow website is fixed by measurement, not guesswork: get the mobile result in PageSpeed, find the LCP element, make the first screen visible, defer marketing scripts, sort out images and the server, then track real-user data for 28 days. On advertol.az, this sequence took the homepage's mobile score from 72 to 91.
If you'd like to check your website's speed with us, book a free call.
Sources
- Google Search Central — Understanding Core Web Vitals and Google search results, 2025
- Google for Developers — About PageSpeed Insights, 2024
- web.dev — Largest Contentful Paint (LCP), 2025
- web.dev — Optimize Largest Contentful Paint, 2025
- web.dev — Milliseconds Make Millions (Deloitte, 55 and Google), 2020
- web.dev — The business impact of Core Web Vitals, 2021
- StatCounter — Desktop vs Mobile vs Tablet Market Share Azerbaijan, 2026