Many SEO professionals rely on “best practices” in their SEO efforts.
But when you’re optimizing JavaScript-based business websites for site speed, you need more than “best practices.”
Here’s why standard solutions don’t always apply to enterprise sites and what you can do instead.
Improve site speed: Migrating to server-side rendering isn’t always the right answer
Imagine going to the CEO (or anyone in upper management) and advising him, “We need to switch our website to server-side rendering (SSR).”
They ask you, “Why?” and the only answer you can give them is, “Because it’s a best practice to improve site speed.” You will probably 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 a business website is being built from the ground up to be rendered on the server or is already going through a website migration, there is rarely a reason to migrate to SSR.
Consider some of the soft and hard costs this would entail:
Review all systems and APIs to confirm compatibility, which is likely undocumented (probably hundreds, if not thousands). Thousands of man-hours to refactor, monitor and review accessibility for the entire website. Training existing staff on the new framework (tens, if not hundreds, of people across the organization). Hire or fire developers and engineers who are unwilling or unable to meet the specifications of the new framework. More money spent on server fees.
Instead of enduring such a long and resource-intensive process, there are other more successful ways to improve the speed of business websites.
In a previous business role, I discussed this very scenario with one of our senior systems engineers for fun.
We estimated that the company would need a year and a half, a dedicated agile tribe (typically around 70 people) and at least $2 million (AUD) to do this. And that was probably a conservative estimate.
So what do we do moving forward?
Get to know your other teams and help them out
At the business level, SEO needs to be a chameleon because you rely on other teams to prioritize and do your work for you.
There’s a good reason why you don’t have the keys to the kingdom to make changes to the live website. So SEO is not 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 in my podcast, Engage: On Enterprise SEO.
It pretty much sums up life as an SEO company.
You need to spend a lot of time listening and paying attention to what others are doing and then showing them how what they are doing has improved the website’s organic visibility.
Build advocates, and those people will keep coming back to you with a constant report of what they’re doing and changing on the website. That’s half the battle.
The second half involves working with developers, designers, and analysts to get things done. This is usually much easier when you realize that people are people with their own thoughts, feelings and goals.
Being a curious person who wants to help them make their life easier is a batch more attractive than working with a bull in a china shop who comes into your life every few weeks and makes no-holds-barred demands.
Work with developers and producers
In many businesses today, site speed is a known factor that helps (or hinders) conversion rates.
Many in-house development teams probably have site speed as a KPI. touch it
You’re both looking for the same thing, and your developers will know the codebase better than you. And if it’s done right, you can both walk away with a bonus.
Some of the common site speed opportunities I’ve come across that developers can help you with include:
Code size/weight
If your teams have sprints or tech debt assignments, keeping track of when they typically do this work can help you understand the impacts of their refactoring.
Reflect on them and recognize their effort.
Image loading and cumulative layout change (CLS)
CLS can be a major factor in the perceived load time of large JS-based business websites. Depending on how it is applied, using a Placeholder JS library effectively “holding” the position of images can reduce perceived page load time by not moving the page when images are loaded.
Management of redirects
This wasn’t something I could make ground on because our redirect management was so fragmented.
However, if your system is a little more centralized, handling redirects, removing jumps, consolidating rules into regex, and improving that technical debt could help a lot.
With some server deployments, each redirect rule must be read before the page can load, and this can add a decent amount of time (over milliseconds) to the initial load time.
This one is a little more nuanced, but I’ve often found that JS developers include ahref links as buttons by default.
This is usually because they don’t have time, and it’s a native default of the framework they’re working on.
When I was doing QA for new page templates, I often flagged it for updates .
Get the daily search newsletter marketers trust.
Work with designers
One of the biggest opportunities for site speed on business websites is image size and weight.
Internal standards can be mistranslated or lost over time, especially when teams are agile and somewhat decentralized.
When I first started at the company, I remember seeing 10MB images on the product pages of some of our flagship products. It surprised me.
No image should be 10MB on the web. Point.
So I had some delicate conversations with our designers and worked with them to reduce the size of our images for about 8 months.
100KB wasn’t a hill I was willing to die on, so if I told a designer 100KB for a header banner or a frame, and they get it to 300KB, that’s still an improvement.
Business SEO is often about incremental wins.
Work with analysts
Analysts enter the conversation because they will likely manage your tagging systems and all third-party tags on your website.
They are the entry point for conversations with tag owners about whether or not that particular tag is critical or if there is an alternative.
Because, boy, third-party scripts can cause massive website bloat.
So while you’re having conversations about the 250+ ad scripts on the site and whether we need them all, you may be able to find some short-term compromises, such as:
HotJar, Fullstory, or other user experience monitoring script is only triggered on pages that are being heat mapped or tracked. Audit your deployments for duplicates (happens more than you think). See which chatbot or customer service tags can be launched on click instead of when the page loads.
Working with the quality control team
This partnership could be a secret weapon for you. SEO in general, but also JavaScript SEO, have many binary yes/no requirements or best practices, such as:
The metadata must be the same between the page source and the client-side rendered page. Canonical must be present on the client-side rendered page. Links must have the format instead of
Preload fonts Pre-connect to great resources
Introduce the good books to your QA team and work with them (including training) to include them as part of their overall, day-to-day QA process. You’ll have eyes everywhere and a potentially massive network of micro-lawyers.
While there are many other teams you could work with to improve your website’s overall SEO, these are likely the ones you’ll be working with the most when it comes to the more technical part of implementation.
Defend other teams you work with
Remember what I said earlier about working with people when you remember they are people? You want to put it into action.
There are two really strong ways to do this at the enterprise level.
Respect their time
Let’s say you have a great idea, like “we should migrate to server-side rendering.”
In this case, instead of going to the command office and saying, “Hey, can we do all this?”, work with them to create a proof of concept that they’ve validated drops in the “easy” bucket and do monitoring its impact. .
If it doesn’t work, they haven’t essentially wasted 20 sprints doing this massive project.
If it works, you have a business case to take to the finance team to fund and prioritize the rest of the project to bring it to the whole website and get that dedicated tribe, $2 million and a year and a half to do- it .
Expand your effort
Something SEOs are notoriously bad at communicate and share success.
It might be a little easier if, instead of saying, “look at this fabulous thing I’ve done,” you position it as, “look at this amazing thing this other team that I’ve worked closely with has done and here’s how it’s gotten better very much our experience on site.”
You, the SEO, are no longer the center of attention. The team that did the real work is.
Collaboration, defense and incremental wins
You might notice that I haven’t actually talked too much about the nuance of JavaScript and site speed in this article.
This is because, in enterprise companies, you will likely have very smart people working with you who you can go to with a problem and how to solve it.
They can help you get there better than an article in an SEO post.
Getting things done at the business level is less about the “what” and more about the “how.”
So, use these guidelines to get your “how” to improve the speed of your JavaScript-based website, and the “what” will be much easier.
The views expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.
[ad_2]
Source link
