Build / Website Speed Optimization
Performance work that identifies the real constraint, whether it sits in the front end, the application, the database or the server.
TechSteps diagnoses why a site is slow before changing anything, because the cause is frequently not where people expect. It may be the front end, an expensive database query, a plugin making a blocking external request, or undersized hosting. We measure, identify the actual constraint, fix it and show the difference in real user data rather than in a single synthetic score.
What this solves
Speed optimization is the area where guesswork is most common and least effective. A tool produces a score, the recommendations at the top get implemented, the score improves slightly, and the site still feels slow to the people using it.
That happens because the score measures a synthetic load of one page on a simulated device. It is a useful signal and it is not the same as what your users experience, and it frequently does not point at the real constraint.
The useful question is where the time actually goes for real visitors on real pages. Sometimes the answer is images. Often it is a slow response from the server, which no amount of front-end work will fix.
When people call us
If more than one of these sounds familiar, the underlying cause is often a single issue rather than several separate ones.
Technical scope
Not every engagement includes all of this. The scope is agreed in writing before we start, and anything excluded is named rather than left ambiguous.
How we approach it
Real user data first, then synthetic tests on the templates that matter. Without a baseline, any improvement is an assertion.
If the server takes 1.5 seconds to send the first byte, front-end optimization is not the answer. This single split determines where the work goes.
Not the longest list of recommendations. One expensive query or one third-party script frequently accounts for most of the problem.
Caching a slow page hides a slow query until the cache misses. We prefer to fix the query and then cache it.
The same measurements, the same pages, the same conditions. Improvement is reported as a comparison, with the method stated.
Performance regresses. Knowing within days rather than months is the difference between a small fix and another project.
What goes wrong
These are the patterns we see most often when we are called in to fix someone else's work, or our own from earlier in our careers.
Deferring scripts until after the measurement window improves the number and not the experience. The score is a proxy, not the goal.
The cached page is fast and every cache miss is slow. Under real traffic, misses are common enough that users still hit the slow path.
Cart, checkout, account and logged-in views get cached. This is a correctness bug and occasionally a data exposure, which matters far more than speed.
The largest element above the fold is deferred, which delays exactly the thing being measured and makes the page feel slower.
Tag managers, chat widgets and tracking pixels are frequently the largest single cost on a page, and are rarely audited because nobody owns them.
Questions we actually get asked
Usually because the constraint was not what caching addresses. Caching helps when the server is doing repeated expensive work to build the same page. It does not help if the delay is in the browser rendering, in third-party scripts, or on pages that cannot be cached anyway, which includes most of a logged-in or checkout experience.
We will not give you a number before measuring, because a genuine answer depends on the cause. What we will do is tell you within a short investigation what the constraint is and what removing it is worth. If the honest answer is that the gains are small, you should hear that before spending money.
It is worth passing, and it is a floor rather than a target. The field data behind it reflects real user experience, which makes it more useful than a synthetic score. Once you pass, further optimization should be justified by user experience or conversion rather than by moving a number that is already green.
Frequently, particularly on mobile and particularly where pages were genuinely slow. We will not promise a percentage, because conversion depends on price, product, trust and competition as well as speed. What we can do is measure the technical improvement honestly and let you compare it against your own conversion data.
Sometimes, and it should be the conclusion rather than the assumption. Plenty of sites on modest hosting are slow because of their own code. We would establish that the application is efficient before recommending you pay for more infrastructure to run inefficient code faster.
Describe the system and what is going wrong with it. A short technical conversation is usually enough for us to tell you whether this is the right work and roughly what it involves.