Hilltop Products has sold cable management, heat-shrink and sleeving to the UK trade for over 45 years. Their Magento store carries more than 8,000 products. Most are sold by the pack, most carry size or colour options, and all of them are on trade pricing. We built that store, and we are the ones rebuilding its storefront.
What Hilltop asked for is what most manufacturers ask for. A site that loads quickly, because a trade buyer comparing pack prices on a phone in a van does not wait. A site that looks like the company behind it. A site that is cheap to change, built on a modern theme that is actively maintained rather than quietly ageing, so a day’s work costs a day rather than three. And the commercial machinery owned outright by Hilltop rather than rented from a paid extension that is no longer supported: pack sizes, quantity breaks, the price a trade customer actually pays.
That last point is the one we would draw a fellow manufacturer’s attention to first, and we will come back to it. Here is what Hilltop is getting, what it means in practice, and the numbers behind it.
Measured on the build store, August 2026.
Key takeaways
- It is faster because there is far less to download. The old homepage made the browser fetch 27 separate script files before the page worked. The new one fetches one, and the whole page weighs about 129 KB instead of about 4.13 MB.
- Prices are right the moment the page appears. Pack quantities, quantity breaks and the VAT figure are worked out before the page is sent, so nothing flickers or corrects itself a second later while a buyer is reading it.
- Three licensed plugins are gone. The commercial logic behind Hilltop’s catalogue is now code Hilltop owns outright. There is no annual licence, no queue at another company’s support desk, and any competent Magento developer can pick it up.
- It is built on a theme that is actively supported and straightforward to work on, which is the part that keeps the cost of future changes down.
- Nothing behind the shop window was disturbed. Payments, shipping, address checking, search and the ERP link all carried over untouched, along with every customer account and order.
- The rebuild is on the build store and close to launch, so no live traffic figures are quoted here.
What the rebuild actually buys them
Four things, in the order a managing director tends to care about them.
Speed. A slow trade site is a leak, and it leaks worst on exactly the customer you want: the buyer on a phone, on site, comparing you against two other suppliers. The rebuild moves roughly 97% less code across the connection to draw the same page. That is not a tuning gain; it is the result of throwing away a fifteen-year-old way of building storefronts and using a current one.
Appearance. A trade catalogue has to look like a company you would place a five-figure order with. The rebuild is a genuine redesign, not a reskin, and every one of Hilltop’s 8,000-odd products keeps its images, its specification and its pricing.
Cost of change. This is the one that gets underestimated. The theme Hilltop is moving to is actively developed, well documented and simple enough that a developer can read a page template and understand it. Changes that used to mean unpicking layers of overrides now mean editing one file. Over a few years that difference is worth more than the speed is.
Ownership. Three paid plugins have been replaced by modules Hilltop owns. There is no annual licence to renew, nobody else’s roadmap to wait on, and if The Art Lab disappeared tomorrow another developer could open the repository and carry on. That is a reasonable thing to insist on from any supplier, including us.
Why it is faster, in one paragraph
When a browser opens a page it has to collect every file that page depends on before it can finish drawing it. On the old Hilltop homepage that meant 27 separate script files from Hilltop’s own site, weighing about 4 MB between them. On the rebuild it is one file, and the page as a whole comes in at about 129 KB. Same shop, same products, roughly a thirtieth of the material. That is the entire explanation for why one feels quick and the other does not.
The measurement, for anyone who wants to check it
Magento’s backend is not what makes a Magento store feel heavy; the frontend theme is. Luma, the theme Magento 2 ships with, was designed around RequireJS and Knockout.js, a module loader and a data-binding library from an era before browsers could do either job themselves. Both sit on top of jQuery, and all of it has to arrive before the page becomes usable. Hyvä, the theme we have rebuilt on, discards that stack rather than tuning it: Tailwind CSS for styling, Alpine.js for behaviour, and Alpine is 16 KB for the whole framework. We measured the same homepage on each build on 23 August 2026, reading every first-party script referenced in the page and fetching each one with compression enabled.
| Before | After | |
|---|---|---|
| Script files from the store’s own domain | 27 | 1 |
| Those scripts, compressed | ~4,092 KB | ~1 KB |
| RequireJS present | Yes | No |
| Knockout present | Yes | No |
| Page itself, compressed | 35 KB | 128 KB |
| Page + own scripts combined | ~4.13 MB | ~129 KB |
The last row is the honest comparison, and the fifth row is why. The new page document is deliberately larger, 128 KB against 35 KB, because the component code is written into the page itself rather than fetched as separate files afterwards. Some of what used to count as JavaScript now counts as page. Even counting it that way, the rebuild moves about 97% less code to draw the same page. Third-party scripts such as Google and Trustpilot are excluded from both columns, because they load identically on each build and including them would flatter neither.
The pricing machinery, rebuilt as code Hilltop owns
This is the part of the project we would point a similar manufacturer at first, and it is worth being blunt about why.
Hilltop’s products are unusual in a way that will be familiar to anyone selling to the trade. A single heat-shrink line can carry colour and size options, and each of those variants can carry its own pack quantities, each with its own price break. That is the commercial heart of the business expressed as a product page. It was running on a paid extension that is no longer supported. That is a dependency Hilltop had no control over, sitting underneath the thing that takes the money.
So we wrote it ourselves, as a module Hilltop owns. It handles pack options that differ between variants, swaps the image and description as a shopper moves between sizes, and produces a shareable link for a specific configuration so a buyer can send it to a colleague or paste it into a quote. Prices and VAT are worked out before the page is sent, which means every figure on the page agrees with every other figure the instant it appears. No flicker, no number that corrects itself while somebody is reading it. A trade customer comparing pack prices sees one consistent set of numbers.
That module is Hilltop’s code, in Hilltop’s repository, with no licence to renew and no vendor roadmap to wait on. We did the same for the accessories block on product pages and for a set of operational customisations covering stock deduction across shipment sources and PDF invoice generation. Three licensed plugins out; three modules in, all of them Hilltop’s property.
The wider module estate got the same treatment. Thirty-two frontend packages came out: a checkout stack the new theme replaces with its own, a second search tool doing work the main search already does, a “call for price” add-on, and one of two competing blog tools. That is not a tidiness exercise. Each of those packages was pushing its own code onto every page a customer loaded, and each was another supplier who had to still be in business for the site to keep working. In total the rebuild strips roughly 153,000 lines of code and adds about 22,000 lines in their place.
What the storefront does for Hilltop now
All 554 products with options are buyable on the new theme, with their pack choices, price breaks and VAT display intact. Stock status comes straight from the ERP: at the last count four products showed as unavailable, and all four genuinely are. Every product and category image in the catalogue resolves.
On top of that, 6,431 products now carry their full specification on the page and 1,435 carry product video. That is the technical detail a specifier needs in order to commit, in front of them rather than in a PDF two clicks away. The product page is the clearest single result of the rebuild: four script files instead of 28, and the main content drawn in about a second with nothing jumping around as it settles.
What deliberately did not change
This is the question every client asks first, and the answer is the reassuring one. A rebuild of this kind replaces the shop window, not the shop. Everything behind it stayed exactly as it was. Same systems, same settings, same data:
- Payments: Stripe, including Stripe Tax
- Shipping: Calcurates rate engine and Shiptheory despatch
- Address validation: Loqate
- Search: Algolia
- ERP: the link Hilltop’s stock and orders depend on
- Marketplaces and feeds: M2E Pro, Google Shopping feeds
- Reviews, email and reporting: Trustpilot, Remarkety, Aheadworks
- Customers, orders, catalogue: the database itself
Nobody’s account, order history or saved address is affected by a change of theme. Web addresses and redirects live in the database and move with it, so the address of every product and category stays the same and the search rankings attached to them stay put. That is the whole point of doing it this way, and it is why a rebuild of this size is a scheduled project rather than a leap of faith.
Why this matters if you sell to the trade
Trade catalogues are the case this approach suits best. They are heavy on products with options, pack quantities, quantity breaks and VAT toggling. Those are all things an older storefront works out in the browser after the page has arrived, and a modern one works out before it sends the page. If your customers are specifiers comparing price breaks on a phone, that is the difference between a page that is right immediately and one that settles into being right.
The second point is ownership, and it is the one worth taking away even if you never touch your website. How your pack sizes are priced, how your variants behave, how your tax is displayed: that is your business, not a plugin feature. Where it can be written as code you own, it should be. It takes a licence out of the budget, takes a dependency out of the roadmap, and it means the behaviour changes when you decide it should rather than when somebody else gets round to it.
One thing we are not doing here is quoting speed scores or traffic gains. The rebuild has not taken live traffic yet, and figures from a build server would not tell anyone anything honest about what real customers experience. Establishing that baseline properly, before and after, is a post-launch job. We would rather publish it late than publish it invented, which is the same standard we apply to the numbers we report to clients every month.
Frequently asked questions
Does this mean rebuilding our whole Magento store?
No. It replaces the part customers see. The backend, database, customer accounts, order history, payment gateway and ERP link all stay in place. On Hilltop’s rebuild every one of those carried over unchanged; the work was in the templates, the styling and the frontend add-ons sitting on top of them.
Will we lose our extensions?
Some, and usually the ones you are happy to lose. Anything that pushes its own code onto the page needs a compatible version or a replacement, and many suppliers now ship one. On this project 32 packages came out, mostly because the new theme’s own checkout replaced a multi-part checkout stack, and because the same job had quietly ended up being done in more than one place.
What happens to our search rankings?
Web addresses and redirects live in the database and move with it, so the address of every product and category stays the same. The page markup changes, so structured data is rechecked as part of the build. On this project we tightened the breadcrumb and product-offer markup while we were in there. Prices and specifications that are finished before the page is sent also give search engines more to read than a page assembled in the browser does.
How disruptive is the switchover?
Less than an in-place upgrade. The new storefront is built and rehearsed alongside the trading store rather than on top of it, so nothing changes for customers until it is signed off. We rehearse the switchover twice before the night itself: once rough, once against a written runbook with a stopwatch. If the dress rehearsal needs improvising, we move the date.
Is it worth it for a B2B catalogue?
It is the case it suits best. Products with options, pack quantities, quantity breaks and VAT toggling all benefit most from being worked out before the page is sent, and they are what a trade catalogue is made of. If your site is mostly a brochure with a contact form, the gain is real but smaller.
Thinking about the same move?
We build and rebuild Magento storefronts for UK manufacturers and trade suppliers, including the bespoke modules that carry their pricing and product logic. If you want a straight answer on whether this is worth it for your catalogue, including the cases where it is not, get in touch.
