{"id":22247,"date":"2022-12-09T13:55:22","date_gmt":"2022-12-09T13:55:22","guid":{"rendered":"https:\/\/mailinvest.blog\/index.php\/2022\/12\/09\/cautionary-tales-and-how-to-avoid-them\/"},"modified":"2022-12-09T13:55:22","modified_gmt":"2022-12-09T13:55:22","slug":"cautionary-tales-and-how-to-avoid-them","status":"publish","type":"post","link":"https:\/\/mailinvest.blog\/index.php\/2022\/12\/09\/cautionary-tales-and-how-to-avoid-them\/","title":{"rendered":"Cautionary tales and how to avoid them"},"content":{"rendered":"

<\/a>\n<\/p>\n

\n

I recently read Ziemek Bucko\u2019s fascinating article, Rendering Queue: Google Needs 9X More Time To Crawl JS Than HTML<\/a>, on the Onely blog.<\/p>\n

Bucko described a test they did showing significant delays by Googlebot following links in JavaScript-reliant pages compared to links in plain-text HTML.\u00a0<\/p>\n

While it isn\u2019t a good idea to rely on only one test like this, their experience matches up with my own. I have seen and supported many websites relying too much on JavaScript<\/a> (JS) to function properly. I expect I\u2019m not alone in that respect.<\/p>\n

My experience is that JavaScript-only content can take longer to get indexed compared to plain HTML.\u00a0<\/p>\n

I recall several instances of fielding phone calls and emails from frustrated clients asking why their stuff wasn\u2019t showing up in search results.\u00a0<\/p>\n

In all but one case, the challenge appeared to be because the pages were built on a JS-only or mostly JS platform.<\/p>\n

Before we go further, I want to clarify that this is not a \u201chit piece\u201d on JavaScript. JS is a valuable tool.\u00a0<\/p>\n

Like any tool, however, it\u2019s best used for tasks other tools cannot do. I\u2019m not against JS. I\u2019m against using it where it doesn\u2019t make sense.<\/p>\n

But there are other reasons to consider judiciously<\/strong> using JS instead of relying on it for everything.\u00a0<\/p>\n

Here are some tales from my experience to illustrate some of them.<\/p>\n

1. Text? What text?!<\/h2>\n

A site I supported was relaunched with an all-new design on a platform that relied heavily on JavaScript.\u00a0<\/p>\n

Within a week of the new site going live, organic search traffic plummeted to near zero, causing an understandable panic among the clients.<\/p>\n

A quick investigation revealed that besides the site being considerably slower (see the next tales), Google\u2019s live page test showed the pages to be blank.\u00a0<\/p>\n

My team did an evaluation and surmised that it would take Google some time to render the pages. After 2-3 more weeks, though, it was apparent that something else was going on.\u00a0<\/p>\n

I met with the site\u2019s lead developer to puzzle through what was happening. As part of our conversation, they shared their screen to show me what was happening on the back end.\u00a0<\/p>\n

That\u2019s when the \u201caha!\u201d moment hit. As the developer stepped through the code line by line in their console, I noticed that each page\u2019s text was loading outside the viewport using a line of CSS but was pulled into the visible frame by some JS.\u00a0<\/p>\n

This was intended to make for a fun animation effect where the text content \u201cslid\u201d into view. However, because the page rendered so slowly in the browser, the text was already in view when the page\u2019s content was finally displayed.\u00a0<\/p>\n

The actual slide-in effect was not visible to users. I guessed Google couldn\u2019t pick up on the slide-in effect and did not see the content.\u00a0<\/p>\n

Once that effect was removed and the site was recrawled, the traffic numbers started to recover.<\/p>\n

2. It\u2019s just too slow<\/h2>\n

This could be several tales, but I\u2019ll summarize several in one.\u00a0JS platforms like AngularJS and React are fantastic for rapidly developing applications, including websites.\u00a0<\/p>\n

They are well-suited for sites needing dynamic content. The challenge comes in when websites have a lot of static content that is dynamically driven.\u00a0<\/p>\n

Several pages on one website I evaluated scored very low in Google\u2019s PageSpeed Insights (PSI) tool.\u00a0<\/p>\n

As I dug into it using the Coverage report in Chrome\u2019s Developer Tools across those pages, I found that 90% of the downloaded JavaScript wasn\u2019t used, accounting for over 1MB of code.\u00a0<\/p>\n

When you examine this from the Core Web Vitals side, that accounted for nearly 8 seconds of blocking time as all the code has to be downloaded and run in the browser.\u00a0<\/p>\n

Talking to the development team, they pointed out that if they front-load all the JavaScript and CSS that will ever be needed on the site, it will make subsequent page visits all that much faster for visitors since the code will be in the browser caches.\u00a0<\/p>\n

While the former developer in me agreed with that concept, the SEO in me could not accept how Google\u2019s apparent negative perception of the site\u2019s user experience was likely to degrade traffic from organic search.\u00a0<\/p>\n

Unfortunately, in my experience, SEO often loses out to a lack of desire to change things once they have been launched.<\/p>\n

3. This is the slowest site ever!<\/h2>\n

Similar to the previous tale comes a site I recently reviewed that scored zero on Google\u2019s PSI. Up to that time, I\u2019d never seen a zero score before. Lots of twos, threes and a one, but never a zero.<\/p>\n

I\u2019ll give you three guesses about what happened to that site\u2019s traffic and conversions, and the first two don\u2019t count!<\/p>\n

\n

<\/p>\n

\n
\n
\n

Get the daily newsletter search marketers rely on.<\/p>\n<\/p><\/div>\n<\/p><\/div>\n<\/div>\n

<\/p>\n

\n

Sometimes, it’s more than just JavaScript<\/h2>\n

To be fair, excessive CSS, images that are far larger than needed, and autoplay video backgrounds can also slow download times and cause indexing issues. <\/p>\n

I wrote a bit about those in two previous articles:<\/p>\n

For example, in my second tale, the sites involved also tended to have excessive CSS that was not used on most pages.<\/p>\n

So, what is the SEO to do in these situations?<\/h2>\n

Solutions to problems like this involve close collaboration between SEO, development, and client or other business teams.\u00a0<\/p>\n

Building a coalition can be delicate and involves giving and taking. As an SEO practitioner, you must work out where compromises can and cannot be made and move accordingly.\u00a0<\/p>\n

Start from the beginning<\/h3>\n

It’s best to build SEO into a website from the start. Once a site is launched, changing or updating it to meet SEO requirements is much more complicated and expensive. <\/p>\n

Work to get involved in the website development process at the very beginning when requirements, specifications, and business goals are set.\u00a0<\/p>\n

Try to get search engine bots as user stories early in the process so teams can understand their unique quirks to help get content spidered indexed quickly and efficiently.\u00a0<\/p>\n

Be a teacher<\/h3>\n

Part of the process is education<\/a>. Developer teams often need to be informed about the importance of SEO, so you need to tell them.\u00a0<\/p>\n

Put your ego aside<\/a> and try to see things from the other teams’ perspectives.\u00a0<\/p>\n

Help them learn the importance of implementing SEO best practices while understanding their needs and finding a good balance between them.\u00a0<\/p>\n

Sometimes it’s helpful to hold a lunch-and-learn session and bring some food. Sharing a meal during discussions helps break down walls \u2013 and it doesn’t hurt as a bit of a bribe either.\u00a0<\/p>\n

Some of the most productive discussions I’ve had with developer teams have been over a few slices of pizza.<\/p>\n

For existing sites, get creative<\/h3>\n

You’ll have to get more creative if a site has already launched.\u00a0<\/p>\n

Frequently, the developer teams have moved on to other projects and may not have time to circle back and “fix” things that are working according to the requirements they received.\u00a0<\/p>\n

There is also a good chance that clients or business owners will not want to invest more money in another website project. This is especially true if the website in question was recently launched.<\/p>\n

One possible solution is server-side rendering. This offloads the client-side work and can speed things up significantly.\u00a0<\/p>\n

A variation of this is combining server-side rendering caching the plain-text HTML content. This can be an effective solution for static or semi-static content.\u00a0<\/p>\n

It also saves a lot of overhead on the server side because pages are rendered only when changes are made or on a regular schedule instead of each time the content is requested.<\/p>\n

Other alternatives that can help but may not totally solve speed challenges are minification and compression.\u00a0<\/p>\n

Minification removes the empty spaces between characters, making files smaller. GZIP compression can be used for downloaded JS and CSS files.<\/p>\n

Minification and compression don’t resolve blocking time challenges. But, at least they reduce the time needed to pull down the files themselves.<\/p>\n

Google and JavaScript indexing: What gives?<\/h2>\n

For a long time, I believed that at least part of the reason Google was slower in indexing JS content was the higher cost of processing it.\u00a0<\/p>\n

It seemed logical based on the way I’ve heard this described:\u00a0<\/p>\n