I worked on SEO and UX for a high-traffic Hungarian hardware ecommerce store. I am not naming the brand because the project was not public, but the situation itself was very familiar: strong organic traffic, many product pages, heavy mobile usage, and a business goal that was not about “making the site look nicer.”
There was no fixed instruction that said which SEO task had to deliver the improvement. The goal was to improve organic performance, and the way to get there was left to me. Several directions would have made sense: technical SEO, content, internal linking, category pages, structured data. But I wanted to start with an area that could support SEO and also have a visible business impact. That is why site speed became the focus. It was not the smallest task on the list, but for a large ecommerce site it can be one of the SEO/UX improvements with the clearest business upside.
The starting point
The assumption was simple: slower pages tend to convert worse. That is not a new idea. Deloitte and Google’s Milliseconds Make Millions research, for example, found that even a 0.1 second improvement in mobile site speed can have a measurable impact on funnel progression. In retail, they observed an 8.4% increase in conversions and a 9.2% increase in average order value. According to the web.dev summary, the study was based on 37 European and US brand sites, more than 30 million user sessions, and a 30-day measurement period.
But the real question was not whether speed matters in general. The question was whether we could see a business effect on this specific webshop.
The problem
The site worked. It was not broken, it was not unusable, and at first glance it did not look dramatically slow either. In practice, this can be more dangerous than an obviously broken site. If something is visibly wrong, the decision to fix it is usually easy. If a site is “just a bit slower than it should be,” performance tends to slide down the development backlog.
That was the case here as well. There was an SEO backlog, a UX backlog, development tasks, campaign requests, promotional pages, and product page changes. Site speed was only one item among many. So we did not start with optimization. We started with measurement.
How we measured it
The goal was not to look at speed as a standalone technical metric. We wanted to connect speed with user behavior and conversion. We set up a site speed / Core Web Vitals style tracking system in Google Tag Manager and sent the measured values into GA4. The logic was similar to what Matthew Edgar describes: GA4 does not include the old-style site speed reports by default, but with GTM you can send values such as page load time, content load time, DOM interactive time, server response time, and Core Web Vitals-style metrics.
From GA4, the data went into BigQuery. That is where we cleaned the data, handled faulty or extreme values, and grouped sessions by speed. The goal was to move the conversation away from general PageSpeed scores and toward a more useful question: did users who experienced slower page loads buy at a lower rate?
The answer was yes. A linear regression showed a strong relationship between mobile load speed and conversion rate. The correlation was -0.81. The sign was negative because a higher load time is worse: the slower the experience, the lower the conversion rate.
I would not present this as “the regression proves everything.” It does not. Correlation is not causation. But in real projects, you often do not need perfect proof for the first decision. You need a strong enough signal to prioritize the work. Here, the signal was strong enough.
What the data showed
The average mobile load time at the starting point was around 5 seconds. That may not sound disastrous, but in ecommerce it is a lot. Especially on mobile, and especially on product listing pages, category pages, and product pages, where users do not make one big decision. They make many small decisions one after another.
The baseline conversion rate was around 2.6%. When we compared speed segments, users with a faster experience converted better. The data was not perfectly clean in every row. Not every bucket behaved like a textbook example. That is normal. Real data is rarely that neat. But the direction was clear.
At that point, the task was no longer to “keep watching it for another month.” The task was to bring the speed metrics down.
What we changed
The improvement came from several layers. In my experience, site speed is rarely solved by one big trick. The result usually comes from many smaller decisions that add up.
The first major area was image handling. The webshop had a large number of product and category images, which is normal for this kind of ecommerce site. The problem was not that the images existed. The problem was that in many cases they were not served in the right size or format. That has a direct impact on LCP, especially on mobile.
We introduced an image logic where multiple sizes were generated from the same uploaded image. The frontend did not serve the same large image to every user. Instead, it served a version that matched the user’s screen size and device. Where possible, we used WebP and AVIF, with fallbacks for browsers that needed them. This alone made a noticeable difference, especially on mobile.
The second major area was caching. With a custom ecommerce platform, this is rarely as simple as turning on a plugin and calling it done. Several layers had to work together. Static files, repeated database queries, and always-fresh business data all needed different handling.
Resource-heavy queries were cached at application level. OPcache and APCu helped on the server side. Images, CSS, and JavaScript were served faster through a CDN/reverse proxy layer. Browser cache rules also had to be cleaned up so users would not download the same assets again and again on every click.
The hard part was not enabling cache. The hard part was doing it without damaging the business logic of the webshop. Prices, stock data, and cart information had to stay fresh. The goal was not to cache everything aggressively. The goal was to separate what could safely be cached from what must never be touched.
The third area was JavaScript and CSS. The principle was simple: if something was not needed for the first render, it should not block the first render. Unnecessary code was removed, unused CSS was reduced, and non-critical JavaScript was delayed or loaded conditionally. This helped mainly on mobile.
HTML, CSS, and JavaScript minification were also added, but I would not overstate that part. HTML minification is useful, but it is rarely the thing that changes the whole project by itself. The bigger gains came from images, caching, reducing render-blocking resources, and removing unnecessary frontend logic.
The fourth part was less visible, but important. We did not treat this as a one-off “site speed project.” The process also had to prevent the site from becoming slow again two weeks later. A new banner, a new script, a new tracking pixel, or a new frontend component can easily undo previous work if nobody is watching the performance impact. This part is less exciting to talk about, but in practice it often decides whether the improvement lasts.
The result
| Metric | Before | After |
|---|---|---|
| Average mobile load time | approx. 5 sec | approx. 3 sec |
| Conversion rate | 2.6% | 2.73% |
| Relative conversion improvement | — | approx. 5% |
The average mobile load time decreased from around 5 seconds to around 3 seconds. That is roughly a 40% improvement. The conversion rate increased from 2.6% to 2.73%. In relative terms, that is about a 5% increase. If we used 2.72%, the relative growth would be around 4.6%, so for publication I would use 2.73% as the cleaner number.
At first glance, 2.6% to 2.73% may not look dramatic. This is why I am careful when people look only at percentage point changes in conversion rate. On a large ecommerce site, the story changes quickly.
In the sample calculation, using 500,000 monthly sessions and an average order value of 35,000 HUF, the improvement would mean roughly 22.75 million HUF in estimated additional monthly revenue. This is not an accounting figure. It is a publication-friendly estimate to show how much page speed can matter on a high-traffic ecommerce site.
What I learned
Many people still treat site speed as a technical SEO task. It is partly that. But on a large ecommerce site, it quickly becomes more than that. From an SEO perspective, speed matters for crawlability, user experience, landing page performance, and the quality signals Google may pick up from the site. But the user does not think in these terms. The user does not see a PageSpeed score. The user experiences waiting.
- The product list loads slowly.
- The image arrives late.
- The page moves just as they are about to tap.
- The cart button does not respond when they expect it to.
Each of these issues may look small on its own. During a buying journey, they add up. Especially on mobile, where users are often less patient and are not always browsing in ideal conditions.
For me, the most important result of this project was not that mobile load time dropped from around 5 seconds to around 3 seconds. That mattered, of course. But by itself, it is still a technical metric.
The real value was that we translated speed into business language. We were not saying: “The PageSpeed score is bad.” That alone rarely moves an organization. We were saying: “The slower user experience is connected with a measurably lower conversion rate. If we improve this, it can have a revenue impact.” That is a very different conversation.
It is also important to say that this was not a one-person project. My role was mainly to connect the business problem, SEO considerations, UX effects, and measurement data. The goal was to turn these into a development priority that was not only technically valid, but also made business sense. The implementation would not have worked without the internal development team.
With this kind of optimization, the result depends on many small decisions: what can be cached, what cannot, how images should be handled, what can be removed from CSS or JavaScript, where there is a real risk, and where something is still in the system simply because nobody has questioned it for a while.
You cannot solve these things from the outside by dropping an audit on someone’s desk. You need a development team that understands the system, knows its limits, and is willing to treat performance not as a separate technical task, but as part of the business goal.
That was the biggest lesson of the project for me. Site speed optimization works best when data, SEO, UX, and development are not running as separate topics, but are all working on the same problem.