Many SEO professionals lean on “best practices” in their SEO efforts. 

But when optimizing JavaScript-based enterprise websites for site speed, you need more than “best practice.” 

Here’s why standard solutions don’t always apply to enterprise sites and what you can do instead.

Improving site speed: Migrating to server-side rendering isn’t always the right answer

Imagine going to the CEO (or anyone in senior leadership) and advising them, “We need to change our website to server-side rendering (SSR).” 

They ask you, “Why?” and the only answer you can give them is, “Because it’s best practice to improve site speed.” You would, likely literally be laughed out of the room. 

The business implications and costs associated with SSR migration are not worth the high effort and low impact.

Unless an enterprise website is built from the ground up to be server-side rendered or is going through a website migration already, there’s rarely a reason to migrate to SSR. 

Think about some of the soft and hard costs that would come it: 

  • Reviewing all systems and APIs to confirm compatibility, which probably isn’t all documented (likely in the hundreds, if not the thousands).
  • Thousands of man-hours to refactor, QA and review accessibility for the entire website.
  • Training existing staff on the new framework (dozens, if not hundreds, of folks across the org).
  • Hiring or firing developers and engineers who either aren’t willing or aren’t up to spec on the new framework.
  • More money spent on server fees.

Rather than enduring such a time-consuming and resource-intensive process, there are other, more successful ways to improve the speed of enterprise websites. 

In a previous enterprise role, I talked out this very scenario with one of our senior systems engineers for fun. 

We estimated it would take the company a year and a half, a dedicated agile tribe (usually about 70 people), and at least $2 million (AUD) to do. And that was probably a conservative estimate. 

So what do we do instead to make headway? 

Get to know your other teams and help them

At an enterprise level, the SEO needs to be a chameleon because you’re relying on other teams to prioritize and get your work done for you. 

There’s a good reason you don’t have the keys to the kingdom to make changes on the website live. So SEO isn’t just SEO. 

SEO is “this will improve our site speed/help us meet accessibility requirements/etc.” SEO is everythingbut SEO. 

Tom Critchlow has said this in his SEO MBA course and on my podcast, Engage: On Enterprise SEO. 

It summarizes life as an enterprise SEO really well. 

You must spend a lot of time listening and paying attention to what other people are doing and then show them how what they’re doing has improved the website’s organic visibility. 

Create advocates, and these folks will keep coming back to you with a steady report of what they’re doing and changing on the website. That’s half the battle there. 

The second half involves working with developers, designers and analysts to get things done. This is usually much smoother when you realize people are people with their own thoughts, feelings and goals.

Being a curious person who wants to help them make their lives easier is a lot more appealing than working with a bull in a china shop who comes into their life every few weeks and makes demands without compromise. 

Working with developers and producers

At many enterprises these days, site speed is a known factor that helps (or hinders) conversion rates. 

Many development teams in-house probably have site speed as a KPI. Tap into that. 

You’re both after the same thing, and your developers will know the codebase better than you will. And if done well, you may both come out of it with a bonus. 

Some of the common site speed opportunities I’ve found that developers can help you with include: 

Size/weight of code

If your teams have tech debt sprints or allocations, keeping across when they typically do this work can help you understand the impacts of their refactoring. 

Reflect it back at them and acknowledge their hard work. 

Image loading and cumulative layout shift (CLS)

CLS can be a big factor in the perceived load time of large, enterprise, JS-based websites. Depending on how this is implemented, using a placeholder JS library to effectively “hold” the position of images can reduce the perceived load time of the page by not shifting the page when images are loaded.

Redirect management

This wasn’t something I could make ground on because our redirect management was massively fragmented. 

If your system is a bit more centralized, though, managing redirects, removing the hops, consolidating rules into regex, and improving that technical debt could help quite a bit. 

With some server deployments, each redirect rule needs to be read before the page can load, and that can add a decent amount of time (more than milliseconds) to the initial load time.

Share This