12 Ways to Make Your Website Load Faster (2026)

Image optimisation alone can cut your total page load time by 40-60%. It is the single highest-impact change you can make, and it is surprisingly easy to implement.

Most business websites we audit in Singapore are still serving images in PNG or JPEG format. These formats are decades old and significantly larger than modern alternatives. WebP delivers 25-35% smaller files than JPEG at the same visual quality, and AVIF pushes that even further with 50% smaller files. For a typical homepage with 8-10 images, that can mean reducing page weight from 3-4MB down to under 1MB.

Here is what we did for a recent client: their homepage featured a hero banner (2.1MB PNG), six service images (400-600KB each as JPEG), and a team photo (1.8MB PNG). Total image weight: 7.2MB. After converting everything to WebP with appropriate compression, total image weight dropped to 1.4MB. That is an 80% reduction without any visible loss in quality.

How to implement this:

• Use the HTML picture element to serve WebP with JPEG fallback for older browsers
• Resize images to their display dimensions. If an image displays at 600px wide, do not upload a 3000px original
• Set quality to 75-85% for WebP. Below 75% you start to see artefacts; above 85% the file size savings diminish
• Tools: Squoosh (free, browser-based), Sharp (Node.js library), or Cloudinary (automated CDN-based conversion)

If you only do one thing from this entire guide, do this. The payoff is immediate and dramatic. When budgeting for a new or redesigned website, image optimisation should be part of the plan from day one. Our guide to website costs in Singapore covers what to expect at different price points, including performance optimisation.

When a visitor loads your website for the first time, their browser downloads every file: HTML, CSS, JavaScript, images, fonts. Without caching, it downloads all of those files again on every subsequent page visit. That is wasteful and slow.

Browser caching tells the visitor's browser to store certain files locally for a specified period. On their second visit (or when navigating to another page on your site), the browser loads those files from its local cache instead of re-downloading them from your server. The result: repeat page loads can be 60-80% faster.

How to set it up depends on your hosting environment:

• Apache servers: add Cache-Control headers in your .htaccess file. Set images and fonts to cache for one year (max-age=31536000), CSS and JS for one month, and HTML for a shorter period or no-cache
• Nginx servers: configure the expires directive in your server block
• Vercel, Netlify, or Cloudflare Pages: these platforms handle caching automatically with sensible defaults. Static assets get long cache durations out of the box
• WordPress: plugins like WP Super Cache or W3 Total Cache add caching headers and generate static HTML versions of your pages

One important detail: when you update your CSS or JavaScript, cached visitors will still see the old version until the cache expires. The solution is cache-busting, which means appending a version hash to filenames (e.g., styles.a1b2c3.css). Most modern build tools handle this automatically.

Your source code is written for humans to read, with indentation, comments, and descriptive variable names. Browsers do not need any of that. Minification strips out whitespace, comments, and unnecessary characters, reducing file sizes by 10-30% without changing functionality.

Here is a practical example. A typical WordPress theme's CSS file might be 180KB unminified. After minification, it drops to around 130KB. That does not sound dramatic on its own, but when you combine CSS, JavaScript, and HTML minification across your entire site, the savings add up quickly. On a site with multiple JS libraries, we have seen combined savings of 200-400KB per page load.

Beyond basic minification, there are more aggressive optimisations worth considering:

• Tree shaking: removes unused JavaScript functions from your bundles. If you import a utility library but only use three of its 50 functions, tree shaking eliminates the other 47
• PurgeCSS or Tailwind's built-in purge: scans your HTML and removes any CSS classes that are not actually used. We have seen this reduce CSS file sizes by 90% or more
• Code splitting: instead of loading one massive JavaScript file, split it into smaller chunks that load only when needed. The contact page does not need to load the image gallery code

Modern frameworks like Astro handle minification automatically during the build process. For WordPress sites, plugins like Autoptimize or WP Rocket bundle and minify your assets with minimal configuration.

A CDN stores copies of your website's static files on servers distributed around the world. When a visitor in Singapore requests your website, the files are served from a nearby edge server rather than your origin server, which could be located anywhere.

For Singapore businesses, this matters more than you might think. If your hosting server is in the US or Europe, every request has to travel thousands of kilometres and back. That round trip adds 200-400ms of latency per request. A CDN with Singapore edge servers eliminates most of that latency, serving content from a data centre that is physically close to your visitors.

The best CDN options for Singapore businesses in 2026:

• Cloudflare: free tier includes global CDN with a Singapore point of presence (POP). Also adds DDoS protection and SSL. We use this for most of our client projects
• Vercel Edge Network: automatically included when you deploy on Vercel. Excellent for Astro, Next.js, and other modern frameworks. Singapore edge node included
• AWS CloudFront: enterprise-grade CDN with a Singapore region. More complex to set up but highly configurable
• BunnyCDN: affordable option with consistently fast performance in Southeast Asia

Setting up Cloudflare's free CDN takes about 15 minutes. You change your domain's nameservers to Cloudflare, and they handle the rest. For a change that small, the speed improvement is substantial: we typically see 100-300ms reduction in Time to First Byte (TTFB) for Singapore visitors.

Your homepage might have 20 images, but a visitor only sees three or four when the page first loads (the "above the fold" content). Why make the browser download all 20 images upfront when most of them are not even visible yet?

Lazy loading defers the loading of offscreen images and videos until the user scrolls near them. This means the initial page load is dramatically faster because the browser only fetches what is immediately needed. For image-heavy pages, lazy loading can reduce initial page weight by 50-70%.

The good news: implementing lazy loading is now trivially easy. Modern browsers support native lazy loading with a single HTML attribute:

<img src="photo.webp" loading="lazy" alt="Description">

A few important caveats:

• Do NOT lazy load your hero image or anything above the fold. These should load immediately. Lazy loading your LCP image will actually hurt your Core Web Vitals score
• Set explicit width and height attributes on every image. This reserves the correct amount of space before the image loads, preventing layout shifts (which affect your CLS score)
• For videos, use the preload="none" attribute and load them only on user interaction, or use a static thumbnail with a play button that loads the video player on click
• For background images loaded via CSS, native lazy loading does not work. Use the Intersection Observer API to load these dynamically

We lazy load every image below the fold on all websites we build. It is one of the simplest changes with the most reliable results.

Time to First Byte (TTFB) measures how long it takes for the server to respond to a browser's request. It is the very first step in loading a page, and if it is slow, everything else is delayed. Google recommends a TTFB under 800ms, but for competitive rankings, aim for under 200ms.

The biggest factors that affect TTFB:

• Hosting quality: cheap shared hosting in Singapore typically delivers TTFB of 500-1500ms. A quality VPS or managed hosting plan can cut that to 100-300ms. Platforms like Vercel and Netlify serve static sites with TTFB under 50ms
• Server location: if your visitors are in Singapore but your server is in the US, physics alone adds 200-400ms. Choose hosting with Singapore-based or nearby regional servers
• Database queries: for WordPress and other CMS-driven sites, slow database queries are a common bottleneck. Every page load might trigger 50-200 database queries. Object caching (Redis or Memcached) can reduce this dramatically
• PHP version: if you are running WordPress on PHP 7.4, upgrading to PHP 8.2 or 8.3 can improve performance by 20-40% with zero code changes

For WordPress sites, the most impactful change is often implementing full-page caching so the server returns a pre-built HTML file instead of rebuilding the page from the database on every request. This can take TTFB from 800ms to under 100ms.

For maximum performance, consider static site generators like Astro. Because pages are pre-built at deploy time, there is no server-side processing at all. The server simply returns a file. TTFB is typically 20-50ms.

This one is particularly relevant for WordPress sites, though it applies to any website that has accumulated third-party scripts over time.

We recently audited a Singapore e-commerce site that had 34 WordPress plugins installed. Only 18 were actually being used. The other 16, including two abandoned slider plugins, three analytics tools (they only needed one), and several "just in case" utilities, were adding over 1.2MB of JavaScript and CSS to every page load. After removing the unused plugins and consolidating the rest, page load time dropped by 2.3 seconds.

Common culprits to audit:

• Multiple analytics scripts: do you really need Google Analytics, Hotjar, Facebook Pixel, and three other tracking scripts all running simultaneously? Each one adds 30-100KB of JavaScript
• Social media widgets: embedded Facebook feeds, Twitter timelines, and Instagram grids load massive external scripts. Replace them with simple icon links that cost essentially zero bytes
• Chat widgets: live chat scripts are notoriously heavy (200-500KB). Load them only after user interaction, not on initial page load
• Unused WordPress plugins: deactivated plugins do not add overhead, but they are a security risk. Completely remove anything you are not using
• Old A/B testing scripts: these are frequently left running long after the test is finished

Run PageSpeed Insights and check the "Reduce unused JavaScript" audit. It tells you exactly which scripts are loading unnecessarily and how much weight they add. Slow load times caused by script bloat are one of the most common website mistakes that kill sales for Singapore businesses.

When a browser loads your page, it downloads the entire CSS file before rendering anything. If your stylesheet is 200KB (common for WordPress themes), the browser has to download and parse all of it before showing a single pixel on screen. This blocks rendering and directly hurts your Largest Contentful Paint (LCP) score.

Critical CSS solves this by identifying the styles needed for the above-the-fold content and inlining them directly into the HTML. The rest of the CSS loads asynchronously in the background. The result: the browser can start rendering the visible part of the page almost immediately, even before the full stylesheet is downloaded.

How to implement critical CSS:

• Automated tools: Critical (npm package) analyses your page and extracts the above-the-fold CSS automatically. Penthouse is another popular option
• WordPress plugins: WP Rocket includes automatic critical CSS generation. Autoptimize can also handle this with the right settings
• Modern frameworks: Astro automatically scopes CSS to components, and its build process eliminates unused styles. This effectively gives you critical CSS without extra configuration

For a practical example: one of our clients had a 240KB stylesheet. Their above-the-fold content only needed 12KB of that CSS. By inlining those 12KB and deferring the rest, their LCP improved from 3.8 seconds to 2.1 seconds. The user perceived the page as loading nearly twice as fast, even though the total download size was identical.

If you are building a new site, choosing a framework like Astro that handles CSS efficiently from the start is far easier than retrofitting critical CSS onto an existing WordPress theme. That said, for existing sites, this optimisation is well worth the effort.

Custom fonts make your brand look polished, but they come at a performance cost. Each font weight (regular, bold, italic) is a separate file, typically 20-50KB each. A site using two font families with four weights each could be loading 200-400KB of font files before any text appears on screen.

Worse, some implementations cause a Flash of Invisible Text (FOIT), where the page loads but text is completely invisible until the font finishes downloading. Visitors see a blank page with images but no words. That is a terrible user experience.

Here is how to optimise your web fonts:

• Use font-display: swap: this tells the browser to show text immediately in a fallback font, then swap to the custom font once it loads. Text is always visible, even on slow connections
• Subset your fonts: if you only need Latin characters, do not load the full font file that includes Cyrillic, Greek, and extended characters. Google Fonts does this automatically; for self-hosted fonts, use tools like Glyphhanger or Fontsquirrel's generator
• Limit font weights: do you really need thin, light, regular, medium, semibold, bold, and black? Most websites work perfectly with two to three weights (regular, medium or semibold, bold)
• Self-host your fonts: loading fonts from Google Fonts requires a DNS lookup and connection to Google's servers. Self-hosting eliminates that overhead. Download the WOFF2 files and serve them from your own domain
• Preload critical fonts: add <link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin> to tell the browser to start downloading fonts early

The nuclear option: use a system font stack entirely. font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif looks clean on every device and loads with zero additional bytes. For sites where speed is the absolute priority (landing pages, tools), this is worth considering.

Sometimes the biggest performance gains do not come from tweaking settings. They come from choosing the right foundation in the first place.

The reality is that some platforms are inherently faster than others. A default WordPress installation with a popular theme like Avada or Divi sends 1-3MB of JavaScript to the browser on every page load. Much of that JavaScript is for features the specific page does not even use. It is like bringing your entire wardrobe to the office when you only need one outfit.

Here is how the major platforms compare for performance in 2026:

• Static site generators (Astro, Hugo, Eleventy): fastest possible performance. Pages are pre-built HTML with minimal or zero JavaScript. Typical page sizes of 50-200KB total. We build our own site on Astro, and our homepage loads in under 1.5 seconds
• Modern React frameworks (Next.js, Remix): good performance with proper configuration, but require discipline. Server-side rendering helps initial load, but hydration can add 200-500KB of JavaScript
• Optimised WordPress: with proper caching, a lightweight theme, and careful plugin management, WordPress can achieve 2-3 second load times. But it requires ongoing maintenance
• Default WordPress with page builders: the worst performer. Elementor, Divi, and WPBakery add enormous amounts of CSS and JavaScript. We have seen page builder sites loading 5-8MB per page

If you are starting a new project, the platform choice is the most important performance decision you will make. Read our detailed comparison of Astro, Next.js, and WordPress to understand which framework fits your needs and budget.

If you are stuck with WordPress and cannot migrate, focus on every other optimisation in this guide. A well-optimised WordPress site can still deliver acceptable performance; it just takes more effort to get there.

Server-side compression reduces the size of files transferred between your server and the visitor's browser. Think of it as zipping a folder before emailing it. The content is identical; it just takes up less space during transit.

Gzip compression reduces text-based files (HTML, CSS, JavaScript, SVG, JSON) by approximately 70%. A 100KB CSS file becomes roughly 30KB over the wire. Brotli, the newer compression algorithm developed by Google, is even more efficient, delivering 15-20% better compression than Gzip.

The best part: enabling compression is usually a server configuration change that takes minutes. Here is how to do it:

• Check if it is already enabled: open Chrome DevTools, go to the Network tab, and look at the "Content-Encoding" response header. If it shows "gzip" or "br" (Brotli), you are already set
• Apache: enable mod_deflate and add compression rules to your .htaccess file
• Nginx: add gzip on; and configure gzip_types in your server config
• Cloudflare: Brotli compression is enabled by default on all plans, including the free tier
• Vercel and Netlify: both enable Brotli compression automatically. No configuration needed
• WordPress: most caching plugins (WP Rocket, W3 Total Cache) enable Gzip as part of their setup

There is almost no reason not to have compression enabled. The CPU overhead is negligible on modern servers, and the bandwidth savings are substantial. If your site is not using compression, enabling it is one of the quickest performance wins available.

Core Web Vitals are Google's metrics for measuring user experience, and they directly influence your search rankings. There are three metrics that matter, and each one has specific fixes:

Largest Contentful Paint (LCP): target under 2.5 seconds

LCP measures how long it takes for the largest visible element (usually a hero image or heading) to fully render. To improve it:

• Preload your LCP image with <link rel="preload">
• Serve the LCP image in WebP or AVIF format at the correct dimensions
• Avoid lazy loading above-the-fold images
• Reduce server response time (see section 6 on TTFB)
• Inline critical CSS so the browser does not wait for the full stylesheet (see section 8)

Cumulative Layout Shift (CLS): target under 0.1

CLS measures unexpected layout shifts, those annoying moments when a button moves just as you are about to tap it. Common causes and fixes:

• Always set width and height attributes on images and videos so the browser reserves the correct space
• Use font-display: swap with a fallback font that closely matches your custom font's dimensions
• Reserve space for ads and embeds with fixed-size containers
• Avoid injecting content above existing content after the page has loaded (common with cookie banners and notification bars)

Interaction to Next Paint (INP): target under 200ms

INP replaced First Input Delay in March 2024 and measures how quickly your page responds to user interactions (clicks, taps, key presses) throughout the entire visit. To improve it:

• Break up long JavaScript tasks into smaller, asynchronous chunks so the main thread is not blocked
• Use requestAnimationFrame or requestIdleCallback for non-critical work
• Reduce the amount of JavaScript on the page (fewer event handlers, lighter libraries)
• Debounce or throttle expensive event handlers (scroll, resize, input)

To measure your Core Web Vitals, use PageSpeed Insights for lab data, and check the Core Web Vitals report in Google Search Console for real-user field data. Both are free. For deeper analysis, GTmetrix and WebPageTest offer waterfall charts that show exactly where your load time is being spent.

For a deeper dive into each metric, read our complete Core Web Vitals guide for Singapore businesses.