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 everything but 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.

<button> in place of <a href>

This one is a bit more nuanced, but I often found JS developers defaulting to including ahref links as buttons. 

This is usually because they’re time-poor, and it’s a native default of the framework they’re working in. 

When I was QA’ing new page templates, I would often flag this to get updated to <a href>.  

Working with designers

One of the biggest site speed opportunities on enterprise websites is image size and weight.

Internal standards can be mistranslated or lost over time, particularly when teams are agile and somewhat decentralized.

When I started enterprise-side, I remember seeing images that were 10MB on product pages for some of our flagship products. It blew my mind. 

No image needs to be 10MB on the web. Full stop. 

So I had some delicate conversations with our designers and worked with them to reduce our image sizes over the course of about 8 months. 

100KB was not a hill I was willing to die on, so if I told a designer 100KB for a heading banner or a-frame, and they got it to 300KB, it’s still an improvement. 

Enterprise SEO is often about incremental wins. 

Working with analysts

Analysts come into the conversation because they’ll probably be managing your tagging systems and all the third-party tags on your website. 

They’re the entry point into having conversations with the tag owners about whether or not this particular tag is critical or if there’s an alternative. 

Because, boy, third-party scripts can cause massive bloat on the website. 

So while you’re having conversations about the 250+ advertising scripts on the site and if we need them all, you may be able to find some short-term compromises, like: 

• Only firing HotJar, Fullstory or another user experience monitoring script on pages that are actively being heatmapped or tracked.
• Auditing your implementations for duplicates (it happens more than you’d imagine).
• Seeing what chatbot or customer service tags can be launched onClick rather than when the page loads.

Working with the QA team

This partnership could very well be a secret weapon for you. SEO in general, but also JavaScript SEO, have a lot of binary yes/no requirements or best practices, like: 

• Meta data must be the same between the page source and client-side rendered page
• Canonical must be present on the client-side rendered page
• Links should be formatted as <a href=””> rather than <button>
• Preload fonts
• Pre-connect to large resources

Get in the good books with your QA team, and work with them (including training) to include these as a part of their general, everyday QA process. You’ll have eyes everywhere and a potentially massive network of micro-advocates. 

While there are a lot of other teams you could work with to improve your website’s SEO overall, these are likely the ones you’ll be working with the most when it comes to the more technical side of the implementation. 

Advocating for other teams you work with

Remember what I said earlier about how working with people happens when you remember they’re people? You want to put that into action. 

There are two really strong ways to do that at an enterprise level. 

Respect their time

Let’s say you have a big idea, like “we should migrate to server-side rendering.” 

In this case, rather than going to the PO and saying, “Hey, can we do all of this?,” work with them to create a proof of concept that they’ve validated falls in the “easy” bucket and track its impact.

If it doesn’t work, they haven’t essentially wasted 20 sprints to get this massive project done.

If it does work, you have a business case to take to the finance team to fund and prioritize the rest of the project to take it across the entire website and get that dedicated tribe, $2M and a year and a half to get it done. 

Amplify their effort

Something SEOs are notoriously bad at is communicating and sharing success. 

It may be a bit easier if, rather than saying, “hey look at this fabulous thing I’ve done,” you position it as, “hey look at this amazing thing this other team I worked closely with has done and this is how much it’s improved our site experience.” 

You, the SEO, are no longer the center of attention. The team who did the actual work is. 

Collaboration, advocacy and incremental wins

You may notice that I didn’t actually speak too much about the nuance of JavaScript and site speed in this article. 

That’s because, at enterprise companies, you’ll likely have some really smart people working with you who you can go to with a problem and the shape of the solution.

They can help you get there better than an article in an SEO publication could. 

Getting things done at an enterprise level is less about the “what” and more about the “how.”

So use these guidelines to get your “how” for improving the site speed of your JavaScript-based website, and the “what” will come much more smoothly.