Remove article on SSR with puppeteer?

[jakearchibald]

Page Affected: https://developers.google.com/web/tools/puppeteer/articles/ssr

What needs to be done? Delete it?

I don't think we should be recommending that people run headless Chrome on the server. It means that TTFB is blocked on Chrome spinning up a tab (which may include starting Chrome itself), fetching all assets on the page, parsing CSS, decoding images, running JS, then waiting for network to be idle for 500ms.

I've been contacted by developers who are seriously considering doing this with 100s of pages per second.

The article discusses caching the result, but the technique is then much more suited to a static build, or something that happens when an article is posted.

I tried adding warnings to the article, but I think it's better to remove it, and perhaps write a guide on how puppeteer could be used as part of a build system.

[jamiebuilds]

fetching all assets on the page, parsing CSS, decoding images, running JS, then waiting for network to be idle for 500ms.

That's not the case, the article itself shows how to block any unnecessary requests.

// 1. Intercept network requests.
await page.setRequestInterception(true);

page.on('request', req => {
  // 2. Ignore requests for resources that don't produce DOM
  // (images, stylesheets, media).
  const whitelist = ['document', 'script', 'xhr', 'fetch'];
  if (!whitelist.includes(req.resourceType())) {
    return req.abort();
  }

  // 3. Pass through all other requests.
  req.continue();
});

The article doesn't go into many of the optimizations that you could do past all of that as well. Like

blocked on Chrome spinning up a tab

You can have a pool of tabs already opened, you can even avoid navigation by just replacing the HTML within them.

waiting for network to be idle for 500ms.

It's very easy to adjust this, and build in timeouts such that the page races to render as much as possible before a timeout and then returns a snapshot of whatever it was able to do.

I've been contacted by developers who are seriously considering doing this with 100s of pages per second.

Also, this count is exaggerated for whatever reason. It isn't based on a real metric, and doesn't account for things like cached pages, client-side navigation, and statically rendered pages.

So the statement "I've been contacted by developers who are seriously considering doing this with 100s of pages per second." isn't the case, and is missing a great deal of context. This article from @ebidel was very helpful, and has valid and valuable real world use cases.

[jakearchibald]

The 100s of times a second figure was given to me by someone working on a site that has that kind of traffic, and since it includes data for a logged in user caching is not an option.

I don't have evidence that this is false, or an exaggeration. Do you?

I agree there are optimisations that aren't in the article.

An article aimed at using puppeteer as part of a build process would introduce developers to the tooling and benefits without the issues we have both mentioned.

[jamiekyle-eb]

I don't have evidence that this is false, or an exaggeration. Do you?

I do, I'm the one proposing we do this. And while there are 100s of requests a second, it's not to the pages that I am proposing we SSR with Puppeteer, and caching is an option even for those logged in pages.

I'm not sure why it's been communicated this way. But I'll follow up with my colleagues.

[jakearchibald]

Let me know what the conclusion is.

If this article was about using puppeteer as part of a static build, would it have been significantly less useful to you?

[jamiebuilds]

I would also really appreciate an article about statically building pages, but if I can contribute to this post, I would like to add even more detail around server-side rendering specifically.

[jakearchibald]

It feels like using puppeteer in real time on the server is worse than jsdom, which is worse than string rendering functions that most frameworks already have. It isn't an approach we'd want developers to use unless the alternatives weren't possible.

An article about using puppeteer like this should come with heavy warnings and justification, which it currently doesn't. I started trying to add these, but I ended up adding so many warnings throughout the article it seemed pretty pointless.

An article on static rendering would cover the same grounds in terms of features, but wouldn't need as many warnings and workarounds. Then, an article on using puppeteer on the server could build on this, adding the extra considerations.

Any insight into how to make puppeteer work like this at scale would be welcome. My main problem with the article right now is it's an experiment that reads like real world guidance. But, if it can be shown to work in the real world, that changes things.

PRs against the post are welcome, but I still think it should be a post that builds upon a static building post.

[jamiebuilds]

When we're comparing against real-time rendering via SSR with jsdom or framework functionality, there isn't as huge of a difference doing the same with puppeteer.

It's mostly the same JavaScript code, which in both cases is being executed in V8. Of course that still leaves a lot of overhead, but when you address each bit of overhead piece by piece, the vast majority of it can be eliminated.

Whether you're SSR-ing with Node or Chromium, both cases would still benefit greatly from many of the same optimizations. Maybe that in itself should be a blog post here (which I'd also be happy to contribute to).

Maybe the warnings and best practices warrant more than just a single blog post. I see that Google has also built Rendertron which seems to be trying to fill the same place.

Maybe a library is a better fit for guiding people on how to correctly use Puppeteer for SSR. Expanding the functionality there, doubling down on optimization strategies, and writing about how appropriately use it (in a way that scales reasonably well) would be a better resource for the web community.

[jakearchibald]

Yeah, puppeteer with workarounds isn't too far apart from jsdom (except memory usage), but avoiding the need for workarounds makes it a better choice, unless you run into a compat issue with jsdom.

Rendertron only does it's thing when it detects a non-Google bot UA. This isn't clear from the docs at all 🙁.

A library built on top of puppeteer specifically for general SSR seems like a good idea, especially if it's similar to jsdom per request.

[jamiebuilds]

I'll experiment with building a library for it

[ebidel]

FWIW, I've had a lot of devs ask me how to use headless to render 100s of pages. It would be great to have guidance for them. Whether you should do realtime SSR using headless chrome is another question. I also recommend reaching out to some folks using headless chrome at scale (e.g. https://www.browserless.io/) if you want to capture solid guidance from their learnings.

A big "caution" box at the top of the article would probably suffice. Or mention that pages should be processed "offline", similar to what is done in this handler on a cron job. The setup ca still live on a web server.

The intention of the article was to demo that headless chrome is a solution for SSR a js-heavy app, with better fidelity than jsdom, utilizing all of Chrome's features (devtools network manipulation, etc.), while getting rid of some other tooling like Gulp for preprocessing. At a smaller scale it does work well and requires zero-to-no config/setup). The realtime-ness should be downplayed as it's the least interesting part.

I don't think we should be recommending that people run headless Chrome on the server. It means that TTFB is blocked on Chrome spinning up a tab (which may include starting Chrome itself), fetching all assets on the page, parsing CSS, decoding images, running JS, then waiting for network to be idle for 500ms.

This is only the case if pages aren't in the cache or have been processed already. https://devwebfeed.appspot.com/ssr gets 99/100 on LH perf :)

[jamiebuilds]

Prerendering at build time with Puppeteer is really great if you are able to do it, but if you're in a scenario where there are too many unique pages (thousands, millions, etc) or that update as data changes, then rendering "lazily" (at first request) is the only realistic option.

It's also really difficult to get an engineering org of dozens or hundreds of engineers to regularly support both a browser environment and node environment (including with jsdom in place). There's always one environment that ends up suffering. You might run all your test suites in both places, but developers still all work in a browser and things slip through.

There's also the problem that engineers have a lot more difficulty trying to optimize their pages when they have to take SSR into account. Often people will create unique SSR bundles that bundle modules differently. For example, often people will bundle their apps without any code splitting for SSR. Which was a common problem I heard from my work on react-loadable which tries to send down all the relevant bundles for a page at once by recording what happened during SSR.

I think that by putting a full browser on the server that we can greatly simplify these and many other problems around SSR. I think that the performance problems of doing that can be mitigated.

[jakearchibald]

That's my problem with the direction of the article. To hit decent performance, users need to be hitting the cache. If the user has a high chance of hitting the cache, it suggests you have a relatively small number of pages. In this case, you'd be better off generating the pages at build time, so you don't have the complexity of running Chrome on the server, and no users hit the slow path.

If you've got thousands/millions of pages, then users are less likely to hit the cache, and performance suffers.

Often people will create unique SSR bundles that bundle modules differently.

In theory it should be cheap and easy to create a second bundle that's only different by one module: export const SSR = true. But current build tools don't make this particularly easy.

[ebidel]

To hit decent performance, users need to be hitting the cache

That isn't unique to running headless in the cloud. Hitting caches (at all layers) is necessarily to deliver good backend/server performance. e.g. cold start of a cloud function, memcache connection/perf, long db query, cdn and lack of cache headers, file I/O, user lookups/auth, merging responses from microservices.

and no users hit the slow path

Definitely want a better caching strategy than the in-memory soln I show in the article. That said, users don't hit a slow path if you do either of these:

1. precache pages offline (@jakearchibal 's suggestion)
2. Hit the page handler(s) when the server starts, warming the cache for the relevant pages (what that demo does).

I'd argue that 1.) is actually more work than running headless in the cloud b/c it requires setup separate tooling to upload/manage/serve the generated pages alongside the normal app. Perhaps even another pipeline/workflow.

In the case where a real user does get a cache miss:
An app like https://devwebfeed.appspot.com/ssr?nocache shows still achieves 98/100 on LH for that single user. Of course, all subsequent real users get a cache hit!