See the entire conversation

Removing client-side React.js (but keeping it on the server) resulted in a 50% performance improvement on our landing page
211 replies and sub-replies as of Oct 27 2017

And yes, we still ❤️ React and pre-fetch it to use on subsequent steps.
Unless I'm misunderstanding, I think an even greater performance gain might be had from not pre-fetching that which you don't need?
I'm curious: did you consider anything else, like Preact or Vue? Is it always a trade-off between convenience vs perf with frameworks/libs?
Great question. Yes, we considered preact, but for a simple page w/ low interactivity, using vanillaJS was simpler and easier wrt our stack
What's the breakdown of where time was saved? Download size? Amount of script to parse and evaluate?
would be curious to hear a bit more about this too! There's usually a threshold where the weight of preact gets offset by smaller components
primarily download size. we didn't directly measure script parsing time, but 270 vs 35kb of JS ought to be a lot quicker to parse
What about pages with high interactivity?
Curious what you mean by still use it on the server. As a replacement for a templating engine like jade?
For this landing page, you might think of it that way. We just stopped sending React down to the client
Plus Jade is actually quite slow
Thanks, appreciate the response.
Just to be this for your homepage? and anything interactive (login, CTA etc.) is handled by React?
Did you consider not using JavaScript when it's not needed? Landing pages need mostly HTML, JS is for additional shininess. Max performance!
is there a link to the slide deck or a recording of the talk?
Where can I watch this talk?
Will watch this one tonight. Will put this on must watch.
yassssss. Thank you!
everyone keeps talking about this PlainJS framework, guess I need to learn it. is it on @npmjs? is available... just saying :D
Did you guys know the framework VanillaJS ?
All the cool kids are using ASI.js 😎
OMG! Opportunity knocks only once
Nop, is not available. Someone registered it yesterday. Pretty fast :)
Classic lol
Careful with jokes like that... over half of the community will take you seriously because they don't know any better
There is no much dynamic content on Home page so it is a good choice but what was the initial thought for using react for homepage
That's awesome! Congrats :D
Is there a recorded version of this talk?
Does "keep it on the server" mean "server-side rendering"~?? 🤓
It means they kept some unused React files on the server. (No really, what does it mean? Node?)
Server side rendering using Node 😃
I have done exact same thing in my one set-up.
50% meaning what exactly? From 2ms -> 1ms or 10s -> 5s?
Depends on CPU, network (latency and bandwidth), but it’s probably in the 5–10s ballpark on bad conditions, 1–2s on excellent network.
I have no knowledge of Netflix’s numbers here, but with DNS resolution, TLS handshake, getting HTML, *then* getting sub-resources, and …
… network latencies from 30ms up to 400ms, the lowest numbers for TTI will be in hundreds of ms (and unlikely to ever get <500ms).
Not sure I’ve ever seen TTI < 1000ms. Even if you load the JS inlined in the HTML, parsing/running time can take some more hundreds of ms.
For instance in this test, it took a bit more than 1100ms to get an interactive page:…
My local test on desktop (good CPU) + broadband + Firefox got me ~900ms for an interactive page.
agree have not seen either with react stack, though it's possible… mentioned here
Hacker News readers as Progressive Web Apps
only insane TTI ive seen used webworkers lol
You're forgetting HTTP2.
From what I've read, unless you server-push your CSS and JS with the HTML, the impact on TTI will be limited.
Luckily server push is starting to get easier, Netflix probably does it already (too lazy to check).
Plain javascript Will always be faster than any framework. But you need to better organize it.
Ok, but to be clear, we're talking about a page with a couple of buttons and some images right?
Here's the clincher:
And yes, we still ❤️ React and pre-fetch it to use on subsequent steps.
Make sense if you have a ~static landing page in front of a react app, to render the static part first and then the react part afterwards.
lol, so the TL;DR: "Used React on the client to build a static website and it was faster to use an actual static website" ?
Makes sense! What would you use react to build something like this in a first place!
When you have a hammer...
The page had also already been created in React so it was quick not to recreate the page and just remove client side React
Seems about right. No surprise there.
They basically improved their landing page load time to get a little head start so they can pre-fetch the rest of the application in the background.
I get it. The static stuff all loads react-free so that the react part can load afterwards while there's stuff on the page.
Next on our programming: "how using server side templates made our day" and "How we made it fly using a custom CSS extension" :-p
Why not appcache your landing page? Then you will see some real improvements!
Do you somehow compile the JS from .jsx files to a vanilla JS file? Or did you just write the vanilla JS and include it?
Nah nothing so fancy. We render the UI on the server w/ React & ship it to the client. client-side interactivity is handled using plain JS
Got it, that's what I figured. Thanks!
What tools do you use to do SSR ? Have you looked at something like next.js or is this something custom built.
I would call this technique "Universal" or "Isomorphic". What do you think? 🤔
I would love to see some code examples.
until do you need this kind of optimization, do you have run a long way building your business and platform. BTW it's a very good insight!
I'd like to see the rest of the slides, because this sounds like people inventing warm water.
Anyone has these slides, pls?
Hmmmm, let's wonder why! :D
Huh. How do you handle events on the site then? Is it just downcompiled to straight JS, like svelte?
When they drop it from servers it will be 50% more.
There are 2 buttons, text and a logo on the landingpage :D How can you manage the complex state of this elements without flux :DD
we are talking about frontend not backend
I think that was sarcasm 😐
If you are talking about my comment, you are being too generous ;)
Is there a video for this talk about removing react and improving TTI? Specially in web, context is key to get to understand why it worked
Now remove it on the server and you'll be even faster than that. Along with using FreeBSD as your video server, shows you are pretty smart!
Landing page only? Or the entire app?
Landing page only
(No comment)
Qual seja o front deles então?!
here we go again
TL;DR increased performance by removing a chunk of code/initial payload. That is nothing new :/
ReactJS and all other equivalents that rely on SS JS, slow and clunky? NEVER... 🙄
can y'all share some traces? I am curious what the primary cost was. cc @_jayphelps
i've asked yesterday about "Why not Service Workers" but didn't get an answer. Does anyone have info why not caching via SW?
I love service works but the lack of support right now on Safari makes it not as compelling on our side.
I agree. It's under development (…) and can be used with XHR fallback ie use SW or fallback to XHR caching.
that's just an idea, i use SW and happy with manual cache control. So i'm not relying on browser cache algorithms but make sure it works
not 100% sure what you mean, can you elaborate a bit so I can better answer?
Just for a landing page there's no need for a framework. But if we speak about a powerful web app I think @reactjs is the better choice.
welll...yeah, this is something i would completely expect.
why did you even choose React for the landing page at the first place ^_^
Not having been at the conf - you mean server-side render + react late-loading into the pages, or "no react at all in the client"?
No react on the client for landing page only. Other pages have React. We prefetch resources used by those pages
What kind of clients are we talking about here? Are TVs & STBs included? Phones? Computers only?
Web only. We’re doing lots of other stuff to optimize perf on other platforms
Why the hell were you using react on a landing page ? oO
Did you compare the hydration improvements in 16.x (~3x server speedup too!) to having no React? I'd expect a similar speedup
Now please give us a way to turn off autoplay.
These metrics never define what "interactive" actually means. Are links still handled in the same scope or do they trigger a request?
TTI = domInteractive - requestStart (both from window.performance.timing)
You guys should as add an engineering channel to your app 🤓
Can you share some actual numbers (averages) and not just a %? %'s can be misleading (many times on purpose....)
A TTI reduction from 200ms to 100ms vs 1 second to 500ms.... Both are 50% .... But one is much more meaningful than the other...
So you are talking about this page, right?
How long before we see "By getting rid of Javascript on the server, we saw a ..."
have you seen this yet?
Yup! Learned new things about win.perf. I've measured TTI manually before and damn was I overcomplicating it 😅. Their way is much easier lol
“…and moving to plain JavaScript”, I feel like this is a “duh” moment.
wow! haters gonna love that you got rid of “heavy React” from a page with two buttons and a bunch of images
React in a landing page? How do the search engines index that? I am not understanding this...
how do you install this plain javascript package? npm install plain-javascript?? sounds like a great framework
Para que mejores la velocidad @Alesonline
Now imagine removing all that sh*t from your workflow... :P
How's it different than SSR?
You server side render the React components but don’t load client side React
Is this drop in for vanilla react code ? Sounds like Gatsbyjs except on-the-fly
Just remove it all together for insane speed lol.
Imagine what you could do if you got rid of JS altogether. 😜
Indeed Web standards alyzs rocks
Use @polymer , it is native JavaScript.... no compiler needed.
what about @sveltejs 😄 it compiles to "plain js"
Interesting, actually makes sense!
Netflix: Let’s share the landing page stuff, it’s minor yet interesting Twitter: BLARGGGARGGARGARGARGARG
That’s a great idea! I’m a little afraid how much work it would take when your landing pages are not as simple. :(
Isn’t that basically just python?
Seriously though, did you even need the vanilla js? HTML5 and CSS3 now provide as more functionality than js did when it was introduced.
Mostly, no! We had only a few things that had to be rebuilt in plain JS. A few click handlers, and I had to re-roll clientside logging etc
Keep the hits coming - thank you!
Bad title lol
Jay, why do you hate React??
me lo explicas?? XD
how does this actually work? Express server in the back end that only pushes HTML plus another JS file?
So interesting, today we'll be talking about #reactjs at Vocento, lets see what UI team have to say about that :D
Where can I watch this talk please?
Removing JS all together and having static html would improve it even more :)
ever heard of static webpage ?
Not sure why people are so offended, but seeing some numbers would be cool ¯\_(ツ)_/¯
You could potentially invest in your own JS framework, considering the big impact and needs of your platform
performance wise, in what regard, speed ?
Now imagine if you'd remove it from the server as well how much faster it would be :)
I'm happy to help with that removal process :)
React is pretty bloated, look into as an alternative. The idea is saving development time rather than being fast
That's a thing with frameworks ., it's the framework which has the control not the code
i came across this cool framework called vanilla.js why don't you give it a shot
viu isto aqui ? Não é exatamente o que vc vem criticando?
como assim? eu critico justamente o react, não o abandono dele!
Sim, isto mesmo. Te passei para dar mais força à sua crítica.
valeu :) mas minha crítica é mais uma piada. caguei p/ o que os meninos usam p/ fazer app hoje em dia.
Great finding. Aside from TTI, what other key user experience metrics do you typically measure and test against?
My team primarily looks at conversion metrics, secondarily CTR and other “user’s flow” metrics
WHO KNEW adding Mbs of overhead dependencies would cause performance issues!
Makes sense. Use it for the parts that need it, but drop it for the client. Simple wins!
But the UX is still shite.
Does this mean anything to you @spreech ?
I'm gonna start new.js, that'll fucking take care of it all. This will replace vue, Angular, etc #programming #javascript
Each of these frameworks should provide profile data for a set of common use cases incl. static web page. Easier to choose one then.