Website Performance for Australian Small Businesses: Core Web Vitals, Lighthouse, Images & Fonts

Short answer: website performance work should start with the exact page, device profile and customer action. There is no universal first fix. Images may dominate one site, while server response, JavaScript, fonts, consent tools or third-party embeds dominate another.

Define what must keep working

Write down the page's business job before optimisation: explain a service, show a product, accept a booking, submit an enquiry or complete checkout. Record the primary mobile path and any accessibility requirements. This prevents a technically faster build from breaking the thing the visitor came to do.

For search work, also record the canonical URL, indexability, rendered main content and internal links. A speed repair that hides useful text behind a failed script or changes the preferred URL can create a larger SEO problem than it solves.

Separate lab and field evidence

Lighthouse and PageSpeed Insights can run controlled lab tests that expose resource and main-thread behaviour. The Chrome User Experience Report provides eligible aggregated field data from real Chrome users. They are related but not interchangeable.

Save the test URL, date, mobile or desktop profile, throttling and tool version. Run the same test more than once because lab results vary. If page-level field data is unavailable, say so; origin-level data does not prove every template.

Understand the current Core Web Vitals

The current Core Web Vitals cover loading, interaction and visual stability: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. The Web Vitals documentation explains their measurement and recommended thresholds.

Google includes Core Web Vitals within its broader page-experience systems. They are not a substitute for relevance, helpful content or trust, and passing them does not guarantee a rank. Use the Google Search page-experience guidance for the current search context.

Diagnose the actual bottleneck

• Images: compare transfer bytes with displayed dimensions, formats, compression, fetch priority and lazy-loading. Preserve enough quality for the page's purpose.
• Server response: inspect origin work, cache status, redirects and geographic delivery. A content delivery network can help static assets, but it does not repair slow application work automatically.
• JavaScript: identify long tasks, unused code and third-party work. Defer optional scripts and keep the primary content and action resilient.
• Fonts: check real files, weights, subsets, font-display behaviour, preloads and layout shifts. Do not download weights the design does not use.
• Layout: reserve space for images, embeds, banners and asynchronous components.
• Interaction: inspect what runs after a tap or keypress, particularly widgets, menus, validation and analytics hooks.

Handle images with page context

An image should be exported near the dimensions the layout needs and served in a suitable format and quality. Responsive srcset and sizes attributes can prevent a small screen downloading a desktop-sized file. Below-the-fold media can often be lazy-loaded; the likely largest above-the-fold image usually needs different treatment.

Do not impose one file-size target on every asset. A small icon, portrait, product-detail image and architect portfolio photograph have different jobs. Record the before and after bytes, visual review and performance evidence.

Keep fonts and motion deliberate

Fonts and motion can support identity and navigation, but they also consume resources. Use WOFF2 where supported, subset cautiously, load only required weights and test fallback behaviour. Preload only resources that are genuinely critical; too many preloads compete with the page's main content.

Motion must respect prefers-reduced-motion and should not block reading or interaction. Measure its script, main-thread and layout cost. Keep it when its purpose and treatment are defensible; simplify it when the measured cost or accessibility risk is not.

Control third-party code

Chat widgets, advertising tags, consent managers, booking tools and analytics can materially affect a page. Inventory each one, its owner and its business purpose. Load it only on the pages and at the time it is needed where the product allows that safely.

Do not remove measurement merely to improve a lab score without understanding the commercial consequence. Likewise, do not keep duplicate or unused tags because nobody owns them. A repair package should name the third party, evidence, approved change and rollback.

Apply, verify and watch

1. Save the baseline trace, field evidence and primary-journey check.
2. Choose the highest-value verified repair, not the easiest generic tip.
3. Implement it in a reviewable change with a rollback.
4. Repeat the same lab tests and compare variation, not just the best run.
5. Verify rendered content, accessibility, forms, calls, booking or checkout on real mobile and desktop paths.
6. After deployment, watch field evidence, errors and qualified customer outcomes over an appropriate period.

If several repairs must ship together, call the result a bundle. A before-and-after movement can support the bundle, but it does not prove which individual change caused it.

What a client should receive

A useful monthly performance receipt contains affected URLs, baseline evidence, applied changes, public verification, field-data status, accessibility checks, customer-journey checks, known third-party limits and the next review date. It should distinguish local preparation from a live deployment.

For a narrower diagnostic, read how to use Lighthouse without chasing a score. Our website service explains the implementation scope, and the site audit provides a page-specific starting point without promising a fixed score, rank or conversion result.