Introduction
Think about the last time a website took too long to load on your phone. You probably waited a few seconds, then pressed the back button and tried another result. Your customers do the same. Research by Google found that as a mobile page’s load time grows from one second to three seconds, the probability that the visitor leaves rises by 32%. Every extra second costs attention, enquiries and sales.
Speed also matters to search engines. Google wants to send people to pages that give a good experience, and it measures real-world loading speed, responsiveness and visual stability through a set of measurements called Core Web Vitals. Speed alone will not put a weak page at the top of the results, but when pages are similarly relevant, a faster, smoother page has an advantage.
Many factors affect website speed: images, code, plugins, design choices and the visitor’s own connection. One factor sits under all of them: the hosting. This article explains why website speed matters, what Core Web Vitals measure, how hosting affects speed, and a practical plan for making your website faster.
Why speed matters for business
Visitors leave slow websites
Mobile visitors are often on the move, using mobile data with variable signal. They have little patience for slow pages. If the first screen takes too long to appear, many leave before seeing your products or services.
Speed affects conversions
Speed affects more than the first page. Slow product pages, filters, carts and forms frustrate customers at the moment they are trying to buy or enquire. A fast, responsive checkout feels trustworthy; a slow one makes people hesitate.
Speed affects advertising costs
If you run Google Ads, the landing page experience is part of how Google judges your ads. A slow landing page can mean lower ad quality, higher costs and fewer conversions from the same budget.
Speed affects search visibility
Google uses page experience signals, including Core Web Vitals, as part of its ranking systems. Relevance and content quality matter most, but when several pages answer a search well, the experience they offer helps decide the order.
What Core Web Vitals measure
Core Web Vitals are three measurements of real user experience. Google collects them from Chrome users who have agreed to share usage statistics, and judges each page by the experience of the 75th percentile of visits, on mobile and desktop separately.
| Measurement | What it means | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | How quickly the main content, such as a hero image or heading, appears | 2.5 seconds or less | 2.5 to 4 seconds | Over 4 seconds |
| Interaction to Next Paint (INP) | How quickly the page responds when someone taps, clicks or types | 200 milliseconds or less | 200 to 500 milliseconds | Over 500 milliseconds |
| Cumulative Layout Shift (CLS) | How much the page jumps around while loading | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
INP replaced an older measurement, First Input Delay, as a Core Web Vital in March 2024. INP is stricter, because it looks at responsiveness throughout the visit, not just the first interaction.
Time to First Byte: the measurement hosting controls most
Behind these three measurements sits another one: Time to First Byte (TTFB), the time between the browser asking for a page and receiving the first byte of the response. Google’s web.dev guidance suggests aiming for a TTFB of 0.8 seconds or less. TTFB includes the connection to the server and the time the server takes to build the page. A slow TTFB delays everything else, including LCP, because the browser cannot start showing the page until it starts receiving it.
TTFB is where hosting has the greatest direct effect.
How hosting affects website speed
Server processing
For dynamic websites such as WordPress, the server runs code and queries a database to build each page. The speed of the CPU, the amount of memory, the speed of the storage and the efficiency of the server software all affect how long this takes. An overloaded shared server, or one with old software, adds delay to every uncached page.
Caching
Server-level page caching serves a ready-built copy of the page instead of building it again for each visitor. This can reduce server processing time from hundreds of milliseconds to a few. Object caching speeds up pages that cannot be fully cached, such as carts and account pages. OPcache keeps PHP code compiled in memory. Our WordPress and WooCommerce hosting guide explains these layers for WordPress.
Distance and the network
Data travels very fast, but not instantly, and every connection involves several round trips between the browser and the server. A server close to most of your visitors reduces these delays. For visitors in several countries, a content delivery network (CDN) stores copies of images, style sheets and scripts on servers around the world, and some CDNs can cache whole pages.
Modern protocols
Current web servers support HTTP/2 and HTTP/3, which load many files over one connection more efficiently than the older HTTP/1.1. Modern TLS versions make secure HTTPS connections faster to set up. Compression such as Brotli or Gzip makes text files smaller. These are hosting-level features that a website owner usually cannot add alone.
Resources under load
A server that is fast with one visitor can slow down with fifty. Limits on CPU, memory and simultaneous processes decide how the site performs during busy periods, such as a sale or a campaign. This is why the same website can score well in a quiet test and badly for real visitors at peak times.
Software versions
Newer versions of PHP and databases are generally faster than older ones. Hosting that keeps software current, and helps you upgrade, gives you these improvements without changing the website.
What hosting cannot fix
Good hosting removes the server as a bottleneck, but it cannot fix problems in the website itself. Common causes of slow pages that need website changes include:
- Oversized images, such as a 4 MB photo used as a hero image.
- Too many plugins or heavy page builders loading code on every page.
- Large JavaScript files, especially from sliders, animations, chat widgets and tracking tools.
- Web fonts loaded in many weights and styles.
- Embedded videos and maps loading before they are needed.
- Missing image dimensions, which cause layout shifts.
- Third-party scripts for advertising, analytics and social media.
The fastest results come from improving both the hosting and the website together.
How to measure your website’s speed
Use several tools, because each shows a different part of the picture:
- Google PageSpeed Insights shows field data from real Chrome users (when enough data exists) and a lab test with specific recommendations.
- Google Search Console includes a Core Web Vitals report that groups your pages into good, needs improvement and poor, based on real visits.
- Browser developer tools show exactly which files load, in what order and how long each takes.
- Uptime and performance monitoring tracks server response time over days and weeks, so you can spot slowdowns at particular times.
Test on mobile as well as desktop, and test important pages such as product pages, category pages and the checkout, not just the home page.
A practical plan to speed up your website
Step 1: Measure
Record your current Core Web Vitals, TTFB and page weight for your most important pages. This gives a baseline for comparing improvements.
Step 2: Fix the server
If TTFB is consistently above 0.8 seconds, start with the hosting. Turn on server-level caching, update PHP, check resource limits and, if necessary, move to a better plan or a server closer to your visitors.
Step 3: Optimise images
Resize images to the size they are displayed, compress them and use modern formats such as WebP or AVIF. Load images below the first screen lazily, but not the main hero image, which should load as early as possible.
Step 4: Reduce code
Remove unused plugins, scripts and styles. Delay non-essential scripts such as chat widgets until after the page has loaded. Limit fonts to the weights you actually use.
Step 5: Prevent layout shifts
Set width and height for images and videos, reserve space for banners and embedded content, and avoid inserting content above what the visitor is reading.
Step 6: Improve responsiveness
Break up long JavaScript tasks, reduce heavy page builder effects and test how quickly menus, filters and buttons respond on a mid-range phone.
Step 7: Use a CDN where it helps
If your visitors are spread across countries, a CDN can reduce load times for images and static files.
Step 8: Monitor and repeat
Real-user data in Search Console updates over about four weeks, so improvements take time to show. Keep monitoring, and check speed after every major change to the website.
Mobile first
Google indexes and ranks websites mainly based on their mobile version. In Sri Lanka, as in most markets, a large share of visitors browse on phones, often on mobile data. Design and test for a mid-range Android phone on a mobile connection, not for a fast office computer. A website that is fast on mobile will usually be fast everywhere.
Speed and online stores
Online stores have particular speed challenges. Category pages with many products, filters, search and product variations put heavy demands on the server and database. Carts and checkouts cannot be fully cached. During sales, many customers act at once. For stores, it is especially important to:
- Use object caching and enough PHP processes for busy checkout periods.
- Keep the database clean and well indexed.
- Optimise product images in bulk.
- Test the checkout’s speed, not just the home page.
- Check server capacity before major campaigns.
Common speed myths
“A perfect PageSpeed score is the goal”
The lab score in PageSpeed Insights is a useful guide, but Google’s rankings use field data from real visitors. A page with a lab score of 85 and good Core Web Vitals for real users is in a better position than a page chasing 100 in the lab while real visitors on mobile still wait. Focus on the real-user measurements and on the pages that matter for your business.
“Unlimited hosting is fast hosting”
“Unlimited” refers to storage or bandwidth, not to speed. What decides speed is server processing power, memory, storage performance, caching and how many websites share the server. A plan with clear, generous CPU and memory limits is often faster than an “unlimited” plan on a crowded server.
“A caching plugin is enough”
Caching plugins help, but server-level caching is usually faster, because it serves pages before WordPress even starts. Caching also cannot help pages that must be built for each visitor, such as carts, checkouts and account pages. Those depend on the server’s raw performance and on object caching.
“Speed only matters for the home page”
Visitors often arrive on a product page, a blog article or a landing page from an advertisement, not the home page. Google assesses pages individually and in groups. Test the pages that bring visitors and the pages where they convert.
“Once it is fast, it stays fast”
Websites slow down over time as plugins, images, tracking scripts and content are added and databases grow. Speed needs regular checks, especially after redesigns, new plugins and new marketing tools.
A quick speed checklist for business owners
- Is server-level caching turned on?
- Is the website running a current PHP version?
- Are images resized and compressed before upload?
- Have unused plugins and themes been removed?
- Do chat, tracking and social media scripts load only where needed?
- Is the Core Web Vitals report in Search Console mostly “good”?
- Is someone checking speed after each major change?
Illustrative example
The following example is illustrative and does not describe a real client.
A furniture retailer’s website looked attractive, but PageSpeed Insights showed a mobile LCP of over six seconds and a TTFB of nearly two seconds. The Search Console Core Web Vitals report marked most product pages as poor.
The work started with hosting. The site moved to WordPress hosting with server-level page caching, object caching and a current PHP version, bringing TTFB well under the 0.8-second target for cached pages. Next came the website itself. Hero images of several megabytes were replaced with properly sized WebP versions, a slider plugin that loaded on every page was removed, the number of font weights was reduced and image dimensions were added to stop layout shifts. A chat widget was set to load after the page.
Over the following weeks, the Core Web Vitals report showed product pages moving from poor to good. More importantly, the owner saw more product enquiries from mobile visitors.
How Dsigngo Group can help
Our hosting is set up for speed, with server-level caching, current software versions, modern protocols and sensible resource limits. Because Dsigngo Group also designs and builds websites and runs digital marketing and SEO, we can improve the website and the server together, and connect the results to your search and advertising performance.
Our speed service includes:
- A speed audit with Core Web Vitals, TTFB and page weight for your key pages.
- Hosting improvements: caching, PHP upgrades and, where needed, a better plan or server.
- Website improvements: images, plugins, scripts, fonts and layout stability.
- Monitoring and a follow-up report.
The speed audit is free for our hosting clients and for businesses thinking of moving their website to us.
Frequently asked questions
Will faster hosting improve my Google ranking?
Faster hosting improves server response time, which helps loading speed and Core Web Vitals. Page experience is one of many signals, so content and relevance still matter most, but speed helps both rankings and conversions.
What is a good page load time?
Aim for an LCP of 2.5 seconds or less and a TTFB of 0.8 seconds or less for most visits, measured on mobile. Faster is better, especially for online stores.
Why is my site fast on my computer but slow for customers?
Your computer may have the site cached, a fast connection and a powerful processor. Customers on mid-range phones and mobile data have a different experience. Use field data from Search Console and PageSpeed Insights to see what real visitors experience.
Do I need a CDN?
A CDN helps most when visitors are spread across countries or when a site serves many large images and files. For a website whose visitors are mainly in Sri Lanka and whose server is nearby, good caching may matter more. We advise based on your traffic.
How long does it take to see results?
Lab tests show improvements immediately. Google’s real-user data in Search Console is based on the previous 28 days of visits, so it takes about four weeks for the full effect of a change to appear in the Core Web Vitals report.
Conclusion
Website speed affects whether visitors stay, whether they buy or enquire, how much your advertising costs and how well your pages perform in search. Core Web Vitals give clear targets: LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less. Hosting controls the foundation, especially server response time, through processing power, caching, location, protocols and resources. The best results come from fast hosting and a well-optimised website working together.
Is your website slow? Ask us for a speed audit and a clear plan to fix it.
Sources
- Google, Think with Google, page load time and bounce probability (Google/SOASTA research, 2017): https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/page-load-time-statistics/
- web.dev, Web Vitals (LCP, INP and CLS thresholds): https://web.dev/articles/vitals
- web.dev, Interaction to Next Paint becomes a Core Web Vital (March 2024): https://web.dev/blog/inp-cwv-march-12
- web.dev, Optimize Time to First Byte: https://web.dev/articles/optimize-ttfb
- Google Search Central, Understanding Core Web Vitals and Google search results: https://developers.google.com/search/docs/appearance/core-web-vitals
- Google Search Central, Mobile-first indexing: https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing











