search

jamstack / jamstack.org

The official Jamstack site
https://jamstack.org/
2.84k stars 638 forks source link

First page render performance? #55

Closed bluepnume closed 5 years ago

bluepnume commented 7 years ago

Hi all!

I was looking into this and it seems like server-side rendering is pretty much eschewed by JAMstack:

Any project that relies on a tight coupling between client and server is not built with the JAMstack. This would include:

A single page app that uses isomorphic rendering to build views on the server at runtime.

How do you reconcile this with the "Better Performance" claim on the JAMstack manifesto? Or is JAMstack not intended for sites with a lot of dynamic content on the first render?

Do you guys think it's possible to reconcile loosely-coupled client/server architectures, with server-side rendering? Maybe using some kind of thin layer to do the initial render but still expose all of the data via apis?

verythorough commented 7 years ago

Hi Daniel!

I hear you—I've always hated the idea of loading all page content via client-side javascript, and this method is often less performant than on-demand server-side rendering. The trouble with server rendering on the fly, though, is that it's limited to a single location, and can't be distributed over a CDN. This is usually solved by caching rendered views and distributing those, but once you're caching and distributing pre-built versions of previously visited pages, why not do this for the whole site at build time? It's interesting because you're still doing server-side rendering, you're just not doing it on the fly.

I'm guessing you were already thinking in this direction when you asked, "Is JAMstack not intended for sites with a lot of dynamic content on the first render?" To that, I guess I would ask: how much is a lot, and how dynamic are we talking about?

A fairly dynamic example that springs to mind is a Pinterest page of search results. They obviously can't generate all possible searches at build time, and the image-heavy content is bulkier than simple text (though the images and text can be loaded separately). The static chrome of the page, on the other hand, is quite minimal. However, it does get the whole process started. If the basic html frame, that also loads the site CSS, JS, icons, and fonts, is generated by a server in a single location, that part of the render is going to be slower (and in some locations, very significantly slower) than if it's pre-built and served on a global CDN. I guess in some ways this could fit into the idea of "some kind of thin layer to do the initial render" that you mention.

The pins themselves get trickier because without server-side rendering, they'll have to be loaded from a data API via client-side javascript. I think that determining the most effective strategies for this part is one of the major questions of current JAMstack development, and one where we'll have lots of interesting discussions and new solutions presented.

ghost commented 7 years ago

Maybe using some kind of thin layer to do the initial render but still expose all of the data via apis?

Very doable. It's called Hijax, better known today as Pjax.

PerrySetGo commented 5 years ago

If folks in this thread want to keep talking - great! I encourage you to pop over to community.netlify.com, our new discussion forum. I'm closing this as this is several years old at this point :)