Why is my website slow?
Posted on Monday June 8, 2026
You open your browser and type your website domain into the navigation bar and then… wait. With websites and apps at our fingertips that have infinite scrolling and endless content, websites are expected to feel responsive and load fast.
Whether you have an e-commerce store or a landing page for a real-estate project, your website’s performance matters for the same reason: conversion rate. Industry research has long shown that for every second a website takes to load, conversions are reduced by roughly 7%. That could have been 7% more purchases or leads.
Is it actually slow?
How can you tell if your website’s performance is the issue or if it’s an external issue like spotty Wi-Fi? We’ve created a free tool to measure your website’s performance. Running your website through our website performance tool will display a score from 0-100 and a breakdown of what’s hurting it. Try our website performance tool.
The score is calculated using Google’s Core Web Vitals, the industry-standard set of metrics for measuring web performance. The three Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS), which measure loading performance, page responsiveness and visual stability. Google uses these as ranking signals, so a slow website doesn’t only hurt conversions, but it can hurt your search rankings as well.
If your score is below 90, or any Core Web Vitals are flagged for needing improvement, your site has issues that can negatively affect your users’ experience. Here are some of the most common issues we’ve found that lead to slow websites.
Common issues contributing to poor website performance
Shared hosting
Was that $10/month shared hosting offer too good to be true? Website hosts that sell shared hosting often oversell the capacity of a single server and this results in a slow Time to First Byte (TTFB). What this means is that when a user searches www.yourwebsite.com, the TTFB is how long it takes before the server responds with anything. This is what causes that loading spinner when you enter a domain into the address bar.
Google says a TTFB of 0.8 seconds or less is good. We’ve seen shared hosts with 4 seconds or more. If your website has a lot of dynamic content like an e-commerce store, the stretched-thin compute power can struggle to serve your store, and you can lose customers.
If your website is mostly static content, like a landing page or blog, you should be using a cache. Caching will help improve the TTFB by saving the website output to memory or disk and serving this file to the next visitor instead of re-rendering the page on the server.

Large file sizes
Visual content on a website is great, unless your landing page is loading 100 Megabytes (MB) of assets. According to the Canadian Telecommunications Association, the average mobile download speed in Canada is 117.0 Mbps. At this speed your 100MB webpage will take 6.8 seconds to load. Not only that, but most cellphone plans also have a monthly cap. If a website visitor has a 40GB data cap your website just took 0.25% of their total data. Oops!
You don’t need to serve 120-megapixel images or 4K videos on your website. Reducing the resolution of images and using newer image formats like WEBP and AVIF can dramatically reduce file sizes. The loading="lazy" attribute on images and videos tells browsers not to load content until it’s visible in the viewport, and who scrolls to the bottom of a page anyway? Srcset is an under-utilized HTML image attribute for responsive images. You can serve smaller images to a mobile browser, while keeping the higher quality image for a desktop browser. These techniques can reduce the overall file size of your website and make it load faster.
Render-blocking and external resources
Do you need to load 10 font files when you’re only using 1? What about your full 5MB Javascript bundle? The browser needs to wait before it displays the content on the screen or, depending on the loading order, the page may appear frozen. This is known as render-blocking. It usually occurs when a webpage requests stylesheets, fonts, or scripts and needs to wait for those resources to load. External resources add more of a performance hit because each connection to a third-party requires another TLS handshake.
The number of resources the browser requests is less of an issue now with HTTP/2. The browser will send all the requests at once, but your website’s loading speed is still at the mercy of the slowest resource. What if that JavaScript library from a third-party fails to load? Depending on the device and browser, it can take over a minute before the request will time out and your page will be responsive again.
So how do you fix these issues? You don’t need to bundle your CSS and JS into a single file anymore; it’s better to load the exact styles and scripts each page needs. Your website should minimize the number of external resources by serving them from your own server and resource-intensive scripts should use the defer attribute if they’re not critical to the functionality of the website. This way the browser doesn’t need to make extra DNS lookups and TLS handshakes, and the page doesn’t hang until the script is finished loading and executing.
What’s next?
We’ve outlined some of the most common issues we’ve seen that can contribute to slow website loading and poor Core Web Vitals scores. If your website doesn’t meet the minimum recommendations of an LCP of less than 2.5 seconds, an INP of less than 200 milliseconds, and a CLS of less than 0.1, then your website is most likely not performing at its best. Upgrade from shared hosting, shrink those file sizes, lazy-load your images, and defer your non-critical JavaScript files.
If you have a slow website and don’t know where to start, we can help. Madhouse has experience developing and hosting award-winning websites for clients that are fast, look good, and most importantly, convert. Contact us today.
ALL POSTS












