More insights.
Subscribe to our newsletter.
Deep dives into design thinking, creative process, and the intersection of business and aesthetics.
Imagine someone in Limerick needs an electrician before the weekend. They search on their phone, open a business website and wait while the page loads. They may return to the results and contact another supplier. That is a possible failure in the enquiry journey; finding out whether it is happening on your own site requires evidence.
Most businesses file website speed under IT. For a local service business it’s a sales problem. You paid for that visibility, through search work or advertising, and then kept the door locked while the customer stood outside it.
What a slow page costs you
A slow or unstable page can make a simple enquiry harder. To understand the commercial effect on your own site, compare real visitor behaviour with the time, device and page conditions they experienced. A conversion statistic from another business cannot establish how many enquiries your website is losing.
Google uses Core Web Vitals in its ranking systems, but a good score does not guarantee a high position. Speed is one part of the experience; relevance, useful content and the wider search context still matter. Measure local search visibility separately from page performance, so a ranking change is not automatically attributed to a faster test.
Where the weight usually comes from
Most slow-loading sites are slow for dull reasons: the platform they were built on, and the way they’ve been looked after since launch.
Older sites often run on heavy, general-purpose themes packed with features nobody uses. Over the years plugins pile up on top for analytics, forms, pop-ups, sliders and chat. Many load their own scripts and stylesheets on every page whether it needs them or not, and the browser has to work through all of it before it can show anything useful. Add a few uncompressed photos straight from a phone and a sluggish page becomes a properly slow one.
Test it on a phone, then fix what you find
Start by meeting the site the way your customers do: on your own phone, on mobile data rather than the office wifi, arriving from a Google search rather than a bookmark. If you find yourself waiting, so are they. For the technical detail on how quickly your main content appears, Google’s web.dev guidance on optimising Largest Contentful Paint is a good place to start. Most of the fixes are housekeeping, with no developer needed:
Serve images at appropriate dimensions and compression for the display size. Compare visual quality and transferred bytes, then check which asset is delaying the main content; one file-size target will not suit every image.
Audit plugins and their dependencies before removing anything. Keep a recoverable backup, test the change away from the live site and recheck forms, consent, bookings and other affected functions.
Review third-party scripts against a named business purpose. Check consent, reporting and integrations before changing how a script loads, then retest the visitor journey.
Look hard at your hosting. Cheap shared hosting puts your site on a crowded server, and if the server itself is slow, no amount of image compression will save you. A good managed host, or a rebuild on a leaner setup, is sometimes the only real fix. It’s also the expensive end, so do the other three first and measure again.
A faster page removes one possible obstacle, but buyers still need a useful service, credible evidence and an enquiry route that works. Repeat the same checks when a plugin, tracking script or large image changes, and keep a record of what was tested.
Loading, response and layout stability are different problems
Largest Contentful Paint measures when the main content appears. Interaction to Next Paint measures responsiveness to user input. Cumulative Layout Shift measures unexpected visual movement. A page can load its first heading quickly and still react slowly when someone opens the menu or uses the enquiry form.
Google’s current good thresholds are LCP within 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1, assessed at the 75th percentile of real visits, with mobile and desktop considered separately. See the Web Vitals guidance for the definitions and measurement limits.
Keep field evidence separate from a lab test
Field data describes visits by real people over the reporting period. A lab trace describes a controlled test under stated conditions. Record the URL, date, browser, viewport, network and CPU settings, cache state and consent choice. If field data is unavailable, label it unavailable; a lab result is still useful, but it does not establish that real visitors pass all Core Web Vitals.
In our 16 October 2026 Chrome DevTools check of the Brainstorm Ireland page, LCP was 10.778 seconds before the correction and 0.921 seconds in the live follow-up. CLS was 0.02 in both traces. Both used a 390 × 844 mobile viewport, Slow 4G network emulation, four-times CPU slowdown, a cold HTTP reload and reduced motion. The trace identified text waiting for an entrance effect, so we made the opening heading, explanation and project buttons visible in the initial HTML. We retained the conditions and trace evidence. Interpret those figures as individual lab observations under the stated settings; real-user performance and commercial results need separate measurement.
Test the enquiry route as well as the homepage
Open a service page, follow its project link, complete representative form fields and check validation. With an agreed test submission, reconcile the success screen with the receiving system and the analytics event. Keep artificial test leads out of commercial reporting. A recorded event, a delivered message and a qualified enquiry are separate stages.
Change one identified bottleneck, repeat the same lab conditions and inspect the live journey. Then watch comparable field and enquiry data long enough to judge the result. A better score can support an improvement, but it does not prove that the change caused extra sales. Google’s page-experience guidance explains why performance scores should serve users rather than become the sole SEO target.
A targeted performance and support review may be enough when the content and CMS still serve the business. Use website design work when the underlying structure also needs to change.
Related Brainstorm services and work
Website and technical SEO services · Technology website design · Request a performance review
Updated 16 October 2026. Dave Curtin, founder and Creative Director of Brainstorm, leads website strategy, brand direction and technical delivery for Brainstorm clients.
Imagine someone in Limerick needs an electrician before the weekend. They search on their phone, open a business website and wait while the page loads. They may return to the results and contact another supplier. That is a possible failure in the enquiry journey; finding out whether it is happening on your own site requires evidence.
Most businesses file website speed under IT. For a local service business it’s a sales problem. You paid for that visibility, through search work or advertising, and then kept the door locked while the customer stood outside it.
What a slow page costs you
A slow or unstable page can make a simple enquiry harder. To understand the commercial effect on your own site, compare real visitor behaviour with the time, device and page conditions they experienced. A conversion statistic from another business cannot establish how many enquiries your website is losing.
Google uses Core Web Vitals in its ranking systems, but a good score does not guarantee a high position. Speed is one part of the experience; relevance, useful content and the wider search context still matter. Measure local search visibility separately from page performance, so a ranking change is not automatically attributed to a faster test.
Where the weight usually comes from
Most slow-loading sites are slow for dull reasons: the platform they were built on, and the way they’ve been looked after since launch.
Older sites often run on heavy, general-purpose themes packed with features nobody uses. Over the years plugins pile up on top for analytics, forms, pop-ups, sliders and chat. Many load their own scripts and stylesheets on every page whether it needs them or not, and the browser has to work through all of it before it can show anything useful. Add a few uncompressed photos straight from a phone and a sluggish page becomes a properly slow one.
Test it on a phone, then fix what you find
Start by meeting the site the way your customers do: on your own phone, on mobile data rather than the office wifi, arriving from a Google search rather than a bookmark. If you find yourself waiting, so are they. For the technical detail on how quickly your main content appears, Google’s web.dev guidance on optimising Largest Contentful Paint is a good place to start. Most of the fixes are housekeeping, with no developer needed:
Serve images at appropriate dimensions and compression for the display size. Compare visual quality and transferred bytes, then check which asset is delaying the main content; one file-size target will not suit every image.
Audit plugins and their dependencies before removing anything. Keep a recoverable backup, test the change away from the live site and recheck forms, consent, bookings and other affected functions.
Review third-party scripts against a named business purpose. Check consent, reporting and integrations before changing how a script loads, then retest the visitor journey.
Look hard at your hosting. Cheap shared hosting puts your site on a crowded server, and if the server itself is slow, no amount of image compression will save you. A good managed host, or a rebuild on a leaner setup, is sometimes the only real fix. It’s also the expensive end, so do the other three first and measure again.
A faster page removes one possible obstacle, but buyers still need a useful service, credible evidence and an enquiry route that works. Repeat the same checks when a plugin, tracking script or large image changes, and keep a record of what was tested.
Loading, response and layout stability are different problems
Largest Contentful Paint measures when the main content appears. Interaction to Next Paint measures responsiveness to user input. Cumulative Layout Shift measures unexpected visual movement. A page can load its first heading quickly and still react slowly when someone opens the menu or uses the enquiry form.
Google’s current good thresholds are LCP within 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1, assessed at the 75th percentile of real visits, with mobile and desktop considered separately. See the Web Vitals guidance for the definitions and measurement limits.
Keep field evidence separate from a lab test
Field data describes visits by real people over the reporting period. A lab trace describes a controlled test under stated conditions. Record the URL, date, browser, viewport, network and CPU settings, cache state and consent choice. If field data is unavailable, label it unavailable; a lab result is still useful, but it does not establish that real visitors pass all Core Web Vitals.
In our 16 October 2026 Chrome DevTools check of the Brainstorm Ireland page, LCP was 10.778 seconds before the correction and 0.921 seconds in the live follow-up. CLS was 0.02 in both traces. Both used a 390 × 844 mobile viewport, Slow 4G network emulation, four-times CPU slowdown, a cold HTTP reload and reduced motion. The trace identified text waiting for an entrance effect, so we made the opening heading, explanation and project buttons visible in the initial HTML. We retained the conditions and trace evidence. Interpret those figures as individual lab observations under the stated settings; real-user performance and commercial results need separate measurement.
Test the enquiry route as well as the homepage
Open a service page, follow its project link, complete representative form fields and check validation. With an agreed test submission, reconcile the success screen with the receiving system and the analytics event. Keep artificial test leads out of commercial reporting. A recorded event, a delivered message and a qualified enquiry are separate stages.
Change one identified bottleneck, repeat the same lab conditions and inspect the live journey. Then watch comparable field and enquiry data long enough to judge the result. A better score can support an improvement, but it does not prove that the change caused extra sales. Google’s page-experience guidance explains why performance scores should serve users rather than become the sole SEO target.
A targeted performance and support review may be enough when the content and CMS still serve the business. Use website design work when the underlying structure also needs to change.
Related Brainstorm services and work
Website and technical SEO services · Technology website design · Request a performance review
Updated 16 October 2026. Dave Curtin, founder and Creative Director of Brainstorm, leads website strategy, brand direction and technical delivery for Brainstorm clients.