Your website is slow. Statistically, it almost certainly is. The median page load time for websites in 2026 is still hovering around 4 seconds on mobile. Google considers anything above 2.5 seconds to be a poor experience. And 53% of mobile users abandon a site that takes more than 3 seconds to load. Those are not abstract numbers. They are customers walking away from your business before they even see what you offer.

But "make it faster" is not actionable advice. To actually fix a slow website, you need to understand what makes websites slow in the first place. Let us break it down into the factors that matter, ranked by their actual impact on load times.

Page Weight: The Single Biggest Factor

Page weight is the total size of everything the browser needs to download to display your page. That includes your HTML, CSS, JavaScript, images, fonts, and any other assets. The average web page in 2026 is over 2.5MB. A well-built page should be under 500KB. The difference is massive, and it directly determines how fast your site loads, especially on mobile connections.

Where the Weight Comes From

For most websites, the breakdown looks roughly like this:

  • Images: 50-70% of total page weight. This is almost always the biggest offender. Unoptimised images uploaded directly from a camera or phone can be 3-8MB each. A single hero image that should be 80KB is often served at 4MB.
  • JavaScript: 15-30% of total page weight. This includes frameworks, analytics, chat widgets, social media embeds, animation libraries, and the dozens of scripts that WordPress plugins add.
  • CSS: 5-10% of total page weight. Frameworks like Bootstrap add 150KB+ of CSS, most of which goes unused on any given page.
  • Fonts: 5-10% of total page weight. Custom fonts are typically 50-200KB per weight and style combination.
  • HTML: 1-3% of total page weight. HTML itself is almost never the problem.

Images: The Low-Hanging Fruit

If you do nothing else to speed up your website, optimise your images. This single change can reduce page weight by 60-80% on most sites.

Modern Image Formats

The JPEG and PNG formats that most websites still use were designed decades ago. Modern formats deliver dramatically better compression:

  • WebP reduces file size by 25-35% compared to JPEG at equivalent quality. Supported by all modern browsers.
  • AVIF reduces file size by 50%+ compared to JPEG. Supported by Chrome, Firefox, and Safari.

A hero image that weighs 400KB as a JPEG can be 180KB as WebP and 100KB as AVIF, with no visible quality difference. Multiply that across every image on your site and the savings are enormous.

Responsive Images

Your hero image does not need to be 1920px wide when it is being viewed on a 375px wide phone screen. Using the srcset attribute in HTML, you can serve different image sizes to different devices. This alone can cut image weight by 70% on mobile.

Lazy Loading

Images below the fold, the ones you cannot see without scrolling, should not load until the user scrolls to them. Native lazy loading with loading="lazy" is now supported by all browsers and requires exactly one HTML attribute to implement. There is no reason not to use it.

Code Bloat: Death by a Thousand Scripts

Every JavaScript file and CSS stylesheet your page loads is a request the browser has to make, a file it has to download, and code it has to parse and execute. Each one adds latency. And the problem is cumulative.

The JavaScript Problem

JavaScript is particularly expensive because it does not just need to be downloaded, it needs to be parsed and executed. A 200KB JavaScript file takes significantly longer to process than a 200KB image because the browser's JavaScript engine has to interpret every line of code. On low-powered mobile devices, this parsing time can be several seconds.

Common sources of JavaScript bloat:

  • jQuery (87KB) loaded on sites that do not need it. Modern JavaScript does everything jQuery does.
  • Analytics scripts from Google Analytics, Facebook Pixel, Hotjar, and others. Each one adds 50-100KB and fires additional network requests.
  • Chat widgets from Intercom, Drift, or Tidio typically add 300-500KB of JavaScript.
  • Social media embeds from Instagram, Twitter, or Facebook can add 1MB+ each.
  • Animation libraries like GSAP or Framer Motion add 30-100KB even if you only use one animation.

Every third-party script you add to your website is someone else's code running on your customers' devices. You are trusting their code quality, their server uptime, and their performance priorities. Most of the time, that trust is misplaced.

Hosting: The Foundation Everything Sits On

You can have the leanest, most optimised website in the world, and it will still be slow if it is sitting on a $3/month shared hosting plan with a server in Virginia while your customers are in Gold Coast, Queensland.

Server Response Time

Time to First Byte (TTFB) measures how long it takes the server to start sending data after receiving a request. Google considers anything under 200ms to be good. Cheap shared hosting regularly delivers TTFB of 800ms to 2 seconds, meaning the page cannot even begin loading for almost two full seconds.

Server Location

Data travels at the speed of light, but even light takes time to cross oceans. If your server is in the United States and your customer is in Australia, every request has to travel approximately 15,000 kilometres each way. That adds 200-300ms of latency to every single request. For a page with 30 requests (CSS, JavaScript, images, fonts), that latency adds up fast.

For Australian businesses, your hosting should be in Australia. Sydney data centres are the standard. If you use a CDN (content delivery network), your assets should be cached at edge nodes in Sydney, Melbourne, and Brisbane at minimum.

What a CDN Actually Does

A CDN is a network of servers distributed around the world. When you put your website behind a CDN like Cloudflare, your files get cached on servers physically close to your visitors. An Australian customer gets served from a Sydney or Brisbane server. A British customer gets served from a London server. The result is dramatically lower latency for everyone.

For static websites (custom HTML/CSS sites without a database), CDNs are particularly effective because the entire site can be cached at the edge. There is no origin server processing to wait for. The CDN serves the files directly.

Core Web Vitals: What Google Actually Measures

Google uses three specific metrics to evaluate website performance, collectively called Core Web Vitals. These are not suggestions. They are ranking factors. Sites that score poorly on Core Web Vitals are actively penalised in search rankings.

Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest visible element (usually a hero image or heading) to finish loading. Google's threshold: under 2.5 seconds is good, over 4 seconds is poor. This metric is heavily influenced by image optimisation, server response time, and render-blocking resources.

Interaction to Next Paint (INP)

INP replaced First Input Delay in 2024. It measures the responsiveness of your page to user interactions throughout the entire visit, not just the first click. Google's threshold: under 200ms is good, over 500ms is poor. Heavy JavaScript is the primary cause of poor INP scores.

Cumulative Layout Shift (CLS)

CLS measures how much the page layout shifts unexpectedly while loading. You know that annoying experience where you are about to tap a button and suddenly the page jumps because an ad or image loaded above it? That is layout shift. Google's threshold: under 0.1 is good, over 0.25 is poor. Setting explicit width and height on images and reserving space for dynamic content prevents this.

How to Test Your Website Speed

You do not need to guess how fast your site is. These free tools will tell you exactly where the problems are:

  • Google PageSpeed Insights (pagespeed.web.dev) gives you Core Web Vitals scores and specific recommendations
  • GTmetrix (gtmetrix.com) provides detailed waterfall charts showing exactly what loads and when
  • WebPageTest (webpagetest.org) offers the most granular performance analysis available

Or you can skip the manual testing and let us do it for you. Our free website audit includes a full performance analysis with specific, actionable recommendations for your site.

The Speed Advantage of Custom-Built Sites

This is where custom HTML websites have an overwhelming advantage over CMS-based sites. A hand-coded site can realistically achieve a total page weight under 100KB, a TTFB under 50ms (when served from a CDN), and perfect 100/100 scores on PageSpeed Insights. That is not aspirational. That is what we deliver at Jarmos Digital as standard.

Speed is not just a technical metric. It is a competitive advantage. A faster site ranks higher, converts better, and delivers a better experience for every visitor. If your current site is not fast, let us talk about fixing that.