Website speed optimisation: a UK buyer’s guide

Website speed optimisation improves how quickly useful content appears, how promptly controls respond and how stable a page remains. UK buyers should commission it around specific customer tasks, a documented baseline and comparable checks. Choose fixes from evidence, preserve important enquiry functions and judge commercial outcomes separately from technical test scores.

A speed report can leave you with a number and very little clarity about what to buy. One supplier recommends new hosting, another proposes image compression, and a third suggests rebuilding the website. Meanwhile, your sales team still hears that a customer could not complete the booking form.

This guide helps business owners and marketing teams turn that situation into a defined project. It covers diagnosis, practical trade-offs, proposal comparison and acceptance, with questions you can use even if you do not write code. Technical guidance was first checked on 7 October 2026 and the thresholds, Search Console validation rules and published UK price ranges were rechecked on 15 October 2026. The business scenarios and cost comparison are hypothetical illustrations, not GRO client results. Use the sections relevant to your current decision, then return to the maintenance guidance when the work is delivered.

The short version:

• Start with a customer task, not a score. Name the page, the action and the interruption somebody experiences, then measure that journey.
• Google’s three Core Web Vitals have fixed thresholds. Good means LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, judged at the 75th percentile of real visits.
• Field data and lab tests answer different questions. Search Console and the field section of PageSpeed Insights describe the last 28 days of real Chrome visits; a Lighthouse run describes one controlled load.
• Match the fix to the slow metric. Slow LCP usually points to server response, image discovery or render blocking; slow INP to heavy JavaScript and third party tags; poor CLS to media and embeds without reserved space.
• Published UK prices vary widely. Two UK suppliers publish audits from about £1,200 to £3,000 and focused fixes from about £600 to £9,000, so compare written quotes for the same scope.
• Allow four weeks before judging field results. Search Console validation watches the affected URLs for 28 days, and the field data needs time to replace visits from before the release.

Decide which customer problem needs fixing

Website speed optimisation should begin with a task somebody struggles to complete. A visitor may wait for product details, tap a menu without a visible response, or lose their place when an image appears. Those experiences can have different causes. Describing the particular interruption gives a supplier a useful starting point and gives you something recognisable to check after the work.

A report showing a poor score is a reason to investigate. Before commissioning changes, ask which pages the report covers and whether the problem appears in the customer journey. The homepage might load comfortably while a quotation page stalls after somebody selects a product. A project focused entirely on the homepage could leave the commercially important interruption untouched.

Start with an observable account

Write a short incident description: the page, the action, the visible result and the circumstances. For example, a hypothetical equipment supplier might record that opening its specification selector leaves the screen unchanged until a second tap. Include the approximate time and device if known. Avoid diagnosing the cause in the same sentence; the supplier still needs to investigate it.

Collect a few examples from customer-facing colleagues. Ask sales what callers say about booking or sending information. Ask support whether customers report missing confirmations. These accounts can identify a route worth examining, but they do not establish its frequency. Keep the distinction between a reported incident and a measured pattern visible in the brief.

Give the page a purpose. A specification page helps somebody judge suitability; a booking page helps them choose an appointment. That purpose determines what must remain after optimisation. Removing the specification tool may reduce page weight while creating extra work for the buyer. Agree which functions are essential before a developer starts deciding what the page can omit.

Consider the route into the page. People arriving from an advert may have less context than returning customers following a saved link. A delayed headline or hidden price condition can affect their understanding of the offer. Choose representative entry points rather than assuming everyone begins at the homepage and follows the same sequence of pages.

Choose a manageable first scope

Group pages by their underlying design. Ten service pages built from one template may share the same image treatment and booking embed. One representative page can help diagnose that template, followed by checks across its variations. A calculator built differently needs separate attention. The number of URLs alone is a poor description of the investigation required.

Give priority to routes with both a meaningful customer purpose and evidence of difficulty. A rarely visited archive can wait if a quotation form regularly hesitates. A high-traffic page is still worth examining even when it generates few direct enquiries, because it may help buyers compare services. Explain its role rather than assigning importance solely from a conversion column.

Separate urgency from expected effort. A broken submit button requires prompt attention even if it is unrelated to speed. A slow decorative animation may be easy to remove but less urgent. Put actual failures, measured delays and optional improvements in separate groups so the project does not spend its first week solving the easiest issue while a customer cannot make contact.

Choose a named internal owner for the decision. Marketing can describe the intended journey, while the website owner can explain technical dependencies. Sales may need to confirm that enquiries arrive. One person should hold the combined scope and resolve competing requests. Otherwise a performance project can become a series of disconnected changes made for different departments.

Campaign landing pages often deserve the first slot because every slow visit is paid for. Google Ads rates landing page experience as one of the three Quality Score components, describing it as how relevant and useful the page is to people who click the ad. Speed is not the whole of that judgement, but a page that is slow to show the offer or respond to the form works against it. Our guides to choosing a Google Ads agency and choosing a Meta Ads agency explain how to make landing page checks part of an advertising brief.

Keep commercial expectations testable

A faster page can remove a source of friction. It cannot make an unsuitable service relevant or make an unanswered enquiry become a sale. Set a technical acceptance question, such as whether the identified delay has improved under comparable conditions, alongside a business question about the resulting journey. The first can often be answered earlier than the second.

Record other work happening at the same time. New advertising, a price change or a revised offer may affect enquiry numbers during the optimisation project. If several things change together, a rise in leads is not evidence that speed caused it. Keep the release notes and business context so later reporting can describe what is known without inventing certainty.

GRO’s website speed optimisation service starts with the affected pages and interactions. Use that kind of scope when comparing suppliers: an observed problem, an investigation, an agreed intervention and evidence of the result. A promise to make the whole website fast is too broad to tell either party when the work is complete.

For a small business, the first useful deliverable may be a concise diagnosis. You might learn that one image treatment affects every service page, or that a necessary external tool creates the main delay. That information helps you choose a proportionate next step. Buying a large implementation package before understanding the constraint can make a straightforward repair unnecessarily expensive.

Keep an explicit boundary around the first engagement. State the pages, tasks and systems included, the access available, and who can approve changes. Record excluded work without pretending it has been assessed. A supplier should be able to explain what it will know after discovery and which questions may still need a different specialist or a separate commercial decision.

The initial scope should also say when you would stop investigating. If the reported problem cannot be reproduced, the next step may be better evidence collection instead of speculative edits. Agree that possibility before work begins. A useful assessment can conclude that more information is needed; it should not manufacture a diagnosis simply because an implementation fee was expected.

Read performance reports without mixing their meanings

Performance reports answer different questions. A controlled test helps a developer investigate one page under specified conditions. Data gathered from real visits describes the experience represented in that dataset. An account from a customer describes an individual incident. Use them together, while keeping their boundaries clear. A disagreement between them is a question to explore, not a reason to discard whichever result is inconvenient.

Ask a supplier to label every result with its source and scope. The page address, device category, collection period and test conditions should be recoverable. A screenshot without that context can be impossible to compare with a later report. You do not need to master every technical setting, but somebody responsible for the work should be able to explain them.

Distinguish a visit history from a controlled test

Google’s PageSpeed Insights documentation explains that its field information comes from the Chrome User Experience Report and covers a trailing 28-day period. It may describe the tested URL or the wider origin. Check which is shown before attributing an assessment to one page. Missing field data does not establish that the page is fast or slow.

Laboratory results are useful for comparing an intervention before enough real visits have accumulated. They describe the chosen test conditions rather than every visitor. Ask for repeated comparable runs and an explanation of variation. Keep the underlying measurements with the overall score so an apparent improvement can be traced to the part of the experience that actually changed.

Suppose a developer repairs an image-loading problem today. A controlled test may show the effect immediately. A rolling field report still includes visits from before the repair, so the two reports need not agree straight away. Document the release date and allow the later review to distinguish historical experience from the newly delivered version.

The reverse situation also deserves attention. A comfortable field assessment can coexist with an awkward task used by only a small group. A particular product selector or consent state may be underrepresented in the headline result. Keep credible incident reports open until somebody has checked the relevant route. Aggregate evidence should guide investigation without making minority experiences disappear.

Understand the three Core Web Vitals

Google’s current Web Vitals guidance identifies Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. LCP concerns loading the largest eligible visible content element. INP concerns responsiveness to interaction. CLS concerns unexpected layout movement. Their good thresholds are respectively 2.5 seconds or less, 200 milliseconds or less, and 0.1 or less, assessed at the 75th percentile with mobile and desktop considered separately.

The Search Console Core Web Vitals report uses three bands for each metric. A group of similar URLs takes the status of its worst metric, so one failing measure is enough to keep a template out of the good band.

Those measures describe different aspects of the experience. A page may show its main content promptly yet hesitate when somebody uses a selector. Another may respond quickly but move the form as an embed arrives. Ask which measure supports the diagnosis and what the visitor experiences. Avoid accepting an improvement in one measurement as proof that every reported problem has been resolved.

The 75th percentile describes a position in a distribution, not an average visit or the slowest person. Keep that distinction when someone explains a pass. It does not mean every visitor had an identical experience. Your business may still need to investigate a difficult route, device or region even when the overall assessment meets the recommended thresholds.

A laboratory performance score is also different from the field assessment. For example, a page-load test without user interaction cannot directly observe the interactions your customers perform throughout a visit. Ask the reviewer to demonstrate the relevant control and explain any proxy measurement. A labelled estimate is useful; an unlabeled substitution can produce the wrong acceptance decision.

Know which tool answers which question

Suppliers often send screenshots from several free Google tools. They are not interchangeable, and a proposal is easier to judge when each finding names its source. The table below summarises what each one shows.

Lighthouse 13, released in October 2025, replaced many older performance audits with the same insight audits used in Chrome DevTools. Google says the change does not alter how the performance score is calculated. If a supplier’s report or dashboard still lists the old audit names, ask whether it uses a current version, because some findings now appear under different labels.

Compare like with like

Use the same page, relevant content and stated conditions when comparing versions. Record whether the visitor is new or returning and whether optional services have loaded. A cached second visit may behave differently from a first visit. Neither is automatically the only correct test; the point is to avoid presenting a change in conditions as an improvement in the website.

Keep a small evidence register rather than collecting screenshots in chat. Each entry should identify the question, version, test date, result and limitation. A developer can attach a detailed trace where needed, while the buyer sees a short explanation. That makes the final review understandable to somebody who did not attend every technical discussion during implementation.

If two suppliers disagree, ask each to reproduce its finding against the same scope. One may be testing a campaign page and the other the homepage. One may have accepted all optional tools, while the other has loaded none. Resolving that difference is more useful than choosing the more reassuring score or averaging numbers that describe unlike situations.

Do not use a blank report to fill a gap with a guess. A low-traffic page may lack sufficient public field coverage. Record that limitation and agree how controlled tests, appropriate monitoring and customer feedback will inform the decision. You can still commission sensible repairs without claiming that a public report proves a result it cannot currently show.

The report should end with a decision the evidence supports. That could be implementing a specific fix, gathering more information, asking another supplier to investigate, or accepting a known limitation. Keep the question visible throughout the document. A long list of diagnostics is useful only when it helps the business choose what to do about the customer experience.

Build a baseline across the journeys that matter

A baseline is a record of the experience before changes, collected in a way you can repeat. Its value comes from the selected journeys and the quality of the record. You do not need to test every possible combination before starting a contained project. You do need enough coverage to recognise whether the proposed work helps the people and tasks within scope.

Begin with a short route inventory. Include the main entry page, the page where buyers examine the offer and the action that creates an enquiry or booking. Add a materially different template when it introduces different behaviour. A business with a product configurator needs to cover that interaction even if most of the site consists of straightforward service pages.

Make each test case meaningful

Describe a task in ordinary language before listing its technical steps. A hypothetical training provider might ask a tester to find a course, check its location and request information. The expected result includes a usable page and a clear confirmation. It also includes the correct enquiry reaching the responsible team, if that delivery is affected by the planned work.

Use representative content. An almost empty test page may load differently from the actual page with photography, course dates and supporting material. Choose examples that reflect normal editorial use and the heavier cases you expect to support. Document the selection. That gives the developer a realistic target without asking them to optimise an artificial worst case nobody intends to publish.

Record the initial state. A visitor may already have consent preferences, a cached image or a partly completed form. These conditions can alter what loads and when. Include the states relevant to the issue, rather than assuming a clean browser tells the whole story. If a condition cannot be reproduced with the available tools, record the gap honestly.

Give each case an expected outcome and an owner. For an enquiry form, marketing can confirm the offer, sales can confirm receipt, and the developer can inspect technical behaviour. Keep the case in one shared record so those checks can be brought together. A passed visual inspection should not silently stand in for an unperformed delivery check.

Preserve evidence you can compare

Save the tested version or release identifier with the result. A URL alone may later display different content. Note the time, relevant settings and any unusual conditions. This does not require a complex testing platform; a disciplined record can be enough. The important point is that another person can understand what was actually observed and how to repeat it.

Ask for more than a cropped score. A useful baseline can include the affected element, a short recording of the task and the measurement supporting the diagnosis. Keep the material proportionate and avoid capturing customer details. Use approved test records for forms, and distinguish them from real enquiries so testing does not contaminate ordinary sales reporting.

Retain failed observations as well as successful ones. If a menu hesitates in one of several attempts, the variation is part of the evidence. A supplier may need to investigate why it appears intermittently. Selecting only the worst or best run makes the project harder to judge. A short explanation of the range is more useful than a dramatic isolated screenshot.

Capture the surrounding business conditions too. A seasonal campaign can change the mix of visitors and pages used. A new product can introduce a heavier template. These changes matter when you later examine field results or enquiries. The baseline should explain its period well enough that somebody can recognise when a later comparison needs qualification.

Include the whole enquiry route

Use the page’s actual onward links. Check that an important button takes the visitor to the intended destination and retains the context the next page needs. If a quotation request depends on selected options, those options should arrive accurately. Improving the first page while losing the customer’s selection creates a faster route to an avoidable misunderstanding.

For booking, distinguish displaying available times from completing an appointment. A tool may load while its confirmation or calendar connection fails. Decide which parts are affected by the proposed optimisation and check them accordingly. There is no need to retest an unrelated business process simply because it exists, but dependencies altered by the work should have named acceptance checks.

GRO’s guide to the lead generation funnel explains the wider connection between an enquiry and its follow-up. In a performance project, use that connection to choose the boundary of functional testing. Your concern is whether the changes preserve the handover, including the information the recipient needs to respond usefully.

Plan for an unavailable external service. If the page depends on a booking provider, decide what a visitor sees when that provider does not respond. A clear onward route or explanatory message may be appropriate. Keep the behaviour honest: a page should not imply a booking has been made when the external system has not confirmed it.

Review the baseline with the supplier before implementation. Confirm that it covers the agreed problem and that the comparison method is workable. Resolve disagreements while the original version is still available. Once the site has changed, reconstructing a disputed starting point can consume more time than establishing a modest, clear baseline at the beginning.

Finally, agree how acceptance will handle uncertainty. Some results may be measurable immediately, while others need more usage or a supplier response. Set a specific next review and owner for those items. A baseline supports a decision; it should not become an endless demand to test every conceivable situation before making a useful, bounded improvement.

Find the cause before buying the remedy

Several causes can produce the same complaint that a website feels slow. The server may take time to respond, the browser may discover an important image late, or a script may occupy the device when the visitor taps a control. Buying a remedy before identifying the delay can leave you paying for changes that barely affect the reported experience.

Ask the investigator to connect three things: what the visitor notices, what the evidence shows and why the proposed intervention should help. That explanation can be short. For example, the main image may be discovered only after another resource finishes. The relevant fix concerns its loading sequence, which is different from reducing the size of an image already arriving promptly.

Follow the sequence of work

Google’s LCP optimisation guidance breaks the loading experience into parts including server response, resource discovery and loading, and the delay before rendering. That separation is useful for buyers. Ask where time is being spent in the observed case. A smaller file may help transfer time while leaving a separate discovery or rendering delay unresolved.

Request a prioritised explanation of the main causes rather than a raw audit export. Automated tools can identify opportunities, but the developer must judge their relevance to the actual page. An item can be technically valid and commercially minor. The proposal should say which findings are expected to affect the agreed task and which are lower-priority housekeeping.

Look for shared causes across templates. A script included everywhere may affect many pages, whereas one oversized image affects a single campaign. The broad change can offer useful reach, but it also needs wider regression checks. Ask the supplier to state the affected components so you can balance the scope of improvement against the scope of possible disruption.

Distinguish a recurring architectural issue from an isolated publishing mistake. If editors repeatedly upload inappropriate images because the system accepts them without guidance, repairing today’s image will not prevent the next occurrence. The remedy might include a safer publishing process. If one exceptional page is the problem, a focused correction may be enough.

Match the symptom to common causes

The slow metric narrows the search. Google’s guides to LCP, INP and CLS describe the causes below in detail. Use the table to check that a proposed remedy fits the measurement it claims to improve.

Interactive tools deserve particular attention because they run code on every input. If your site uses a quote calculator or configurator, our guide to lead magnets and configurators explains how to keep them useful; include each one in the INP test plan.

Make ownership part of the diagnosis

Identify who controls the relevant layer. Your developer may control page markup but not an external booking widget. A managed website platform may restrict server behaviour. The hosting company may own configuration that the design agency cannot change. Record those boundaries before a proposal promises an outcome that depends on somebody outside the engagement.

Ask what evidence would justify involving another supplier. A vague statement that hosting is slow is difficult to act on. A reproducible finding, affected routes and a clear question give the provider something useful to investigate. Avoid making an immediate migration decision from one observation when the underlying issue could sit elsewhere in the delivery chain.

Consider constraints you knowingly accepted. A detailed product demonstration may require more resources than a plain service page. That does not remove the need to improve its delivery, but it changes the trade-off. Decide which experience the buyer needs and which parts can be offered after a deliberate action. Performance work should preserve the feature’s useful purpose.

GRO’s landing page design service addresses the journey around the offer. A performance assessment may identify a separate design problem, such as an unclear next step. Keep that finding visible without quietly adding a redesign to the speed scope. The business can then decide whether it needs one focused fix or a broader piece of work.

Test the working explanation

A useful diagnosis makes a prediction that can be checked. If the developer believes a nonessential script is delaying an interaction, a controlled comparison can test that explanation without removing the feature from production prematurely. Record what changed in the comparison and what stayed constant. Otherwise an improvement may be attributed to the wrong intervention.

Ask what would disprove the diagnosis. If the predicted improvement does not appear, the supplier should return to the evidence and revise the explanation. This is normal investigation, provided the work is bounded and communicated. Avoid a sequence of paid fixes justified only by a fresh guess after the previous one failed to change the problem.

Keep related defects separate. A form can submit slowly because a remote service takes time, while its lack of a waiting message makes the delay confusing. Improving the feedback may help the experience without shortening the remote process. The report should describe both outcomes accurately so a communication improvement is not presented as proof of faster server processing.

For a hypothetical professional-services site, the initial complaint might be a late hero image. Investigation could find that the image file is reasonable but its request starts late. The scoped remedy would change discovery or prioritisation, followed by comparable checks. Replacing every image and changing hosting would be difficult to justify from that particular evidence alone.

Accept the diagnosis when the explanation, evidence and feasible next action align. Where uncertainty remains, agree a limited experiment or a further evidence requirement. Your buying decision should be informed by the cost of learning as well as the cost of implementing. A supplier who makes those boundaries clear is giving you a more usable basis for approval.

Improve images and media without losing useful detail

Images often help a buyer understand something words cannot explain as quickly. A product finish, installation detail or example of workmanship may justify its place on a page. The performance question is how to deliver that useful information efficiently. Removing meaningful photography simply because it adds weight can leave a lighter page that answers fewer of the customer’s questions.

Start with the role of each major asset. A hero image introduces the offer, a diagram explains a process, and a gallery supports inspection. Those roles can require different loading choices and levels of detail. Ask the designer and developer to agree what the visitor must see initially and what can reasonably wait until the person chooses to explore further.

Match the delivered asset to its use

An original camera file is a source asset, not automatically the right file to serve on a website. The published version should suit its display size and purpose. Ask how the site generates or selects appropriate variants and how an editor can verify the result. A documented process is more dependable than a one-off instruction to make every file smaller.

Inspect the actual image after compression. Fine labels, material textures and product edges can become unclear even when the file becomes much lighter. Set a visual acceptance standard with examples. A furniture buyer comparing finishes may need different detail from a visitor viewing a background photograph. File size by itself cannot decide whether the chosen version remains useful.

Check cropping at the intended layouts. A technically efficient image can lose its subject when placed in a narrow container. Important text embedded in a photograph is particularly vulnerable. Where information is essential, make it available as readable page content too. Keep visual review connected to the customer’s task, including the details they need before making an enquiry.

Ask whether the system serves an appropriate resource for the displayed image. A small thumbnail should not require the same delivery as a large detail view without a reason. The implementation can vary by platform, so avoid prescribing one technique before the developer assesses the site. The acceptance question is whether the chosen delivery suits the visible use and remains reliable.

Choose loading behaviour deliberately

MDN’s explanation of lazy loading describes delaying noncritical resources until they are needed. That can help content farther down a page. It is not a reason to defer everything. An image central to the initial view needs a loading strategy appropriate to its role, with evidence showing whether the change helps the measured experience.

Discuss image priority in relation to the page’s actual main content. A decorative asset should not unnecessarily compete with information the buyer needs first. A meaningful product image should not appear late because a broad optimisation setting treats all images alike. Ask the developer to inspect the specific template rather than applying one rule across unrelated page types.

Reserve suitable space for media so the page can maintain its layout while resources arrive. Review the result with different content shapes, including portrait photography and diagrams. A template that behaves well with one wide image may fail when an editor uses a different aspect ratio. The publishing guidance should explain the supported choices and their visible effects.

For galleries, distinguish the initial view from deliberate enlargement. A buyer may accept loading a detailed image after choosing to inspect it, provided the control is clear and the result arrives as expected. Keep an accessible route to the information. A clever image viewer that is difficult to operate can undermine the purpose of providing extra visual detail.

Treat video as a separate decision

A video can explain a complex product, but its player and delivery may introduce work before anybody presses play. Ask what loads initially and what begins only after the visitor chooses to watch. A preview image or clear play control can be appropriate, depending on the implementation. Confirm that captions and other required information remain available in the resulting experience.

Avoid forcing motion into a page simply to make it feel active. The buyer needs a reason to watch. A short demonstration of a mechanism may support the decision, while an unrelated looping background may add little. Decide the content’s purpose before discussing compression. Performance optimisation is easier when the business can distinguish useful explanation from a visual habit nobody owns.

Consider people who cannot or do not want to play the video. Provide a practical written explanation of the essential offer and next step. If the media is temporarily unavailable, the page should still communicate what the business provides. That resilience is a content decision as well as a technical one, and it belongs in the brief for media-heavy pages.

Check the surrounding page during playback and after closing the player. Controls should remain understandable, the next action should stay available, and the visitor should not lose information already entered elsewhere. Include any changed media behaviour in the acceptance cases. A successful play test alone does not establish that the rest of the customer journey still works.

Give editors a usable handover

Ask for a short publishing guide illustrated with the site’s own components. It should explain supported image shapes, how to prepare source material and how to check the published result. Include who can help when an unusual asset does not fit. A rigid size rule without examples often leads editors to guess, especially when a campaign deadline is close.

Keep original source assets in the business’s normal controlled storage, separate from the optimised public versions. Record where the originals belong and which output is used on the website. That avoids unnecessary quality loss when someone later needs a different crop. It also makes a supplier handover easier because the next designer can find the material behind the published file.

Build a small review into high-impact publishing changes. Replacing a hero image or adding a demonstration deserves a quick check of appearance, loading and the next action. Routine text edits need a proportionate process. The aim is to prevent known problems from returning while keeping everyday publishing practical for the people who maintain the website.

Make interactions responsive and layouts stable

A page can look complete while responding poorly to input. A menu may hesitate, a product selection may take time to update, or a button may appear to do nothing. These problems occur during use, so the investigation needs the actual interaction. A screenshot of a loaded page cannot establish how a form, calculator or booking control behaves when somebody operates it.

Describe the visible feedback you expect. After a visitor submits information, the page should make clear whether it is processing, needs a correction or has completed the request. Those are different states. A button changing colour may acknowledge a tap without explaining what happens next. Ask the designer to make the status understandable in the context of the task.

Investigate the work behind the response

Google’s INP optimisation guidance separates delays before handling an interaction, the work in its event handlers and the delay before the next frame appears. This gives the developer several possible causes to examine. Ask which part affects the reported control and how the proposed change will be tested through that interaction.

A slower device may expose work that is barely noticeable on a developer’s machine. The project should consider the audience and available evidence rather than assuming one powerful laptop represents everyone. Use the supported testing methods available and record their limitations. An unperformed device test is not a pass, but an unavailable testing control is not proof of a website defect either.

Consider what else is happening when the visitor acts. A page can be loading optional services or updating several components at once. The developer should examine the interaction in that context. An isolated demonstration of the button may miss the conditions under which it becomes sluggish. Include relevant timing and page state in the incident and acceptance records.

Ask whether work can be reduced, scheduled differently or moved away from the immediate response. The correct implementation depends on the platform. As a buyer, you need an explanation of the intended effect and the functions that might be affected. You should not have to choose a technical mechanism from a list of fashionable terms without a diagnosis.

Keep feedback truthful

A waiting state should tell the visitor that the request is underway, without implying success before it is confirmed. If the action fails, the person needs a practical next step. Avoid language that makes them repeat the whole process unnecessarily. A clear status can make an unavoidable wait easier to understand, while the underlying delay remains a separate improvement question.

The W3C guidance on form notifications covers informing people about success and errors, including accessible feedback. Use it when reviewing changes to submission behaviour. A message that appears visually but is not conveyed appropriately to assistive technology can leave some visitors uncertain about what happened. Include the affected notification in the functional review.

Check repeated actions. If a person presses submit again because nothing seems to happen, the page and receiving system should handle that possibility deliberately. Ask how duplicate requests are prevented or recognised within the agreed scope. Do not claim the problem is solved merely because a spinner appears; verify the actual result of the repeated interaction.

For a calculator, distinguish an estimated result from a confirmed quotation. The output should identify its meaning and any next step needed. A faster update should preserve the assumptions that make the result understandable. Performance work must not remove explanatory content simply because it takes space near the control or requires another component to display it.

Prevent movement that interrupts the task

Google’s CLS optimisation guidance identifies causes such as images without dimensions and dynamically inserted content. For a buyer, the practical concern is whether important controls or reading positions move unexpectedly. Ask the developer to show the affected sequence and explain how space or loading behaviour will change.

Review the page as content arrives, rather than only after everything settles. A booking area may look perfectly aligned in the final screenshot yet move while somebody tries to select a date. A late banner can push a form farther down the page. Capture the sequence when diagnosing that kind of issue so the acceptance check observes the same moment.

Check the places where content length changes. Error messages, optional product details and expanded answers can alter the layout. Some movement is expected when a person deliberately opens something. The design still needs to maintain orientation and keep the resulting content usable. Ask the supplier to distinguish expected expansion from an unexpected shift caused by unrelated loading.

Fonts can also affect the visible layout as text renders. Discuss the trade-off between brand typography, available fallback text and delivery. The solution should preserve readable content while avoiding unnecessary disruption. Review headings and controls with realistic lengths, because a short demonstration label may not expose the same wrapping and spacing problems as the actual page copy.

Review motion for its explanatory value

Use motion when it clarifies a sequence, a change of state or a relationship. A product mechanism may benefit from a brief demonstration; a decorative loop may not. Provide a suitable way to stop ongoing movement where needed and keep essential information available when motion is off. The static state should still communicate the concept rather than becoming an empty frame.

Test controls with the input methods relevant to their design, including keyboard use for accessible interactive elements. Check visible focus, the selected state and the resulting content. A performance change that makes a control respond sooner but harder to understand is incomplete. The acceptance decision should consider the response and the usability of what follows it.

Finish this part of the project with a small set of demonstrated tasks. Keep the observations connected to the original complaint: the menu responds, the selected options remain visible, the form explains its result. Those examples make the outcome understandable to the business and give future developers useful regression cases when the same components change again.

Review hosting and external tools as dependencies

A website’s behaviour depends on more than its own visible content. Hosting, content delivery, embedded services and third-party scripts can all affect the customer experience. Some are directly controlled by your team; others are governed by suppliers. Map those dependencies before agreeing a performance promise, particularly when a proposed fix requires a migration or changes how an essential service loads.

Create an inventory of the tools used on the affected routes. Record what each one does, where it loads, who owns it and what would happen if it were unavailable. Include booking, chat, video and measurement where relevant. The inventory should support decisions, not become a hunt to remove every external request regardless of the tool’s value.

Keep useful tools with clear ownership

Ask the business owner of each tool to confirm its current purpose. A script may remain from a campaign that ended long ago. Another may support a current sales process even if the website team rarely uses it. Establish that distinction before removing anything. An apparently unnecessary component can have a less visible dependency that needs a proper handover.

For each proposed removal or loading change, identify the expected benefit and the acceptance check. Delaying a chat service until a visitor chooses to open it may be appropriate in one setting. A time-sensitive support route may need a different approach. Keep the decision tied to the customer task and the operating requirements, with the service owner involved.

Review consent behaviour separately from performance. A tool should not be loaded outside its agreed privacy controls merely to improve a test result or simplify implementation. Equally, a faster page should not quietly stop collecting permitted information that the business relies on. Preserve the established choices and get the responsible privacy owner involved if a proposed change alters them.

Check the receiving system after an integration changes. A form can still display while delivering incomplete information. A booking tool can open while losing the selected service. Use approved test data and compare the expected record with the actual result. The test should follow the dependency affected by the optimisation rather than stopping at the visible widget.

Understand what caching can and cannot do

MDN’s HTTP caching guide explains how stored responses can be reused under defined rules. Caching can reduce repeated work, but its configuration must suit the content. Ask what is cached, for how long, and how updates become visible. Personalised or sensitive responses need handling appropriate to their nature.

A buyer does not need to choose individual cache headers. You do need to understand the publishing consequence. If an urgent price correction takes time to appear, somebody must know how the delivery system is refreshed. Include that operational question in a hosting proposal. A faster cached page is not helpful if the business cannot reliably update information that customers use to decide.

Distinguish first and repeat visits when reviewing evidence. A returning visitor may reuse resources that a new visitor has not yet received. Ask the supplier to cover the situations relevant to your audience. Do not let a warm-cache demonstration become the only evidence for a campaign primarily aimed at people visiting the site for the first time.

Document ownership of cache invalidation and release checks. An editor should know whether publishing content is enough or whether another step is required. Keep the procedure safe and specific to the platform. Broad instructions to clear everything whenever something looks wrong can disrupt useful caching and conceal the original cause of an update problem.

Assess a hosting change on the whole commitment

A hosting recommendation should identify the limitation it addresses and the evidence supporting it. Ask what changes besides server response, including support, backups, deployment and account ownership. A migration introduces work and risk even when the destination is suitable. Compare the complete arrangement rather than selecting a plan solely from a headline resource allowance or advertised speed claim.

Clarify which party handles domains, certificates and connected business services. The website move should have a documented boundary so unrelated email or systems are not changed accidentally. Retain access through appropriate business-owned accounts. Keep credentials out of general project documents and use the agreed secure access process for the people who need to perform the work.

GRO’s website hosting and maintenance service provides a relevant place to discuss continuing ownership and support. When buying either a one-off optimisation or ongoing hosting, ask who investigates a regression after launch. The answer should identify the work included and when a new estimate would be required.

Set a migration acceptance plan before changing production. It should cover the affected pages, important customer actions and the ability to recover deliberately if something fails. Preserve the previous revision and relevant configuration within the normal controlled process. Recovery should restore the intended service without overwriting unrelated changes made by another team during the same period.

Where an external provider remains the main constraint, record it plainly. Ask whether configuration, a different placement or an alternative route could improve the experience within the existing arrangement. A change of provider may be worth considering, but the decision should include customer functionality, data handling and operating effort alongside the observed performance limitation.

End the dependency review with named actions. One item may belong to your developer, another to the hosting company, and another to the business owner of a booking tool. Give each a clear question or change request. The value of the map is that it turns a general complaint about speed into work that the right person can actually carry out.

Compare optimisation proposals and total cost

Compare proposals against the same problem and expected evidence. One supplier may be pricing an audit, another a defined implementation, and another a monthly maintenance arrangement. Their fees cannot be judged fairly until the deliverables are understood. Ask each bidder to explain what you receive, what your team must provide and what remains outside the proposed commitment.

Use a brief based on the route inventory and available baseline. Include known constraints without prescribing an unverified solution. A supplier should have room to recommend a different approach if the evidence supports it. At the same time, the response must be concrete enough for you to see how its work addresses the customer problem you described.

Separate investigation from implementation

An audit should produce findings you can act on. Ask for affected pages, supporting evidence, likely causes, priorities and ownership. Clarify whether the supplier will implement any changes or only recommend them. A report full of automated warnings can leave the business with most of the decision-making work still to do, even when its page count looks substantial.

For implementation, request a list of the components and templates included. Ask how the supplier handles a discovery that changes the estimate. A reasonable process can allow additional investigation or a revised scope, but the business should approve material extra cost. An open-ended promise to optimise until the score improves provides little control over the eventual commitment.

Include validation in the price. The proposal should say which performance comparisons and functional checks will be supplied, and how remaining limitations will be recorded. If validation is left to a different supplier, establish that dependency before appointment. A repair without usable evidence can be difficult to accept, especially when the symptom was intermittent or the original report was ambiguous.

Ask whether ongoing monitoring includes remediation. A monthly report that identifies a regression is different from a service that fixes it. Both can be useful if clearly described. Confirm the alert recipient, response arrangements and any development allowance. Avoid assuming that a recurring fee includes every future performance issue simply because the service is called maintenance.

Calculate the cost of the same scope

Separate one-off work, recurring charges and your own required contributions. A quote may depend on a paid plugin, a hosting upgrade or time from your existing developer. List those dependencies alongside the supplier fee. Use actual written prices for your decision and check whether they include VAT where relevant; do not substitute an unsourced industry average for the engagement you need.

Consider this hypothetical comparison, using invented figures solely to show the method. Supplier A quotes £1,200 for assessment and fixes, plus £30 a month for a required tool. Supplier B quotes £1,500 with no recurring tool charge. Over twelve months those stated items total £1,560 and £1,500 respectively. The calculation says nothing about which supplier provides the better service.

The next question is whether the work is equivalent. If Supplier A covers three templates and Supplier B covers only one, the lower total may buy less. If one includes follow-up investigation and the other does not, that difference matters too. Add missing necessary work before comparing costs, then assess delivery quality and control separately from the arithmetic.

Include your team’s realistic availability. Someone may need to supply imagery, arrange access or test enquiry receipt. You do not have to invent a cash value for every task, but you should know whether the work can happen. A proposal dependent on unavailable internal help can become more expensive through delay even if the supplier’s fee stays unchanged.

Sense check quotes against published ranges

There is no independent survey of UK website speed optimisation prices. A few suppliers publish their own ranges, which are useful for spotting a quote far outside the norm but not as a fair price for your site. The figures below are each supplier’s 2026 estimate, not GRO prices, and exclude VAT unless the source says otherwise.

A quote well below these ranges may be an automated plugin setup with no validation. A quote well above them may include design or platform work that should be priced separately. Either can be reasonable once the scope is written down, which is why the comparison should start from the same list of pages and checks.

Examine claims and guarantees carefully

Ask what a claimed improvement refers to. A laboratory score, an individual loading measurement and an enquiry rate are different outcomes. A supplier should identify the page, period and conditions behind an example. Respect another client’s confidentiality; a redacted explanation can still show the reasoning and the work without exposing private business or customer information.

Google’s page experience guidance says good Core Web Vitals results do not guarantee top rankings. Treat a promise of search positions from speed work with care. Ask what the supplier actually controls and what evidence will demonstrate its contribution. A clear technical commitment is more useful than a broad commercial promise that cannot be isolated from other influences.

If a guarantee depends on disabling useful features, review that condition before agreeing. Removing a booking tool may make a test easier while making appointments harder to request. Any accepted trade-off should be explicit in the scope. The proposal should describe the customer experience you will receive, not only the conditions under which a particular number can be achieved.

Ask how the supplier treats work that does not produce the expected result. A credible answer explains diagnosis, communication and the boundary of further effort. It should distinguish a faulty implementation from a valid test that disproves an assumption. Agree that process in advance so a disappointing result leads to a reasoned decision rather than an argument over what was promised.

Check control and handover

Retain appropriate ownership of the website, source assets and accounts. Establish where code and documentation will live, who can deploy changes and how another supplier could continue the work. Access should match the agreed task. A performance project should not leave the business dependent on an undocumented personal account or unable to obtain the implementation it paid for.

Choose the proposal that gives you a convincing route from the observed problem to a maintainable improvement. Record any accepted limitations and unresolved conditions before the work starts. That decision record need not be elaborate. It should make clear why the scope fits, what evidence you expect and who has responsibility for the parts outside the chosen supplier’s control.

Release changes with a clear acceptance decision

A release plan connects the proposed fixes to a version that can be checked and delivered safely. It should identify what changes, which tests apply and who can authorise production. Keep that plan proportionate to the work. Correcting one image treatment needs less coordination than moving hosting and changing a booking integration, but both need a known version and a way to verify the result.

Use an isolated preview where the platform supports it. The preview lets the team examine the actual content and behaviour before customers receive the update. Confirm which production dependencies are represented and which are deliberately different. A preview that cannot send real bookings can still support useful checks, provided the missing delivery test is recognised and completed through an appropriate method.

Agree the acceptance pack before development ends

Ask for a concise record of implemented changes, comparable measurements and functional observations. Each item should connect back to the scope. If the supplier found additional issues, identify whether they were repaired, excluded or left for a separate decision. That makes acceptance a review of delivered work rather than a general impression that the website now seems quicker.

Use the same representative tasks from the baseline. Check the affected page, the control and the resulting action. For a media change, inspect visual detail and layout as well as loading. For an integration change, verify the relevant handover. The scope determines which tests matter; adding unrelated checks at the end can delay acceptance without increasing confidence in the actual work.

Document unavailable evidence honestly. A particular real device may not be available, or field coverage may be insufficient. Record what was checked and what remains uncertain. Decide the practical consequence according to the affected task and available alternatives. A missing testing tool should not be described as a defect, and an observation never made should not be recorded as successful.

Keep genuine failures distinct from those limitations. A form that loses a selected option is an observed problem and needs attention. A request to reproduce an obscure combination without evidence of an issue may be a lower-priority diagnostic. This distinction helps the team fix what is wrong while avoiding a process in which every untested possibility becomes an automatic reason to stop.

Make the deployment decision specific

Approve a particular revision, with its tested content and assets. If another person changes the same component afterwards, review the affected checks again. A previous pass belongs to the version tested. The team should be able to identify the revision going live and explain any difference from the preview reviewed by the business.

Choose timing around the people needed to verify the result. A small change may fit the ordinary deployment routine. A migration may need the hosting provider and sales contact available together. Do not schedule a major handover solely because the development work is finished. The ability to check and respond after release is part of the operational plan.

Preserve the prior production revision and relevant deployment record. Agree what would justify recovery and who can decide it. Restoration should be deliberate, especially if other changes have happened since the baseline. A broad rollback can undo unrelated work. The recovery plan should identify the affected change and the safest route to restoring the customer function.

If an unresolved issue is accepted, write down the reason and owner. The business may decide a constrained external tool is usable while a supplier investigates further. That is different from forgetting the issue. Record the intended follow-up and the circumstances that would trigger reconsideration, so a temporary acceptance does not silently become an indefinite operating condition.

Verify the delivered version

After deployment, open the actual production route. Confirm that the new assets and behaviour are present and that the expected links still work. A successful build proves a technical process completed; it does not by itself show that the intended version is serving customers. Check the public result before reporting that the repair is live.

Review the relevant enquiry path using the agreed test method. Confirm delivery where the release affected it, and distinguish test activity from ordinary reporting. If a consent or booking dependency behaves differently in production, investigate that difference before declaring the work complete. The test should follow the customer-facing outcome that the project was commissioned to protect.

Keep a short release note that customer-facing colleagues can understand. It should describe the affected task, when the change went live and what to report if the original symptom returns. Technical traces can remain with the development records. Sales and support need enough information to recognise a recurrence without learning the internal implementation.

Acceptance can include a later field review without withholding acknowledgement of completed technical work. State what has been demonstrated now and what will be assessed after sufficient visits. This gives the supplier a fair completion boundary and gives the business an honest account of the evidence. Neither party needs to pretend that an immediate test answers every longer-term question.

Judge the result without inventing a revenue uplift

The first question after release is whether the agreed technical problem improved. The next is whether the customer journey remains usable. A later commercial review can examine enquiries and sales in context. Keeping these questions separate makes the report more credible. It also prevents a valid performance repair from being judged against a sales promise that the project was never equipped to prove.

Start with the acceptance evidence and release date. Compare the same tasks and explain remaining constraints. Then review the relevant field information when coverage and timing make it useful. If a report includes visits from earlier versions, say so. The business should be able to tell whether it is looking at a direct test of the repair or a broader history of the website.

Use business measures with clear definitions

Choose an outcome the page can reasonably influence. A quotation page may support completed requests; a product detail page may support better-informed enquiries. Define how the outcome is recorded and what it excludes. A click on a contact button is not the same as a delivered enquiry, and a delivered enquiry is not the same as an accepted opportunity or a sale.

Check the measurement setup after changes that affect it. A sudden increase in reported events may reflect a duplicate trigger or a revised definition. Ask the analyst to confirm that the comparison uses consistent records. This is particularly relevant when performance work changes how an embedded tool loads, because the timing or availability of its events may change too.

Look at counts alongside rates. A large percentage movement based on very few enquiries can be unstable. Avoid presenting it as a dependable forecast. Where volume is limited, combine the available quantitative evidence with specific task observations and customer feedback. You can make a sensible operating decision without claiming a level of statistical certainty the data does not support.

Use the same reporting population where possible. If a new campaign brings a different audience to the page, its response can change independently of performance. Record the channel mix, offer and major business events that affect the period. An analyst should explain material differences rather than hiding them inside a single site-wide conversion rate.

Distinguish association from an effect

A before-and-after comparison can describe what happened around a release. On its own, it may not establish what caused the change. Advertising, demand, pricing and sales response can all move during the same period. Phrase the conclusion to match the design: the website changed and outcomes moved, with the stated limits on attribution.

Where the business has sufficient traffic and suitable technical support, a controlled experiment may help answer a specific commercial question. Agree the hypothesis, relevant outcome and operating constraints before running it. Some infrastructure changes are awkward to isolate, and a small sample may remain inconclusive. The decision to experiment should follow the question and available evidence, not a requirement to produce a positive result.

GRO’s marketing attribution guide discusses the difference between assigning credit and proving an effect. Apply that distinction here. A customer who used the improved page may also have spoken to sales, read another article and returned through a branded search. The page can be part of the journey without its speed change receiving all the credit.

Avoid importing another company’s uplift into your forecast. A published case study describes its own starting point, audience and intervention. It may illustrate a possibility but cannot tell you how much your business will gain. Ask a supplier to explain the practical relevance of an example rather than multiplying your current revenue by a percentage drawn from an unrelated site.

Report decisions rather than a victory narrative

A useful review can conclude that the technical repair worked while commercial evidence remains uncertain. It can also conclude that the measured delay improved but a different obstacle now deserves attention. Those are actionable findings. The report should not need a dramatic sales claim to justify a properly scoped piece of work.

If enquiries fall after release, check whether the change introduced a functional problem before debating marketing performance. Confirm the actual route, delivery and measurement. If those are sound, examine wider conditions. The sequence matters because an immediate defect needs a different response from a shift in demand or a small fluctuation in a low-volume period.

For a hypothetical training provider, the repaired course selector may respond promptly and preserve the chosen location. That demonstrates the agreed functional outcome. A later increase in course enquiries would still need context about the new term, campaign activity and available dates. Report the proven repair clearly while leaving the wider commercial interpretation open to the evidence.

End each review with one next decision: maintain the current approach, investigate a remaining issue or commission a defined further change. Give that decision an owner and an evidence requirement. This keeps performance reporting connected to the business’s actual priorities and avoids an endless pursuit of marginal score improvements whose customer value has never been established.

Keep the gains through everyday publishing

Performance can change as a website evolves. New photography, a different template or an extra integration may reintroduce work that an earlier project removed. Treat maintenance as an operating responsibility with clear boundaries. The handover should make ordinary publishing easier to do well and make unusual changes easy to recognise as needing a closer review.

Begin with the specific causes repaired. If large source images were being uploaded directly, give editors a workable preparation process. If a script loaded on pages where it served no purpose, record where it belongs. Generic advice to keep the website fast is less useful than guidance tied to the decisions people actually make when changing content.

Set rules around components and responsibilities

Give each important component an owner. That person need not perform every technical task, but should know its purpose and who can change it. A booking embed can belong to the sales process owner, while an image template belongs to the website team. Clear ownership prevents tools accumulating because nobody knows whether they are still required.

Document acceptable content patterns using real examples. Show a suitable hero crop, a readable diagram and the expected behaviour of an embedded demonstration. Explain how to request an exception when a campaign needs something different. A practical exception route is better than a rigid rule that people bypass because it cannot accommodate legitimate business needs.

Consider a performance budget for frequently changed templates. This is a locally agreed boundary for aspects such as resource weight or tested behaviour, chosen from the actual design and audience. It is not a universal number borrowed from another website. Ask the developer to explain what is measured, why the boundary is useful and what happens when a proposed change exceeds it.

Keep the budget connected to quality. An unusually detailed image may be justified on a specialist product page, while the same delivery would be wasteful for a small thumbnail. The review should examine that purpose. A limit that ignores the buyer’s information needs can encourage technically compliant pages that are less useful to the people reading them.

Choose monitoring that leads to action

Decide which routes deserve routine checks and how often the business can respond. A campaign destination receiving active spend may need closer attention than an unchanged archive. Use the established deployment checks for changes likely to affect performance. Avoid collecting a large dashboard of warnings when nobody is responsible for deciding which ones matter.

Specify the alert recipient and the first investigation step. A notification should include the affected page, observed change and relevant comparison. The recipient should know whether to contact the developer, inspect a recent publication or check an external service. Without that operational detail, repeated alerts can become background noise while a customer problem remains unresolved.

Record releases and significant content changes alongside the monitoring history. A new video, a campaign launch or a platform update may explain when a regression began. This does not prove causation, but it gives the investigator a useful starting point. Keep dates and versions accurate enough that the team can compare the relevant state before and after the change.

Review persistent warnings rather than accepting them indefinitely. Some may represent a known supplier constraint; others may no longer apply to the current scope. Give each an owner and a reason for its status. Closing irrelevant warnings makes the remaining issues easier to understand, while quietly ignoring everything because some alerts are noisy leaves the business without a dependable review process.

Maintain a workable supplier boundary

Confirm which changes your maintenance agreement covers. Updating content, reviewing performance and rebuilding a component are different kinds of work. Ask how urgent incidents are handled and when a new estimate is needed. The agreement should reflect the website’s real dependencies so a problem does not get passed between suppliers who each assumed the other was responsible.

Keep account access current through the business’s normal process. Staff and supplier changes should not leave monitoring attached to an abandoned personal account. Check that authorised internal owners can find the reports, source assets and deployment records. Continuity depends on those practical details as much as it depends on the original quality of the optimisation work.

Schedule a review when the website’s purpose changes materially. A new product configurator, language version or customer portal may alter the performance requirements. Treat that as a new scope decision rather than assuming the old acceptance pack covers it. The previous evidence remains useful history, but it does not automatically validate components that did not exist when the tests were performed.

Give customer-facing teams a simple way to report recurring symptoms. Ask for the page, action and visible result, with appropriate care around personal information. Feed credible reports into the same investigation process used during the project. A maintained website combines measurements with what people experience; it does not require customers to supply a technical diagnosis before their difficulty is taken seriously.

Questions UK buyers ask about website speed

Do we need a new website to improve its speed?

A rebuild is not automatically necessary. A focused assessment may identify a problem in image delivery, a shared component or an unnecessary script that can be addressed within the current site. Ask the supplier to explain the observed cause and the realistic options before comparing a repair with a replacement.

A rebuild becomes relevant when the existing architecture or platform materially limits useful improvements, or when wider business needs justify it. Compare the full cost, disruption and expected capabilities of both options. Keep the decision grounded in your actual website, including the customer functions and content that must survive the work.

Should we insist on a perfect PageSpeed score?

Set acceptance around the customer problem and comparable evidence. A perfect laboratory score is not a guarantee that every interaction works well or that the website will generate more enquiries. Ask which measurements describe the affected experience and how the supplier will demonstrate the result.

Useful features can have a performance cost. Removing them simply to improve a number may make the page less helpful. Agree any trade-off explicitly, preserve the important customer tasks and record remaining constraints. The goal is a better working experience supported by evidence, with a score interpreted as one part of that assessment.

How much does website speed optimisation cost in the UK?

The appropriate price depends on diagnosis, affected templates, access and implementation complexity. Request written quotes for the same scope, with assessment, fixes and validation identified separately. Include required tools, hosting changes and work that another supplier must perform. Check the actual payment and tax basis of each proposal.

Avoid choosing from an unsourced average or the lowest visible fee alone. One quote may cover an audit while another includes implementation and continuing support. Ask what evidence you receive at completion and what happens if the investigation changes the proposed work. Compare equivalent commitments before deciding which arrangement offers suitable value.

Why has the field report not changed after a repair?

A field report can include historical visits from before the change. PageSpeed Insights uses a trailing collection period, so an immediate controlled test and the field view may describe different experiences. Check the release date, report scope and whether the information is for the individual URL or the wider origin. In Search Console, open the Core Web Vitals report and use Validate fix once the change is live: Google then monitors the affected URLs for 28 days and marks the issue fixed only if none of them still shows it.

Do not assume the delay proves success or failure. Confirm that the intended version is live and repeat the relevant controlled checks. Then review field information when its period and coverage make the comparison useful. Keep any missing data visible, and investigate a continuing customer problem rather than waiting for a headline assessment to change.

Can we keep our booking tool, video and tracking?

Often the useful functions can remain, with their delivery reviewed against the customer journey. Ask what each tool does, where it is needed and which supplier controls its behaviour. A different loading approach or placement may help, but the correct choice depends on the actual implementation and operating requirements.

Check the affected functions after any change. Booking confirmation, enquiry delivery and permitted measurement should still behave as agreed, with existing privacy choices preserved. If a necessary provider remains a constraint, record it and assess the options honestly. Do not accept removal of an essential customer function as an undisclosed condition of a performance promise.

Does website speed affect SEO?

It can contribute, but it is rarely decisive on its own. Google’s Core Web Vitals documentation recommends that site owners achieve good results for success with Search, while its page experience guidance is clear that good results do not guarantee top rankings. Relevant, helpful content still matters more.

The stronger commercial case is usually what happens after the click. A visitor who waits for an offer or taps a form without a response may leave, whatever brought them to the page. Treat speed as part of the enquiry journey and measure enquiries alongside rankings.

Why is my website so slow?

The most common causes are oversized images, slow or overloaded hosting, too many plugins or third party tags, and code that must load before anything appears. On content managed sites, a heavy theme or page builder can add work to every page. A slow site is often the result of several small additions rather than one fault.

Run the important page through PageSpeed Insights and note which metric fails in the field data. That tells you whether to look first at loading, responsiveness or layout movement, and gives a supplier a specific starting point.

How long does website speed optimisation take?

An audit of a few important templates usually takes days rather than weeks. Implementation depends on the causes: image and caching changes can be quick, while reworking scripts, a theme or a hosting move takes longer and needs more testing. Ask for a schedule that includes regression checks, not only the development time.

Then allow about four weeks for field evidence. Search Console validation runs for 28 days and real user data replaces older visits gradually, so a fair before and after comparison of field results comes a month after release.

Bring a specific page to the next conversation

Choose one important customer task and gather the evidence you already have. Bring the page address, the observed difficulty and the systems involved. A useful proposal should explain the likely investigation, the work it covers and the checks that will show whether the result is acceptable.

GRO can connect performance work with the page’s offer, enquiry route and continuing maintenance. Book a strategy call to discuss a focused starting point. Keep known facts separate from assumptions, and ask who owns any external dependency. The next step should be a defined assessment or repair that your team can support, with a clear completion boundary and an honest account of what the available evidence can show.