Why is my website slow to load?
A website is slow to load when something on the page, or the server behind it, makes the browser wait before it can show the main content. The cause is usually one or more of four things: heavy images, a slow server, scripts and plugins that add extra code, and fonts. A speed report names the cause, and the fixes below go in order of likely effect.
How do you check how fast your website loads?
Check how fast your website loads by running the page through PageSpeed Insights, Google's report on page speed. It reports on the user experience of a page on both mobile and desktop and suggests how to improve it. Test the pages that matter most, such as the homepage and the page people land on from a search or an ad, not just one.
Read the results in three parts:
- **Real-user data first.** If the page has enough visits, the report shows how real visitors experienced it over the previous 28 days.
- **Lab data second.** This is a test run in a controlled setting, useful for finding the cause.
- **The opportunities list.** It names the images, scripts and fonts that cost the most.
What is the difference between lab data and field data?
Lab data comes from loading a page in a controlled environment with fixed network and device conditions. Field data comes from real visitors, so it reflects their actual devices, networks and locations. The two can disagree, even for the same page, and neither is wrong. Lab data helps you debug. Field data tells you what visitors actually got.
Which numbers should you look at?
Look at the three Core Web Vitals and, for the server, time to first byte. Google's thresholds for a good result are these:
- **Largest Contentful Paint (LCP):** 2.5 seconds or less. It is when the largest image, text block or video in view finishes drawing.
- **Interaction to Next Paint (INP):** 200 milliseconds or less. It measures how quickly the page responds when someone taps or types.
- **Cumulative Layout Shift (CLS):** 0.1 or less. It measures how much the page jumps around as it loads.
- **Time to first byte (TTFB):** 0.8 seconds or less, as a rough guide.
A page passes Core Web Vitals when it meets the targets at the 75th percentile for all three.
How do you check speed on a phone?
Check speed on a phone by reading the mobile results in PageSpeed Insights, then loading the page on a real phone over mobile data. Lighthouse, the tool behind the lab data, simulates a mid-tier phone on a mobile network. A simulation still differs from your visitors' phones, which is why the field data matters.
Are images the reason your website is slow?
Images are the first place to look. LCP scores when the largest image, text block or video in view finishes drawing, so a heavy hero photo counts directly against it. Three checks cover images: the size, the format and when each image loads.
Are your images bigger than they need to be?
Often they are. Lighthouse compares the size of each image with the size it is displayed at, and Google's guidance is that a page should never serve images larger than the version rendered on the visitor's screen. Anything larger wastes bytes and slows the load. The fix is to resize each image to the size it is shown at and, where the platform allows it, serve smaller versions to smaller screens.
Is the image format right?
The format matters because the newer formats compress better. WebP and AVIF generally give better compression than JPEG and PNG, and a JPEG or PNG can sit behind them as a fallback for browsers that need one. Photos suit JPEG, lossy WebP or AVIF. Images that must keep fine detail suit PNG or lossless WebP.
Do images below the fold load only when needed?
They should. Adding `loading="lazy"` to an image tells the browser to wait until it is near the visible area before fetching it. That saves bandwidth for the images people may never scroll to. One rule matters: do not lazy load images likely to be in view when the page opens, especially the largest one. Lazy loading that image delays the very number the report scores.
Is slow hosting the problem?
Slow hosting is the problem when the server takes too long to start sending the page. Time to first byte measures the wait between asking for a page and the first byte of the answer arriving, and it comes before every other loading measure. Google's rough guide is 0.8 seconds or less, and anything over 1.8 seconds is poor.
Compare the number across several pages. A high figure on every page points at the server, the hosting plan or the way pages are generated, and no amount of image work reaches that. A high figure on one page points at that page. Either way, the report tells you where to send the question: to the host, or to whoever built the site.
Do scripts and plugins slow a website down?
Scripts and plugins can slow a website down. Each script adds code the browser must download and run, and a plugin from a site builder or content management system often brings its own scripts with it. Third-party scripts, such as analytics, advertising tags, chat widgets and social buttons, can significantly affect load performance, according to Google's Lighthouse documentation. Lighthouse flags a page when third-party code blocks the main thread for 250 milliseconds or longer.
What should you do about a slow script?
Google gives two options. Remove the script if it does not add clear value. If it stays, change how it loads. A script in the head of the page without an `async` or `defer` attribute is render-blocking, meaning the browser stops drawing the page until it has handled the script. Adding `async` or `defer` to a script lets the browser keep building the page while the script loads in the background.
List every script and plugin on the site and ask what each is for. The ones nobody can name are the first to go.
Can fonts slow a website down?
Fonts can, because they are often large files that load slowly. Some browsers hide the text until the font arrives, which Google calls a flash of invisible text.
The `font-display` setting controls this. The values `swap`, `optional` and `fallback` tell the browser to show a system font until the custom one is ready. Fewer font files and fewer weights also mean less to download. A text block set in a web font is not counted as drawn during the period when the browser hides it, so a slow font can hold back the LCP number too.
Why fix a slow website in this order?
Fix a slow website in order of effect, meaning the change that saves the most time goes first. Images lead because the report shows their saving in plain figures and a hero image can be the LCP element. Hosting comes next because the first byte arrives before anything else, and a slow server is not fixed in the page. Scripts and plugins follow, then fonts.
Treat that as a starting order, not a rule. The opportunities list in the report shows the saving for each item. If one third-party script costs more than every image combined, it moves to the top.
What should you recheck after each change?
Recheck the same page, in the same mode, after each change. Make one change at a time, so a gain or a loss has one explanation. Run PageSpeed Insights again and compare the lab figures straight away. The real-user figures lag, because that data covers the previous 28 days, so give it time before judging a result. Then check the page by eye on a phone for anything that broke, such as a missing image or a layout that jumps.
What can no one promise about page speed?
No one can promise a score, a number of seconds or a position in search. Lab and field data differ, and visitors' devices and networks vary. Speed is also one part of how a site performs, alongside whether its content answers what people are looking for. What can be promised is the work: the measurements taken, the causes found, the fixes made in order and the numbers shown again afterwards.
How do you get a speed check and a fix plan?
Start with the report. Run your main pages through PageSpeed Insights, keep the mobile results, and write down which images, scripts and fonts it names. That list is most of a fix plan.
Before a Devodin site launches, its pages are tested on phones and run through Lighthouse and the Core Web Vitals. Devodin is remote first and serves the US, the UK and Europe. If you want help to get a speed check and fix plan, send the details and you will get a reply within one business day. No result is promised in advance, and the scope is agreed in writing before any work begins.
