Are you geared for a downhill market?
In a market where prices rise and growth falters, you need to keep in control of your expenses. Are you spending your money wisely?
The market of business is changing. The inflation is on the rise – as is the interest rate. And at the same time, we see a decline in growth.
:Sigh:
As a result, it’s becoming increasingly expensive and challenging to do business. But what does that mean for your digital organisation?
Digital priorities
To support the overall business, your digital organisation needs to be efficient. That means optimising processes and minimising expenses. With that objective in mind, there are of course numerous handles to pull. We focus on three: Speed, licenses, and development.
The business impact of speed
Over the years, there have been several studies that calculated significant increases in business results by just improving the webpage speed by 1 single second. If you operate a regular commerce site, then improving 1 second will have a considerable impact on several factors: You’ll see lower bounce rates, higher conversion rates, and stronger SEO.
These three factors combined will lead to higher revenue. Yeah!
Just to highlight a couple of interesting cases – please note that these numbers below are everything else equal (or Ceteris paribus, as we learned in business school):
1 second improvement of the webpage speed increased with 7% the conversion rate for Zalando
1 second slower site increased with 10% the bounce rate for BBC
Spend your license money where they matter
A well performing website, however, is not all you need if you want to keep cost-effective.
In many organisations, one of the major money pits is licence costs.
There are plenty of ideas and software to invest in, but in a cooling market you need to be choosy. You’ll probably want to trim your subscriptions – and perhaps renegotiate the ones you mean to keep.
Take a look at your IT architecture too. In a quest to build high-performing websites, many opt for a headless solution – and end up with a spiderweb of integrations and costly licenses.
That’s both directly expensive in licence fees, but also indirectly costly in maintenance.
This is not least the truth, if your infrastructure includes a licence CMS in a headless setup with multiple Content Delivery Servers. There is a lot to save if you have a large and complex setup around your installation today.
A simplified infrastructure including a standardised Speed layer will help you on both accounts. You’ll save on maintenance, and you’ll improve your performance significantly.
Clean up your development
In your quest to make your digital organisation more economical, you should also evaluate your development. Do you have an efficient setup? Do you spend your energy on the things that can really move your organisation forward? Do you work efficiently?
Many organisations are digitally wrapped up in legacy tech and it can be overwhelming to face the digital and technical dept they have in front of them. But you don’t need to accept either status quo or to completely overhaul your architecture. You can opt for a more evolutionary route towards digital transformation and focus on separating your frontend from the rest of your legacy system landscape. By doing so, you can build the optimal customer experience for your business at a lower cost, thus realising the business objectives faster and easier.
One way to go if you decide on the evolutionary way is to implement a Speed layer, where you can revitalise all legacy data sources for new uses at the frontend.
👉 More on making legacy great again
And now we’re at it… How much custom do you maintain? When putting together – or when expanding – your infrastructure it’s not uncommon to bridge separate source integrations with custom code. That leaves you with a very specific solution that needs constant supervision and upkeep. That is maintenance heavy and perhaps not the most effective use of your developer time.
Consider, if an off-the-shelf solution isn’t the better choice. It might cost you on licence, but it can also save you enormous maintenance resources.
And then there’s your development processes. Because it’s not all roses in the land of modern decoupled architecture.
A simple change may require changes in multiples pieces of software. Most often across several people and in some cases across several teams. The more people that are involved, the more time it’ll take, and the more expensive the change will be.
Too often, tech teams end up in bottleneck situations, where the architecture basically forces especially frontend developers to depend heavily on backend action.
The frontend developers might experience process delays because they’re forced to wait for backend developers to e.g. orchestrate the APIs. That’s beyond frustrating for all. The frontend developer can’t move on, and the backend developer is pulled away from their own task to serve someone else.
Have you considered how a more efficient development process can enhance your time to market? What it would mean for your time management if smaller changes such as property name changing or structure alterations don’t require you to change, merge or deploy code?
How much easier it would be if all developers – be it .NET developers, JavaScript developers, java developers, react developers, or something fifth – can all work easily together?
Consider, how you can build an architecture, that enables all your developers to work simpler and more flexibly without having to rely too deeply upon each other.
The short version
So, to wrap up: If you’re not already focusing on your webpage speed performance, now is the time to begin. But look at your architecture too. In a quest to build high-performing websites, many go for a headless solution – and end up with a spiderweb of custom integrations and costly licenses.
A simplified infrastructure including a standardised Speed layer will improve your speed, licenses, and development. You’ll save on maintenance, and you’ll improve your performance and user experience significantly. And we all know how that can mean big business 😉
Facts: What is speed?
Speed indicates Time To First Byte. TTFB measures the duration from the user or client making an HTTP request to the first byte of the page being received by the client's browser.
Speed is also a major influencer on your overall performance.
Why is your webpage slow?
Often, a combination on several issues drives down your webpage performance – but a few issues are close to universal:
- Daily work
One of the biggest issues for your website performance is the actual daily work. In a high-velocity world, we tend to add and add, without taking things away. The more you add without optimising or taking something away, the more you will decrease the site’s performance.
We’re fans of the quote from French philosopher Antoine de Saint-Exupéry: “Perfection is not achieved when there is nothing left to add, but when there is nothing left to take away.”
Apply this to everything from adding new filters to adding more data scripts to new features – greed combined with a busy day job is your worst enemy to high performance.
- Slow database
The second major root cause for slow webpage performance is slow databases serving the front end. In a world where every company is hunting hyper-personalisation, digesting, and serving the right data with speed at the edge is often neglected.
For years, we’ve worked towards optimal speed – and it’s not an embellishment to say that we’ve been hindered by slow databases.
The slower the database used to load inquiries to your webpage, the fewer customers will visit and finish a purchase on your site.
- Codebase and architecture
So many organisations are struggling with old legacy systems or customised monoliths that are extremely difficult to scale. Particularly so because all data streams through the monolith all the way to the front-end/customer.
That’s bad for performance and security (high risk of hacking).
- Hosting
Another key factor in high performance sites is the hosting setup. Most companies jumping towards cloud solutions has already attempted to solve this issue. However, just shifting the codebase to the cloud, will not bring you high performance – it will only make it easier to add CPU+RAM. But you should note that this can be an extremely expensive way to scale.
True scalability requires support from the underlying architecture/software. When you go cloud, you should still revise the speed killers above (1-3). If these are not in place, you’ll continue to struggle to compensate for the bad site performance.
CEO and Partner at Enterspeed. Speaker on digital transformation and the future of Enterprise tech. Loyal lover of Liverpool! ⚽❤️