Web Performance

Website Speed Basics: Practical Improvements for Mobile Visitors

Images, JavaScript, caching and layout stability: the changes that make the biggest difference on mid-range phones and slower connections.

Many of your visitors will open your website on a mid-range Android phone over a mobile connection that changes from one minute to the next. A page that feels instant on a developer's laptop can take many seconds there. Speed is therefore part of the user experience, not a vanity score, and it affects whether people stay, read, buy or leave. This guide covers the changes that usually make the biggest difference, in the order that is most worth doing.

What "fast" means: the three measurements that matter

Google's Core Web Vitals describe real user experience in three measures. You do not need to memorise tools, only the targets for a "good" experience:

MetricWhat it measuresGood target
LCP (Largest Contentful Paint)How quickly the main content appears2.5 seconds or less
INP (Interaction to Next Paint)How quickly the page responds to taps and clicks200 milliseconds or less
CLS (Cumulative Layout Shift)How much the layout jumps while loading0.1 or less

Free tools such as PageSpeed Insights and the Lighthouse panel in Chrome DevTools report these. Use them to find your biggest problem, then fix that first.

Measure first, on a realistic setup

Test the way your visitors browse, not the way you develop. In Chrome DevTools, open the Network panel, choose a throttled profile such as "Fast 3G" or "Slow 4G", and enable CPU throttling in the Performance panel. Reload the page and look at three things: how long until something useful appears, how many kilobytes were downloaded, and which files were largest.

Write down the numbers before you change anything. Without a baseline you cannot tell whether a change helped, and you may spend a week optimising something that was never the bottleneck.

Optimise images first

On most sites, images account for the majority of downloaded bytes, which makes them the easiest large win.

  • Resize to the displayed size. A photo displayed 400 pixels wide does not need to be 4000 pixels wide. Serve roughly twice the display width at most, to cover high-density screens.
  • Use modern formats. WebP and AVIF are usually much smaller than JPEG or PNG at similar quality, and are widely supported. Keep a JPEG fallback if you must support very old browsers.
  • Compress. A quality setting around 75 to 85 is usually visually indistinguishable for photos.
  • Lazy-load below-the-fold images with loading="lazy", but do not lazy-load the main image at the top of the page.
  • Set width and height attributes so the browser reserves space and the layout does not jump.
<img src="/img/team-800.webp"
     srcset="/img/team-400.webp 400w, /img/team-800.webp 800w"
     sizes="(max-width: 600px) 100vw, 600px"
     width="800" height="533" loading="lazy" alt="The team at work">

Reduce and defer JavaScript

JavaScript costs three times: downloading it, parsing it and running it. On a mid-range phone the processing cost is often larger than the download cost.

  • Remove libraries you do not use. A page that needs a menu toggle and a form does not need a large framework.
  • Load scripts with defer so they do not block the page from rendering.
  • Load heavy widgets (chat, maps, video embeds) only when the visitor asks for them, for example by showing a static preview and loading the real widget on click.
  • Check what each third-party script actually does for you. Remove the ones that do nothing useful.

Keep the first screen simple

The first screen is what visitors judge you by. Make sure the content they came for can appear without waiting for everything else.

  • Use a clear heading and short introduction at the top rather than a large slider or video.
  • Inline only the small amount of CSS needed for the first screen if you can, and keep the rest in a cached stylesheet.
  • Limit web fonts. Each font weight is another download. Use font-display: swap so text shows immediately in a fallback font, and consider a system font stack for body text.
  • Preconnect to origins you must use, such as your font provider, with <link rel="preconnect">.

Use caching carefully

Caching stops visitors from downloading the same files on every visit. Static files such as images, CSS and JavaScript should be cached for a long time, and renamed or versioned when they change so browsers fetch the new copy.

# .htaccess: cache static assets for one year
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType text/css  "access plus 1 year"
  ExpiresByType application/javascript "access plus 1 year"
</IfModule>

# Compress text responses
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json
</IfModule>

Version your assets by adding a query string such as style.css?v=8 and increasing it when you deploy. Be careful with dynamic pages: cache a page only if it does not contain information that is specific to one visitor.

Prevent layout shift

A page can feel slow even when its files download quickly, if content jumps as it loads. The usual causes are images without dimensions, late-loading fonts, and banners or ads injected above content.

  • Always set width and height (or CSS aspect-ratio) on images and embeds.
  • Reserve space for advertising units with a minimum height so the page does not jump when an ad loads.
  • Avoid inserting new content above what the visitor is already reading.

Watch third-party services

Analytics, chat widgets, social feeds, video embeds and advertising scripts all add network requests and processing. They are often the reason a lightweight page feels heavy. Keep only the ones that earn their place, load them after the main content where the provider allows, and re-measure after adding any new one. If a page must show ads, test it with the ad scripts enabled, because that is what visitors will experience.

Make speed a habit

Sites get slower gradually as content and features are added. Re-run your measurements after major changes, test on a real phone, and keep a short list of numbers you care about (page weight, LCP and CLS on your main pages). The goal is not a perfect laboratory score. It is a site that stays useful and responsive for the people who actually visit it.

Quick wins checklist

  • Resize and compress every image; convert photos to WebP.
  • Add defer to scripts and remove unused libraries.
  • Enable compression and long-lived caching for static files.
  • Set image dimensions and reserve space for ads and embeds.
  • Limit fonts and third-party widgets.

Found a mistake or an outdated detail? Email contact@abtech.com.et and we will review it. See our Editorial Policy.