Your Site Is Slow: How to Have the Right Conversation With Your Developer

Your developer just told you the site is slow and needs work. Or worse, your customers are complaining about speed but your developer says everything is fine.

You’re not technical. You don’t know what “Time to First Byte” means. You’re not sure if “optimising images” is a real thing or something developers say when they want more budget.

This puts you in an impossible position: you need to make decisions about performance work, but you don’t speak the language.

Here’s how to have productive conversations about site performance without learning to code.

What Your Developer Means When They Say “The Site Is Slow”

Developers use “slow” to mean different things. Here’s the translation:

“The server response time is slow”

Translation: When someone visits your site, your server takes too long to start sending information back to their browser.

What this feels like to customers: The page sits blank/white for several seconds before anything appears.

Business impact: People leave before seeing anything. Google penalizes you in search rankings.

Typical causes: Database problems, inefficient code, cheap hosting, or traffic spikes your server can’t handle.

“The page load time is slow”

Translation: After the server responds, it takes a long time for everything to download and display.

What this feels like to customers: They see some content quickly, but images/features take forever to appear, or the page keeps shifting around as things load.

Business impact: Frustrating experience. Mobile users on data plans burn through their data allowance. People abandon before the page finishes.

Typical causes: Huge images, too many third-party scripts (tracking, ads, analytics), bloated code.

“The site feels sluggish”

Translation: Once the page loads, clicking buttons or interacting with features is slow or unresponsive.

What this feels like to customers: They click something and nothing happens for a second or two. Forms feel laggy. Animations are janky.

Business impact: Makes your site feel broken or low-quality. Particularly bad on mobile.

Typical causes: Too much JavaScript, poorly written interactive features, browser trying to do too much at once.

The Questions You Should Be Asking

When your developer brings up performance, don’t just nod and approve the work. Ask these specific questions:

“What specifically is slow, and how do you know?”

Good developers measure performance. They should be able to show you:

• PageSpeed Insights scores (Google’s free tool)
• Real user monitoring data from your actual customers
• Comparison to your competitors
• Which pages are worst

If they say “it just feels slow” or “customers are complaining” without data, they’re guessing. Get actual measurements first.

What good answers sound like:

• “Our mobile PageSpeed score is 35, which is in the bottom 20% of sites. Our competitors average 60-75.”
• “Real user data shows our homepage takes 6.2 seconds to become interactive on mobile. Industry standard is under 3 seconds.”
• “Our product pages have a 45% bounce rate, which correlates with their 5-second load time.”

Red flags:

• Can’t show you specific numbers
• Just says “it’s slow” without measurements
• Only tested on their fast office internet
• Hasn’t compared to industry benchmarks

“What’s causing this, in business terms?”

Developers love talking about technical details. Push them to translate to business impact.

Don’t accept: “The DOM is bloated and JavaScript is render-blocking.”

Push for: “We’re loading 15 different tracking scripts, and they’re preventing the page from displaying until they all finish downloading. Removing unnecessary ones would improve load time by 2-3 seconds.”

What you’re listening for:

• Can they explain the cause without jargon?
• Do they connect the technical cause to user experience?
• Have they prioritised by business impact (not just technical complexity)?

“What will fixing this cost, and what will it gain us?”

Performance work costs money. Make sure you understand the trade-off.

Questions to ask:

• How many hours will this take?
• What’s the expected improvement? (In seconds, not percentages)
• How will this impact conversions/sales?
• What’s the risk if we don’t do this?

Example of good vs. bad answers:

Bad: “We need to optimise. It’ll take a few weeks.”

Good: “We need 40 hours ($6,000) to compress all images and implement lazy loading. This should reduce page load from 4 seconds to 2.5 seconds on mobile. Based on industry data, that could improve mobile conversions by 10-15%. At your current traffic, that’s potentially $2,000-3,000 additional monthly revenue.”

“What are we comparing to? What’s ‘good enough’?”

Perfect performance is impossible and unnecessarily expensive. You need to know what good-enough looks like.

Ask your developer:

• What’s the industry benchmark for our type of site?
• What do our main competitors score?
• What’s the minimum acceptable performance?
• At what point are we getting diminishing returns?

Realistic targets:

• Mobile PageSpeed score: 50+ acceptable, 70+ good, 90+ excellent (very expensive)
• Load time: Under 3 seconds on mobile is acceptable, under 2 seconds is good
• Desktop: Usually 20-30 points higher than mobile

Don’t pay to go from a score of 75 to 95. The improvement from 40 to 70 delivers far more business value.

“Is this a one-time fix or ongoing maintenance?”

Some performance work is a one-time project. Some requires ongoing vigilance.

One-time improvements:

• Compressing existing images
• Removing unused code
• Upgrading hosting
• Switching to a faster theme/platform

Ongoing requirements:

• Compressing new images as you add them
• Monitoring performance monthly
• Vetting new features/plugins before installing
• Regular code audits

Make sure you budget for both. A one-time optimisation that degrades over time because you’re not maintaining it is wasted money.

The Conversation Framework

Here’s how to structure a productive performance conversation:

1. Start with business goals, not technical details

Don’t say: “The developer says we need to optimise.”

Do say: “Our mobile conversion rate is 40% lower than desktop. I want to understand if site performance is contributing to that gap.”

2. Request data before approving work

Don’t say: “Ok, go ahead and make it faster.”

Do say: “Can you run PageSpeed Insights on our top 5 pages and compare them to [competitor 1] and [competitor 2]? I’d like to see the specific numbers and where we’re falling short.” The same principle applies any time you’re reporting a problem, not just requesting an audit — see a bug report template that saves you money.

3. Ask for the business case

Don’t say: “How long will this take?”

Do say: “Walk me through the expected cost, the improvement in seconds, and the estimated impact on conversions. How confident are you in these estimates?”

4. Set clear priorities

Don’t say: “Make everything fast.”

Do say: “Our checkout page is most critical for revenue. Let’s optimise that first, measure the impact, then decide if we need to do more.”

5. Establish ongoing monitoring

Don’t say: “Let me know if it gets slow again.”

Do say: “After this work is complete, I want monthly performance reports showing our scores and any degradation. What tool will we use for this?”

Red Flags That Your Developer Doesn’t Actually Know

Not all developers are performance experts. Watch for these warning signs:

They can’t explain without jargon

If they can’t translate technical concepts into business language, they might not fully understand the problem themselves. Good developers can explain complex things simply.

They propose rebuilding instead of optimising

Major red flag. Performance problems are rarely solved by rebuilding from scratch. Usually, targeted optimisations fix 80% of issues for 20% of the cost. If rebuild is the first suggestion, get a second opinion.

They have no specific measurements

“It feels slow” or “customers complain” isn’t enough. Performance must be measured objectively. If they’re not using tools like PageSpeed Insights, Chrome DevTools, or real user monitoring, they’re working blind.

They can’t prioritise

If everything is equally urgent and equally important, they don’t understand the business impact. Good developers prioritise fixes by: (1) business impact, (2) effort required, (3) risk of not doing it.

They promise specific conversion rate improvements

No one can guarantee that a 2-second improvement will increase conversions by exactly 15%. They can share industry data and reasonable estimates, but anyone promising specific conversion improvements is overselling.

They want to optimise before measuring

Optimising without measurement is guesswork. Always measure first, optimise second, measure again to confirm improvement.

Common Performance Scenarios and How to Handle Them

Scenario 1: Developer says site needs optimisation, but you see no customer complaints

What to ask:

• “Show me our current performance metrics compared to industry benchmarks”
• “Show me our bounce rate and conversion rate trends over the past 6 months”
• “What specifically is underperforming, and by how much?”

Possible outcomes:

• They’re right: Data shows problems you hadn’t noticed. Good developers catch issues before customers complain loudly.
• They’re being proactive: Performance is acceptable but could be better. Decide if the ROI justifies the investment.
• They’re creating work: No data supports the claim. Table the conversation until you have actual evidence of a problem.

Scenario 2: Customers complaining about speed, but developer says everything is fine

What to ask:

• “Let’s run PageSpeed Insights together right now on the pages customers are complaining about”
• “Can we look at real user monitoring data, not just your tests on fast internet?”
• “What’s our current bounce rate? How does that compare to when we weren’t getting complaints?”

Possible outcomes:

• Developer is testing on fast connections: They need to test on mobile/slow connections like customers use.
• Developer is measuring wrong things: They’re checking server response but ignoring total page load time.
• Customers are complaining about something else: “Slow” might mean confusing navigation, not actual load time.

Scenario 3: You want performance improvements, but developer says platform limits them

What to ask:

• “What’s the performance ceiling for our current platform?”
• “What would moving to a different solution cost vs. the ongoing frustration of hitting this ceiling?”
• “Can you show me competitors on the same platform who perform better? What are they doing differently?”

Possible outcomes:

• Platform is actually limiting: Shopify, WordPress, or other platforms have real ceilings. Question becomes whether the ceiling is acceptable for your business.
• Developer doesn’t know how to optimise: Other sites on the same platform perform better. You might need different expertise.
• Platform choice was wrong initially: If you’re fundamentally limited, you need a migration plan.

Scenario 4: Agency/developer wants ongoing optimisation retainer

What to ask:

• “What specifically will you monitor and optimise monthly?”
• “What happens if we do this once and then stop? Will performance degrade?”
• “Can you show me examples of gradual performance degradation on sites you don’t actively maintain?”

Possible outcomes:

• Legitimate need: Sites do degrade over time as new content/features are added. Monthly monitoring and tuning prevents this.
• Unnecessary recurring revenue: If they do proper one-time optimisation and you’re disciplined about new additions, monthly retainers might be overkill.
• Middle ground: Quarterly check-ins rather than monthly, unless you’re actively developing new features constantly.

The Tools You Can Use Yourself

You don’t need to be technical to check basic performance. Here are tools anyone can use:

Google PageSpeed Insights (https://pagespeed.web.dev)

• Free, requires no login
• Test any URL
• Shows scores for mobile and desktop (0-100)
• Green = good (90-100), Orange = needs improvement (50-89), Red = poor (0-49)
• Focus on the mobile score – most traffic is mobile

How to interpret results:

• Look at the score (ignore all the technical details unless you’re curious)
• Check “Opportunities” section – shows what could be improved
• Note the load time in seconds
• Compare to your main competitors’ sites

GTmetrix (https://gtmetrix.com)

• Free tier available
• More detailed than PageSpeed Insights
• Shows you what’s loading and how long each thing takes
• Can test from different locations globally

How to use it:

• Run your homepage and key landing pages
• Look at “Fully Loaded Time” (that’s the number that matters)
• Check “Page Details” to see total page size (over 3MB is heavy)
• Review “Waterfall” to see what takes longest to load (you don’t need to understand it, but your developer should)

WebPageTest (https://www.webpagetest.org)

• Free, no login needed
• Can simulate slow connections (3G, 4G)
• Shows filmstrip of how page loads over time
• Most comprehensive, but complex

How to use it:

• Choose “Mobile” and a slow connection
• Run test on your key pages
• Look at “Speed Index” (lower is better, under 3 seconds is good)
• Watch the filmstrip – this is what your customers see

What Good Performance Work Looks Like

So your developer does the optimisation work. How do you know if it actually worked?

Before starting:

• You have baseline measurements (PageSpeed scores, load times)
• You have a written scope of work with expected improvements
• You’ve agreed on how success will be measured
• You have a budget and timeline

During the work:

• Regular updates (at least weekly for multi-week projects)
• You can test a staging/development version before it goes live
• They explain what they changed in business terms
• They identify any trade-offs (e.g., “Removing this animation improved load time by 0.5 seconds, but the page looks slightly less polished”)

After completion:

• They show before/after measurements
• Improvements match (or are close to) estimates
• You can verify improvements yourself using PageSpeed Insights
• They provide a report of what was done
• They give recommendations for maintaining performance going forward

When to Get a Second Opinion

Consider getting another developer’s assessment if:

Your current developer can’t explain the problem

If they can only describe the issue in jargon or their explanations don’t make sense, they might not fully understand it.

The proposed solution seems extreme

If their first suggestion is “rebuild the site” or costs $50K+ for a simple site, get another opinion. Most performance issues have cheaper, incremental solutions.

The timeline keeps extending

If a “two week” optimisation is now in month three with no end in sight, something is wrong. Either the scope wasn’t understood, or they don’t know what they’re doing.

Results don’t match promises

If they promised a 3-second improvement and you got 0.5 seconds, either their estimate was wrong or they don’t know how to optimise effectively.

They’re defensive about questions

Good developers welcome questions and explain their thinking. If they’re dismissive or annoyed when you ask for clarification, that’s a communication problem at minimum.

The Bottom Line

You don’t need to understand code to have productive conversations about site performance. You need to:

Ask for data, not opinions: “Show me the PageSpeed scores” beats “it feels slow.”

Request business translations: “What will this cost and what will we gain?” not “how many milliseconds will we save?”

Set clear priorities: “Optimise checkout first, then we’ll decide about the blog” not “make everything fast.”

Verify independently: Run PageSpeed Insights yourself. You don’t need your developer’s permission to check performance.

Question unclear answers: If you don’t understand their explanation, that’s their communication problem, not your technical knowledge problem.

Good developers can explain performance in business terms. They provide measurements, clear scopes of work, realistic estimates, and verifiable results. If your developer can’t do these things, you either need a different developer or they need to change how they communicate.

Performance isn’t magic. It’s measurable, it’s fixable, and it’s worth the investment when done properly. But it requires clear communication between business and technical people.

Your job isn’t to understand the technical details. Your job is to ensure the work has clear business justification, reasonable cost, and measurable results.

These conversations might feel uncomfortable at first. But asking clear questions and expecting clear answers isn’t technical, it’s just good management.