Site is slow and losing leads: what to check before a redesign

Someone is already waiting on the site you have. A form sits half finished. Search keeps spinning. A manager starts an export and switches to something else. The same month, the inbox is quieter, and a proposal lands: new layout, new pages, maybe a new platform. The money in that proposal goes to what people see. The wait is often one database operation, one oversized response, or one missing index. A lead does not die because the typeface is old. It dies when the step that creates it never finishes.

Do this pass before you pay for the redesign. Name the screen, time the click, and only then decide whether the page should change. A slow page and fewer enquiries can both be true. They are not automatically the same cause. Any number below belongs to one operation on one product. It is not a promise that your site will move by the same amount.

1. Name the wait people already feel

In the meeting it comes out as one sentence: the site is slow, and we are losing leads. That sentence is too big to act on. You cannot fix a wait you have not named, and you cannot blame a page nobody has timed.

"Slow" is a shared feeling. It does not point at a screen, an export, or a job. The homepage can feel fine while the page that creates the lead is the one that stalls: search, a booking form, checkout, or the list a salesperson refreshes all day. A redesign then freshens the page people already tolerate, and leaves the step they abandon.

Write it down before anyone opens a design file:

• The exact screen where someone waits, and who waits: a visitor, a manager, or a partner.
• One timing, taken before any change. Day, click, seconds.
• A line that separates "this page is slow" from "we want a new look". Both can be true. They are not the same task.
• The step that actually creates the lead: the form submit, the call, the booking. Time that step, not the page above it.
• Whether the quieter inbox started before the slowness, after it, or nobody knows. Do not invent a percentage.

Keep the note that narrow. On one training platform, "the platform is slow" was never a useful description. A loop of database queries became one aggregating query. That operation went from 12.41 seconds to 2.451 seconds, and memory use fell by 1.5 GB. A separate critical operation went from 23,937 ms to 48 ms. One API response went from 912 KB to 2.1 KB. Weekly average CPU load went from 82.2% to 2.75% after the bottlenecks, including missing search indexes, were addressed. Each figure describes that operation. None of them means the whole product became a fixed number of times faster. Your note should look the same: this screen, this click, this many seconds, before anyone discusses a new look.

2. Why the wait is usually one operation

A new theme does not remove a query that runs once per row. A new logo does not add the index a search is missing. People see the page paint, so the project gets framed as design. The seconds were often spent earlier, on the server, before the browser drew anything.

The time sits in a familiar place: a query inside a loop, a search column without an index, or a response that sends a whole record when the screen needs a few fields. On that same training platform, the cut from 912 KB to 2.1 KB was one API response. The screen did not need the rest. A redesign of that screen would still have shipped the same payload if nobody had asked what the response contained.

There is a second pattern. A report, an export, or a call to a partner service holds the request open. Moving that wait into a background job is a different change from a visual redesign. A second runtime is not the first question. Name the operation first. The boundary is covered in when a Node queue belongs beside Laravel.

Ask these before you accept a cause:

• Is the slow step a query, a large response, or a wait on an outside service? The slow log, or the person who runs the server, can start that answer.
• If the same table is read once per line on the screen, write "query in a loop" in one sentence.
• If search is the slow step, ask whether that column has an index. Missing search indexes are a common reason a lookup feels broken.
• If the response is large, compare its size with what the screen shows.

On another product, a frozen screen was cleared and a critical process went from about an hour to about six minutes. That result belongs to that process. It is not a multiplier you can paste onto a redesign quote. Keep every number next to the operation that produced it.

3. What to check before you commission a redesign

Pictures in a proposal are easy to approve. That is why the contract gets signed while the current site still has no measurement and no second environment. Afterwards you cannot tell whether the new site is faster, and you cannot try a smaller fix without touching the live site.

A site that looks dated is sometimes the production system that still takes the orders. The useful first move is to see what is running and steady it. A new product, chosen because the old one feels old, can wait.

Walk through this before you sign:

• Time the lead step and one internal step staff already complain about, such as an export or a report. Keep both numbers.
• List the framework, the language runtime and the database. You are checking whether the current system can still be patched, not shopping for a new stack.
• Find out whether a separate environment exists. A fix you can only try on the live site makes a redesign and a performance patch the same risky release.
• Confirm the last successful restore, or restore a backup once in that separate environment.
• If another developer handed you the site, confirm repository access, the deployed branch and a written setup before design work. That pass is the Laravel handover checklist.

Do not refresh every package because a newer release exists, and do not copy a stack from a portfolio because it looks serious. Ask whether this operation can get faster without a new product.

4. What a redesign does not fix

A new front end on the same slow operation still waits. After launch, the lead step takes as long as before, and people call it a failed design. The design did what it was asked. It was not asked to change the operation.

Design scope is pages, type and components. The slow path is data access. If a customer search joins large tables without an index, the new search box calls the same path. If an export builds a file inside the request, the new button waits the same way. The people who approved the pictures had no line in the brief that said "this search returns in the time we measured, or better".

Put the constraint in writing:

• The timed operations go into the redesign brief, with the seconds you wrote down.
• Keep the old numbers. The honest comparison is the same screen, the same kind of data, before and after.
• If the redesign also changes the database or the hosting, treat that as a second project with its own check.
• If customers share one application, write down how one account's data stays separate before new pages show more of it.

A faster page that shows another customer's records is not an improvement. On one multi-tenant product, each branch had its own database, and the migrations and indexes were built around that split. Your product may differ. Before a redesign shows more of the same data, write down whether one account can read another's records.

5. Turn the notes into a short plan

A document that ends with "consider a redesign" and names nobody is not a plan. Split the notes. Immediate: the lead step, if it fails or times out, and any restore you have not proved. Next: the operation you timed, with a suspected cause — a loop, an index, a payload, or work that belongs in a queue. Later: the visual change that is still worth doing once the wait is understood.

Give the list owners:

• Each line has a person and a check that shows it is done: a repeated timing, a restored backup, a search that uses an index.
• Agree which visual work can wait until those checks exist.
• Do not start the redesign until the lead step has a number and a suspected cause.

On inherited production systems, the work that held was architecture and performance before new features. The decision was what to steady, not whether to throw the application away. A redesign can still be the right later project. It is a weak first project when the only evidence is that the site feels slow and the leads feel few.

When to bring in a specialist

Time it yourself. You do not need a developer to write down the screen, the click and the seconds. Ask for help when the slow path is inside the database or a queue and nobody on the team can read it, when the site was inherited and the repository or hosting is still not yours, or when a redesign quote is already in the inbox and the brief does not mention the operation you timed.

That is the work I take: the diagnosis, then the development on the system you already have. Services cover performance work, SaaS and backend systems, and AI integration. Selected work is the same kind of situation, with each result kept next to the operation that produced it. If you want a second look at the screen you timed, message me on LinkedIn and send the note: the URL, the click and the seconds.