Ask HN: Why does Google use server side rendering for search results? | Hacker News Reader

Ask HN: Why does Google use server side rendering for search results?

17 pointssam0x1715 comments

I've been wondering this for a while.

My thought is that search results could be rendered faster using an SPA-style setup as the rest of the page wouldn't have to be reloaded, yet Google Search still uses server side rendering on their results in 2020.

Is there any particular technical reason they are doing this?

My thoughts on possible reasons are:

* they want to support browsers that have JavaScript disabled and/or older browsers / TOR

* legacy reasons -- their whole infrastructure is designed to deliver results via server side rendering and it would be a pain to change it

* they are in general afraid to make sweeping changes to google search (don't fix what isn't broken)

* some interesting technical advantage of server side rendering in this scenario over client side rendering that I am unaware of but would be curious to learn about

View on HN

Because it's faster! Which one do you think will render first?

- Send a small amount of HTML and CSS for the browser to show on the page; or

- Send a JavaScript application framework and JSON results, then have the browser interpret the JavaScript, parse the JSON, generate the HTML and show on the page

With an approach like Svelte takes, you can make the second option pretty workable, but you'll still never beat sending markup directly if your goal is to render a small amount of static content as quickly as possible.

The average Google user is more likely to be someone running Microsoft Edge on a 6-year-old cheap PC, than Chrome on a 1-year old Macbook. An SPA requires the front-end do the heavy lifting, spinning up tons of Javascript. Server-side rendering means the browser doesn't have to do a lot of work -- just render the damn HTML, which is fast and efficient. Google results pages are not very hugely interactive compared to say Facebook, so it's better to keep the browser happy to make the page load quickly.

This makes a lot of sense to me. Still, I wonder if there is an additional advantage here in terms of being able to render results before the request is fully received -- is that even possible with AJAX?

With Ajax, definitely not, though I imagine some wizard will mention some mode where it can be done. Fundamentally, imagine if you started running code on partially downloaded JSON. Imagine an array of objects is partially downloaded, then the JSON is parsed, the code starts running, then suddenly more objects are added to the array later? That would be a runtime nightmare.

One issue is that they don't want to provide a well defined api to get search results. The last thing they want is for SEOs to practice the quantitative methods that they expect you to use for adsense.

Could you please elaborate on what you said? I have no idea what you are talking about so I want to learn

People who run online ads use A/B testing. You might ask them, "why do you use that yucky shade of green?" and they will laugh and tell you they tried a few different colors and that one got the most clicks and conversions.

If Google's ranking formula was deterministic, you could do the same thing for your search rankings. You could make changes to your page, see if your rankings get better or worse, and repeat.

If you try to do this you will find all sort of phenomena designed to gaslight you. For instance, one form of personalization is that if you click on a link that is lower down, it might move up. Well if you are always clicking on your own site it will rise higher in your rankings and you might think you've won, but really you've lost.

Other countermeasures are more conjectural, but looking from the outside I believe I've observed that Google uses randomness both on a day-to-day and a long-term basis, has different rules for sites in different parts of their lifecycles. It may be a superstition, but I have many sites that I haven't updated in years because it seems that changing a high-producing site is likely to make your site a low-producing site.

The last thing they want to do is provide an API that would make it easier to research what they do on a large scale.

People who work for Google will deny all that, but some of them are the gaslighters, while the rest are gaslit.

There is a huge industry devoted to knowing the patterns and logic behind google search to sell expertise around changing the results behind google search. A business would want this to ensure that they could be the first result when a potential customer searches for something that would indicate that they are ready to make a specific purchase that the business can handle. Politicians and other public figures would want to know how to make sure that given pages or topics do not show up like how some people theorize Boris Johnson does: https://kottke.org/19/10/boris-johnson-shady-seo-master

The issue with the industry around Search Engine optimization is that if commercial and marketing interests are too good at determining what get shown to a user, then Google loses it's value to a user. API's by design are machine readable, so if Google built its site in a way where other people can query this api directly, then marketing and PR firms would be able to query this api to build datasets on the relationships between different site, their content, and their pagerank to create rough models on how to 'game the system'. Instead by only offering a server-side rendered page for search, to collect the same information for data-mining purposes, you would need to 'scrape' the page and hope that format of the page's html is consistent for a long enough period to build a scraper, and then collect the data that they need. This combined with html and css obfuscation which is common with ssr apps and webpack in general, as well as rate-limiting and some other techniques, it can quickly become infeasible for somebody to data-mine google search for these kind of uses, and Google gets to keep their value.

First reason is the one that is most likely. There are many kinds of users on the WWW and they use many kinds of web browsers. So the only constant they all recognize is HTML and the only way to realize an application over the web that will be accessible to all those users, is by rendering it as HTML completely on the server.

Also, from technical point of view there is no point in generating JSON output (or any other format), and use that format by a JavaScript based processor to generate HTML, when you can directly generate HTML that will be as simple as the JSON. There are not many savings. Why?

3 results of a simplified query engine output in HTML: [DIV class="results"]

  [DIV class="result"] [DIV class="url"]URL[/DIV] [DIV class="description"]description[/DIV] [/DIV]

  [DIV class="result"] [DIV class="url"]URL[/DIV] [DIV class="description"]description[/DIV] [/DIV]

  [DIV class="result"] [DIV class="url"]URL[/DIV] [DIV class="description"]description[/DIV] [/DIV]

These results are usable as is, the browser will render them and does not need anything else to do it.

3 results of a simplified query engine output in JSON:

  "results": [
    {
      "url": "URL",
      "description": "DESCRIPTION"
    },
    {
      "url": "URL",
      "description": "DESCRIPTION"
    },
    {
      "url": "URL",
      "description": "DESCRIPTION"
    }
  ]

This output does not save much space. It is equally as complex on the server-side.

But this output is not usable by the user as will not be displayed in a usable form, so you need JavaScript code to process it and generate HTML that will be usable.

So why generate the same list of things two times? It is better, easier and more accessible for the user if you generate HTML the first time.

Just my opinion. This might not be the real reason.

I imagine most people pop a new page for every google search, reloading the whole page anyway.

Simple: it’s for SEO so that when google crawls the page it shows exactly as they want it indexed. Waaaaait a minute?!

It's because SPAs are a fad and server-side rendering is both faster and better for the client.

one theory I had -- I wonder if doing SSR makes it easier to emit results one by one as they come in vs. an AJAX request where normally you don't get anything until you have the whole response body. Thoughts?