That's how most of the world's population will experience your site.
I'm baffled that so many sites have invested in multiple megabytes of JavaScript to render their pages. It's like our entire industry has forgotten how to build sites that can be used by anyone who's not on an LTE iPhone.
Unless you're FAANG you probably don't care about most of the world's population, but the tiny slice that is most likely to see your site and generate revenue for you.
It's not baffling that most developers don't make things for most people. That's just a waste of time and money.
That is simply not true for pretty much most companies in existence. Also those users will still be mostly using phones that are significantly slower than iPhone.
> It's not baffling that most developers don't make things for most people. That's just a waste of time and money.
Empirical proof shows that most web developers make things for other web developers (optimizing for 4000$ MacBooks and 1000$ iPhones while forgetting that poor LTE signal areas exist) instead of making it for targeting your actual companies user reach.
(Remember, people who don't return on your slow loading JS bloated web site do not appear on simple dumb Google Analytics.)
For my company, we serve images and video. Even multi megabyte JavaScript only equals one minute of a 720p videos runtime.
For people on restricted connections, we have a lite versions with less than 100k JavaScript and videos transcoded to 260p.
On the one hand google promotes SPA frameworks. on the other hand , google makes AMP because they are too slow. It's not stated often enough, but modern web is schizophrenic
Most sites/apps don't work at all at this speed with the notable exception of Hacker News and Facebook Messenger.
Why is React superior to Razor Templates (or for that matter, Razor pages) for server side templating?
I support the assertion that it’s a good paradigm for creating consumable SSR templates I just don’t see anything that empirically cuts it above Razor other than if you know JSX/JavaScript it’s obviously more natural but I’m assuming that’s taken for account here
If you don't want to dig too deep though, compare how to add a datepicker to a view in both systems. With React it is just another component, with Razor it is a bit more finicky.
With the react app there's a chance I'll have the js already cached and I'm only fetching the data. With the SSR I'll probably be fetching data and view continuously.
People keep asserting it’s impossible to do all of the stuff we were doing on a daily basis in 2012, without the magic of megabytes of client-side code.
That's right, I am loading the same sites again every day consuming different data. Both for work and fun. That was the whole point.
Just not true. We test all your react sites with $100 Android phones. They render them all fine and fast.
There's some good write up here: https://medium.com/@benjburkholder/javascript-seo-server-sid...
Essentially content that requires client side rendering gets stuck waiting for Google to have resources available to render the content, which is likely scaled to keep the queue at what _they_ determine to be a reasonable length. That can mean a lag of up to days or weeks after the page was first touched before they have the content indexed and in SEO. Worse, search engines don't cache javascript the same way that your end users do. An end user returning to your site likely has all your javascript pre-cached ready to go. A search engine will be starting from scratch each time. That's a lot more requests hitting your server (vs server-side rendering) and so a slower page response time (which impacts SEO rank)
My first gut instinct to this hybrid SSR-CSR approach in the article was that it's nasty, but I really like the trade-off they hit. That's a really nice failure mode. Something happening on the client side is way better than nothing, even if that something is slow.
On a side note, server-side rendering is almost certainly more efficient overall. When running under a JIT environment, methods will have already been compiled down to native code. The code is likely already in memory and ready to execute so there is no parsing / compilation time involved (and you have the advantage of OS level caching, cpu caches etc on your side). The server CPU is almost certainly faster than the client's CPU and will be more likely to be in an awake state (there is measurable latency in a CPU waking from any of the sleep or lower power/frequency states). You're trading off once-per-server parse/compilation phase vs one-per-client-per-access.
SEO: If you don't server-side render your website, your SEO will certainly suffer. Google says they execute your JS, and to some extent they do, but your ranking will be worse and fewer pages will be scraped. We experienced this first hand.
Perf: User will stare at a blank page while they wait for your JS to download and execute. On a slow connection this could be many seconds slower than SSR.
If you have 5 pages that take seconds to render you might be fine, if you have 100k pages that take 50ms to render you might be in trouble.
Some of the detail of this is exposed in the webmaster tools that Google provide.
For example, copying a route from your SPA and pasting it into Twitter, Facebook, Slack, Teams, etc. Preferably you want the copied page's title, description and icon and not just your SPA's generic info.
Technologies used outside of their context and "developers" having to deal with complex problems they should not even have in the first place.
The benefit of that is getting all the effects of 'just plain HTML' while still being able to dynamically update parts of the page, and doing the entire thing in a single framework such that (if you do it right) your code doesn't have to explicitly do anything to specially handle the two different use cases.
A case of vital context missing. Ever tried something like Next.js? It's a react framework for client + server-side rendering. What's really cool about it is that it does SSR for the initial view and the client-side react picks it up from there. It doesn't sound very impressive like that but where it blew my mind was when I realized that I could save URLs for some deeply nested view in a react site, enter that URL later and I'd get an instantaneous SSR'd view seamlessly.
I guess what I'm trying to say is that some tech is cool like that, not really a contingency plan but a plan.
Especially when server-side rendering is so easy nowadays if you pick the correct stack.
(normally server-side rendering first-page loads faster because it is pre-rendered (and often cached) ).
>"... SEO was a very important consideration — we had full-time SEO consultants on staff — and we wanted to provide the best possible page load speed, so server-side rendering quickly became a requirement. ..."
Yes: when the user's browser is under high load.
> when the server is under high load, skip the server-side render, and force the browser to perform the initial render.
With this type of contingency plan, I don't see any reason to use server-side rendering at all. We build all of our sites and apps with React and don't do it at all, for any reason at this time.
Is there something we're missing?