If your website feels slow, start by recording what happens and where. Does the main image take a long time to appear? Does the menu respond slowly on a phone? Does the page jump while you are trying to read it? These observations help your web designer investigate the right problem.
This guide gives Wexford businesses a practical way to prepare a speed review, understand Google’s reports and agree what to check afterwards. A test score alone does not establish the cause, the work required or a likely business result.
Jump to: Record the problem · Read the reports · Core Web Vitals · Possible causes · Agree priorities · Check changes · Review worksheet · Scope and care plans
Choose the pages customers need most: your main service page, a project gallery, a contact form or, where relevant, a product page and checkout. Record the exact page address, device, browser, connection and what you were doing.
Compare more than one page and, where possible, another device or connection. Note whether you were signed in or browsing as a customer. If the problem started after a new gallery, video, plugin or website change, include the date. This is evidence to investigate, rather than proof that the last change caused the delay.
Google PageSpeed Insights reports on mobile and desktop performance. Its lab results come from a simulated Lighthouse test; its field data describes real visitor experiences from the Chrome User Experience Report. These answer different questions, so they need not match.
Real visitor data uses a rolling 28-day period. A page may not have enough samples, in which case the report may show data for the wider website, or no real visitor data. Missing data is not a pass or a fail. Check which level the report describes before drawing conclusions. See Google’s explanation of PageSpeed Insights.
Save the report link and date alongside your observations. Treat the findings as a starting point for investigation, rather than a shopping list of changes to apply without checking their purpose.
Google’s Core Web Vitals describe three parts of the visitor experience:
A page can load its main content promptly but still respond poorly to a menu tap. Record the symptom as well as the metric. Google’s Core Web Vitals guidance explains these measures; they are not interchangeable with one overall performance score.
Ask whether photographs are being delivered at suitable dimensions and file sizes for the layout and device. Keep the original files, and check that any resized or compressed versions remain clear. Google’s image performance guidance explains responsive images and reducing unnecessary downloads. Our website content checklist can help you organise approved photographs.
Review large videos and how they load. Ask whether the video needs to download immediately or whether another presentation would suit its purpose. Google’s video performance guidance covers delivery choices. Keep useful content and accessibility requirements in the decision.
Chat tools, video players, analytics and other external scripts can add work and network requests. List what each feature does before deciding whether to change it. See Google’s third-party JavaScript guidance. For WordPress, ask your developer which plugins contribute to the affected page; plugin count alone does not identify the cause.
Time to First Byte describes the wait for the first byte of a response. It is not itself a Core Web Vital, but a long wait can delay what follows. Google’s server response guidance explains how to investigate it. Ask your developer or host to review the evidence before recommending a hosting move.
Use our website hosting guide to clarify access, support, backups and email arrangements. A different plan should not be presented as a guaranteed fix without diagnosing the problem.
Ask for a short list showing the affected pages, evidence, proposed changes, cost and how each change will be checked. Agree a backup and recovery route, and use a test copy where appropriate. Changes to scripts, caching or plugins should preserve required features, consent behaviour and security.
Our Technical SEO Wexford service starts with investigation and agreed priorities. If a wider rebuild is being considered, use the website redesign guide to separate speed work from content, design and page-address changes.
Compare the same pages under similar conditions and record what changed. Test the customer journey on desktop and mobile: menus, image galleries, forms and, where present, basket and checkout. A better report is not enough if an enquiry form has stopped working.
Because real visitor data covers a rolling period, it will not instantly represent only the updated version. Keep the change date with your reports and review the visitor experience alongside the tests.
Google says good Core Web Vitals do not guarantee top rankings, and pursuing a perfect score solely for SEO may not be a useful priority. See its page experience guidance. Agree realistic checks for usability; do not assume a particular speed improvement will produce a stated increase in rankings, enquiries or sales.
Prepare these details before asking for a review:
Agree whether a performance investigation, implementation and follow-up reporting are included in the quotation. Use our website maintenance responsibilities checklist to record who handles technical work, content and approvals.
Our technical maintenance is billed yearly. Content work and ongoing SEO are quoted separately, with hosting identified separately in the quotation. See our Website Maintenance & Care Plans for the website care service.
To discuss a slow website, contact Istech Web Design with the page addresses, symptoms and any reports you have saved. We can agree what needs investigating before recommending changes.
