Idle idle water article series

Note: This article is just to briefly explain what SSR and preRender do for SEO. Again, the choice depends on the current business, time cost, and familiarity with the technology

preface

A few days ago, in dealing with low code at the same time took over a to do SEO official website. The technical stack of the official website was put up by me with VUE. As we all know, for modern JS framework, the first thing to do SEO is to make spiders climb all the content on your page.

How do you deal with that?

Two more traditional schemes

  • Do the SSR
  • Do the pre-rendered

Since IT was the first time I had come into contact with this kind of thing, and my dear boss had run away, I began to tinker with it myself. It’s a lot of digging, so I’ve tried both of the main solutions.

First of all, let’s talk about the popular SSR. SSR is actually relatively simple, because both React and Vue have a corresponding to next or Nuxt (of course, there is also an open source egg that does quite well).

Here’s how it works: Take spa React as an example. The app root component is converted into AN HTML string on the server side and passed to the browser (for example, renderToString under the React-DOM /server method). Of course the server cannot bind events, and there is code to maintain a client at the same time. Then handle the inconsistency of store data on the client and server (dehydration and water injection).

Although a closer look seems to be a lot of things, but to say the main is to put the HTML generated in the server to return, and SSR wheels are also very mature. It’s got wheels. It’s done. But it seems that pre-rendering is not as well known. For this article we’re going to play with pre-render.

Principles of pre-rendering

1. Use a pre-render server (crawler application)

First, when the project is not processed

The basic flow of the project without any processing is as follows (figure below). The client accesses index.html and the server returns.

This is the HTML that you get when you’re not doing any processing

In this case, the browser must parse the JS first. Then the corresponding DOM can be attached to the div with the id of root, the browser completes the rendering, and the page is displayed

But the spider doesn’t look at the result of the JS execution. What it sees is a skeleton with no information.

Get him a pre-render server

The react server can be used to determine whether the react server is a spider.

If ordinary users access, there is no need to process it. If it’s a spider visit, go to the pre-render server

What’s the main thing going on in this pre-render?

Basically, it simulates this operation

Something like this: when we F12, the stuff in the element palette is already after chunkJS has been executed. So is it possible to send a copy of this HTML back to the spider?

I wonder if you are a little curious about how the prerender server works.

But it is a pity that xiaobai did not spend energy on it. So I did not have a specific look at its implementation ideas, but small white here to provide my own idea

Following the above simulation, it seems that we can adopt the idea of crawler. Here I will simply use Puppeteer to implement the above framework

Step 1: Start a react project using crA

At this point, of course, the page is rendered on the client side, so you can’t see any main content in the source code (such as Learn React).

Step 2: Set up our pre-render server (of course, using the node that the front-end is most familiar with)

You can see that a new Pup_server has been opened

Because it’s a simple imitation, then we can do it. Open a browser and another page to open the React project (assuming port 3000). And then I’m going to crawl and get a copy of the code

The core code is as follows


const puppeteer = require('puppeteer')
const fs = require('fs')

const start = async() = > {const browser = await puppeteer.launch({
        headless: false,})const page = await browser.newPage();
    await page.goto('http://localhost:3000/', { timeout: 20000 });
    const html = await page.content()
    fs.writeFileSync('index.html', html)
}

start()
Copy the code

If you open the HTML copy, you can see that it already has content.

Previewing this file seems to be a bit of a problem, but it is only for spiders, we do not cure the view effect

If you’re interested, take a look at this Prerender as well

2. Again, use the prerender-SPa-plugin

To be honest, the above architecture is a bit complicated. Here webpack provides a plug-in prerender-spa-plugin. The principle is still the same.

First use this thing for general SPA projects, which requires that your routing mode be history. Because it has to be packaged according to the route. What does that mean?

Take a look at the typed directory structure

For a brief introduction, there are four routes in my project, namely about Index intro Study

The original normally typed package does not have these four folders. What are the extra four folders here? And with that foundation we can figure it out pretty quickly. This is after the completion of the original SPA package construction, he made a simulation browser, open the corresponding route page to get the source code copy out, and then in turn in the folder named by each route

And you can see that under these folders, they’re all HTML that’s been copied. This is for spiders. From the user’s point of view, there are no changes, starting with the root index.html. It’s the same process as before. Just a few things that need to be given to spiders for SEO

What’s the difference between SSR and preRender?

Ideologically:

What is the main contradiction of modern framework to do SEO first?

A: Because the framework’s main content area is now dom (

). It just needs the browser to execute JS to create and mount it, but the spider just can’t get it.

For this question

SSR thought: well, you can’t get it, so I’ll send you HTML on the server.

PreRender thinks that a client has two roles, one as a normal user and the other as a spider. Just you spider can not get is, that I think method give you spider want, user that logic I do not move.

Which one to use? It depends on the current business, but also on their respective weaknesses, right?

For example, the common problem of SPA projects is the slow first screen. At this time, you not only dealt with SEO but also dealt with the first screen with SSR

However, your boss suddenly gives you a day or two to do SEO on a project you are completely unfamiliar with his business. You can’t just take it and start migrating it to next or NuxT.

Good today to have a meal first, this first simple thought. Later, when you have a chance to sort out another article…