Slow pages cost you trust before anyone's even read your copy. We track down what's actually making your site sluggish, on Umbraco or anything else, and fix it properly.
Marketing leads want a site that converts, and a score they can defend to the board without flinching. IT managers want a straight answer on what's actually causing the drag, not a vague "it's probably Umbraco" shrug. Whoever's fielding the complaints just wants them to stop. For most of them, the real measure isn't a score at all, it's whether the browsing experience feels fast to an actual visitor.
We look across templates, hosting, database queries and content, not just your homepage, because that's where most of your traffic actually lands. Umbraco Performance is where we go deepest, but the same rigour applies whatever's running under the bonnet. Get this right and it also supports your organic traffic and protects your conversion rate, not just how the site feels to use.
Our approach to successful projects
Before we touch anything, we look at how your site actually behaves under real traffic, not a single homepage test. That means checking load times across your highest-traffic templates, not just the front door, alongside Core Web Vitals, mobile performance and server response times. On Umbraco specifically, we look at your caching configuration, how content queries are structured, and whether Examine's indexes are doing more work than they need to. We also ask about the business side: which pages actually drive enquiries or bookings, what your board or team already believes about the site's speed, and what's already been tried. The aim is a clear, evidenced picture of what's slow and why it matters, before we propose fixing anything. Think of this stage as your performance audit, the diagnostic work that tells us what's actually worth fixing.
Not every fix is worth making, and we'll say so. We weigh each finding against the effort to fix it and the actual business impact, a slow-loading carousel on a rarely-visited page matters less than a sluggish enquiry form. Where output caching would help, we work out whether in-memory caching is enough or whether a distributed setup makes sense for your hosting and traffic. We also flag anything Google's own tooling suggests that we wouldn't actually recommend, over-compressing images until they look poor is a real trade-off, not a free win. You get a prioritised plan, not a wall of technical findings with no order to them.
This is where the fixes actually happen. On Umbraco, that typically means configuring output caching properly, reviewing the database queries and value converters doing more work than they should, and building sensible image compression and resizing into the content pipeline so editors don't have to think about it. On the front end, we defer what doesn't need to load immediately, tidy up render-blocking scripts, and make sure visible content appears before everything else catches up behind it. None of this happens in isolation. We test as we go, on real devices and real connections, so we know a fix has actually worked before moving to the next one.
Speed problems creep back in if nobody understands what caused them the first time, so we don't just hand over a fixed site and disappear. We explain what we changed and why, in plain English, and show your team where the risk usually reappears, most often through oversized image uploads or a new third-party script bolted on without anyone checking the cost. If content editors are the ones adding media day to day, we make sure the defaults do the right thing automatically, rather than relying on someone remembering a rule three months from now. You end up with a team that understands its own site, not one still waiting on us to explain it.
Once the fixes are live, we keep watching. Performance isn't a one-off project, new content, new integrations and a growing site will always pull load times back the wrong way eventually. We monitor Core Web Vitals and load times across your key templates on an ongoing basis, so a slow creep gets caught before it shows up in your conversion numbers. If you're already a Gecko support client, this sits inside that relationship directly. If you're not, we'll tell you plainly whether ongoing monitoring is worth it for a site your size, rather than upselling it regardless.
We configure Umbraco's output caching properly, whether that's caching server-rendered Razor pages or Delivery API responses if you're running headless. Done right, the server skips re-running the full rendering pipeline for repeat requests, which cuts both load times and server load under real traffic.
We also make sure caching isn't papering over a genuine problem elsewhere. Output caching is brilliant for performance, but it isn't a fix for slow underlying queries or a badly structured content tree, so we check what's underneath before switching it on. If you're running multiple servers, we look at whether a distributed cache makes sense for your setup, and what happens to performance if it goes down.
A lot of Umbraco slowdown comes from how content is queried and structured, not the platform itself. We review your value converters, your content architecture and the queries running behind your busiest templates, looking for the inefficient ones doing far more work than the page actually needs.
Deeply nested content trees, badly scoped queries and an Examine index carrying more than it should all show up here. Where the fix is structural rather than a quick tweak, we're honest about that upfront. Some of this is a genuine rebuild of how content is organised, not a setting we can flip. We're looking for genuine performance bottlenecks here, not hypothetical ones, so anything we flag is something actually slowing your busiest pages down.
Oversized images uploaded by well-meaning editors are one of the most common real causes of a slow site, and it's rarely anyone's fault, it's just that nothing's stopping it. We build compression and responsive resizing into your upload process so the right-sized image gets served automatically, rather than relying on someone remembering to resize before hitting publish.
We also review your existing media library for anything already dragging your pages down, and set sensible defaults going forward so this doesn't quietly creep back in six months from now.
Beyond the CMS itself, we look at what's actually loading in the browser: JavaScript and CSS blocking the page from rendering, third-party scripts and chat widgets stacking up over time, and layout shifts that make a page feel unstable even if it technically loaded fast.
We defer what doesn't need to load immediately, minify what's left, and prioritise getting visible content on screen before everything else catches up. This is often where the gap between a good PageSpeed score and how a site actually feels to use gets closed.
We also check which JavaScript libraries you're relying on, since it's common to find several doing the same job, or one loaded in full for a feature that only needs a small part of it, and bring older markup up to current web standards where that's a quick, worthwhile win.
Sometimes the ceiling is your hosting, not your code. We review server response times, how your hosting handles traffic spikes, and whether your current setup is doing you any favours as the site grows. For UK-focused audiences, a CDN isn't always the automatic win it's sold as, and we'll tell you honestly whether it'll make a real difference for your traffic pattern rather than adding cost for cost's sake.
Where hosting genuinely is the bottleneck, we'll say so plainly, and talk through what moving or upgrading would actually involve. We also check things like HTTP/2 or HTTP/3 support, and other protocols and standards a modern host should meet, since an outdated setup here can quietly cap how fast an otherwise well-optimised site is able to load.
A one-off fix doesn't stay fixed on its own. We monitor Core Web Vitals, load times and server response times across your key templates over time, so a slow creep gets flagged before it costs you conversions rather than after.
You get a clear read on what's changed and why, not just a dashboard you're left to interpret yourself. This sits comfortably alongside our ongoing support packages if you want it there, or as a standalone check-in if you'd rather keep things occasional. We track your Web Vitals scores over time too, not just a single Core Web Vitals snapshot, so you can see whether things are genuinely improving or quietly slipping.
We configure Umbraco's output caching properly, whether that's caching server-rendered Razor pages or Delivery API responses if you're running headless. Done right, the server skips re-running the full rendering pipeline for repeat requests, which cuts both load times and server load under real traffic.
We also make sure caching isn't papering over a genuine problem elsewhere. Output caching is brilliant for performance, but it isn't a fix for slow underlying queries or a badly structured content tree, so we check what's underneath before switching it on. If you're running multiple servers, we look at whether a distributed cache makes sense for your setup, and what happens to performance if it goes down.
A lot of Umbraco slowdown comes from how content is queried and structured, not the platform itself. We review your value converters, your content architecture and the queries running behind your busiest templates, looking for the inefficient ones doing far more work than the page actually needs.
Deeply nested content trees, badly scoped queries and an Examine index carrying more than it should all show up here. Where the fix is structural rather than a quick tweak, we're honest about that upfront. Some of this is a genuine rebuild of how content is organised, not a setting we can flip. We're looking for genuine performance bottlenecks here, not hypothetical ones, so anything we flag is something actually slowing your busiest pages down.
Oversized images uploaded by well-meaning editors are one of the most common real causes of a slow site, and it's rarely anyone's fault, it's just that nothing's stopping it. We build compression and responsive resizing into your upload process so the right-sized image gets served automatically, rather than relying on someone remembering to resize before hitting publish.
We also review your existing media library for anything already dragging your pages down, and set sensible defaults going forward so this doesn't quietly creep back in six months from now.
Beyond the CMS itself, we look at what's actually loading in the browser: JavaScript and CSS blocking the page from rendering, third-party scripts and chat widgets stacking up over time, and layout shifts that make a page feel unstable even if it technically loaded fast.
We defer what doesn't need to load immediately, minify what's left, and prioritise getting visible content on screen before everything else catches up. This is often where the gap between a good PageSpeed score and how a site actually feels to use gets closed.
We also check which JavaScript libraries you're relying on, since it's common to find several doing the same job, or one loaded in full for a feature that only needs a small part of it, and bring older markup up to current web standards where that's a quick, worthwhile win.
Sometimes the ceiling is your hosting, not your code. We review server response times, how your hosting handles traffic spikes, and whether your current setup is doing you any favours as the site grows. For UK-focused audiences, a CDN isn't always the automatic win it's sold as, and we'll tell you honestly whether it'll make a real difference for your traffic pattern rather than adding cost for cost's sake.
Where hosting genuinely is the bottleneck, we'll say so plainly, and talk through what moving or upgrading would actually involve. We also check things like HTTP/2 or HTTP/3 support, and other protocols and standards a modern host should meet, since an outdated setup here can quietly cap how fast an otherwise well-optimised site is able to load.
A one-off fix doesn't stay fixed on its own. We monitor Core Web Vitals, load times and server response times across your key templates over time, so a slow creep gets flagged before it costs you conversions rather than after.
You get a clear read on what's changed and why, not just a dashboard you're left to interpret yourself. This sits comfortably alongside our ongoing support packages if you want it there, or as a standalone check-in if you'd rather keep things occasional. We track your Web Vitals scores over time too, not just a single Core Web Vitals snapshot, so you can see whether things are genuinely improving or quietly slipping.
Cristiano Martins, Senior Full Stack Developer at Gecko
[PLACEHOLDER: no confirmed performance case study with real before/after metrics currently exists. Section held here structurally until one's available.]
[CLIENT NAME/SECTOR] had a site that scored well on paper but felt slow to the people actually using it. We tracked the real cause back to [ISSUE], fixed it, and measured the difference on the templates that actually mattered to their traffic, not just the homepage.
No. Umbraco itself isn't the bottleneck in most cases we see. Problems usually come from how a site's been implemented: unoptimised database queries, an Examine index carrying more than it needs to, hosting that hasn't kept pace with the site's growth, or third-party scripts added over time without anyone checking the cost. Older Umbraco 8 sites can carry extra baggage too, ageing .NET dependencies and End of Life considerations add real weight. The platform gets blamed because it's the thing everyone can see, when the actual cause is usually a few layers underneath it.
Only if performance is part of the brief from day one. A redesign focused purely on how a site looks can just as easily make speed worse, more scripts, heavier visuals, a new set of images nobody's compressed yet. If speed matters to you, say so before the design work starts, not after launch when you're wondering why nothing's changed.
It can help, particularly with hosting-related bottlenecks, but it isn't a fix on its own. A badly structured content tree or an inefficient query is still a badly structured content tree or an inefficient query, wherever it's hosted. We'd look at implementation first, then talk about whether Cloud is the right move for your setup.
Treat it as one input, not gospel. Google's test conditions are deliberately harsh, closer to an old phone on a patchy connection than how most of your actual visitors browse, which is why even major sites often score poorly. Not every fix it suggests is worth making either. Over-compressing images to chase a few extra points can leave them looking noticeably worse for barely any real-world gain. We'd rather test your site the way people actually use it, then act on what that tells us. It's still useful for spotting real problems, the specific Web Vitals and Core Web Vitals metrics dragging a page down, layout shift or slow interactivity, for instance. Treat it as a helpful online tool for a first look though, not gospel, and we won't blindly action every PageSpeed suggestion it makes without checking it's actually worth it for your visitors. PageSpeed Scores can also shift between individual test runs, which is another reason we look at trends across several checks rather than reacting to any single number.
Umbraco is where we go deepest, and it's genuinely our specialism, but the diagnostic process (checking real templates, real traffic, real user experience rather than a single lab score) applies to any platform. If you're not on Umbraco, we'll still tell you plainly what we can and can't help with before you commit to anything. Plenty of site owners come to us this way, testing the water before deciding whether to move platforms entirely. If you're running a theme-based website instead of Umbraco, we'll adjust our approach accordingly but keep the same diagnostic rigour.
We start by looking at how your site behaves under real traffic across your key templates, not just the homepage, alongside your hosting, your content architecture and (on Umbraco) your caching and indexing setup. You get back a clear, prioritised picture of what's actually slow, why, and what it would take to fix, before any work begins on fixing it.
It depends on what we find. A caching and image optimisation pass can often be turned around quickly. Something structural, like a content architecture rebuild or a set of genuinely inefficient database queries, takes longer, and we'll always tell you which kind of problem you've got before quoting a timeline. Whether it's a full site speed optimisation project or a narrower fix, we'll be upfront about the likely timeframe before you commit to anything.
Rarely one bad decision. It's usually a gradual build-up: tracking scripts and chat widgets added one at a time, images uploaded at full size because nothing stopped that, ageing packages, and hosting that hasn't been revisited since launch. None of it looks dramatic on its own. Together, it adds up to a site that feels noticeably slower than it did on day one.
Both, where it's relevant. Sometimes the site itself is well optimised and the ceiling is genuinely the hosting underneath it. We'll review server response times and how your setup copes with traffic, and say plainly if that's where the real problem sits, rather than only working on what's easiest for us to change.
Get in touch and tell us what's feeling slow, or send over a link to the pages you're worried about. We'll take a look and give you an honest steer on whether it's worth a proper look before anything's booked in. If it looks worth a full performance audit, we'll scope that out with you before anything's confirmed.
