Preact - Performance Optimization by default
A few months ago, I wrote an article based on optimizing react loading time, and most of the reader's comments were to try Preact to get default optimization. So I decided to try preact with the same app used for the previous article. Let's first get an intro about Preact.
Preact is a React alternative library with all the react features!.. Preact is a 3KB library. It is very small compared to react, as react and react-dom gzip size is around 41KB excluding react-scripts based on bundlephobia. Some highlighted features of preact are
- Lightweight Virtual Dom
- Small in Size
- Performance optimized by default
- Integration is simple
- PWA by default
Now let's see preact in action.
I have developed the same app in React and Preact to test the app performance.
For react app I used Create React App and for Preact used preact-cli. Preact also gives an option to convert your existing react app to preact using preact-compat, but I have built an app from scratch to see the best result.
To compare both app performances, I used GTmetrix and hosted both apps in Netlify.
React App Performance
Below is the score given by GTMetrics for React-based App. I have used Route Based Code Splitting for the dashboard Component. The performance is 80% with B grade, largest content paint (LCP) and Layout Shifting (CLS) seems low.
As we see in the below image, the entire page is loaded in 2 sec, First Content Paint is around 1 sec. Seems the performance is Not bad.
Preact App Performance
All the metrics are in Green!!!. Seems the same app in Preact scored 100% with an A grade in GTMetrix. The largest content paint (LCP) is less than 500ms, No Layout Shifting (CLS) happened.
This looks very impressive. Preact optimized our dashboard app quite well. The performance is drastically increased compared to React. Let us check the Loading time
As we see in the above image. The entire App loads in 1.3 secs and the Time to First Byte (TTFB)is 179ms !!. Preact seems very faster compared to React and it handles everything by default.
As looking at the page loading side by side, Preact app loads well ahead compared to React and The Time to interact is also faster than react app. Preact is Progressive Web App(PWA) by default so instant loading on repeat visits.
Preact also gives some useful warning reg bundle size increase during the build as below
Suspense and Lazy
Some limitation I faced when converting to Preact is that Suspense and lazy loading are experimental and don't support on production as of now. but route based code splitting is enabled by default for the routes directory.
Reference
Conclusion
As based on the above comparison Preact leads in all parts. Due to reduced library size and fast, Preact allow us to focus on developing features instead of manual optimization.
Thank you for reading.
Get more updates on Twitter.
You can support me by buying me a coffee ☕
eBook
Debugging ReactJS Issues with ChatGPT: 50 Essential Tips and Examples
ReactJS Optimization Techniques and Development Resources
More Blogs
- Laravel Sanctum Authentication for React App Using Breeze
- Twitter Followers Tracker using Next.js, NextAuth and TailwindCSS
- How to Structure Your React Redux App
- How to Reduce React App Loading Time By 70%
- Build a Portfolio Using Next.js, Tailwind, and Vercel with Dark Mode Support
- No More ../../../ Import in React
- 10 React Packages with 1K UI Components
- 5 Packages to Optimize and Speed Up Your React App During Development
- How To Use Axios in an Optimized and Scalable Way With React
- 15 Custom Hooks to Make your React Component Lightweight
- 10 Ways to Host Your React App For Free
- How to Secure JWT in a Single-Page Application
Top comments (18)
Then you realize - a lot of components you had don't work with preact, because they were made for react. Then you realize, that you have to implement a lot of functionality that comes out of the box with react... and suddenly you realize why react has a bigger footprint.
And the less code YOU write, the less bugs you have to fix, because let's agree on that - the bigger the codebase the more bugs there are.
Just my .02c
Imagine if there were a standard for components that could work across all the various front-end libs and frameworks.
Oh, there is? custom-elements-everywhere.com/
Of course, React doesn't support them properly.
While I do appreciate what React has given to the community as a whole - it would be so much better if we could get to a point where people are developing web components and then we can just focus on the other libs we need.
Just my .01c (yeah, it's a bargin today)
Yes, if you start a new project you can pick anything. And I wouldn't pick neither React nor Preact - I like Vue better.
But if you are handed a react codebase, converting it to preact isn't a one-day task and the bigger the project the more problems you will meet.
I'm working on the opposite conversion: Preact->React, and our company chose to do so for a reason.
Couldn't have said it better ... look before you leap, things aren't always what they seem, there are always tradeoffs, and in most cases "it depends".
Once we changed experimentally ~2 years ago the codebase to preact and we had decreased pageload times reported both by devtools and analytical tools, even tho evaluation times improved. We reverted. Possibly this improved since then.
However, as it was pointed out, Suspense and Lazy are experimental, React 18 is around the corner with even more features. It simply means preact will be one step behind, no matter what. Not saying it's anyone's fault, everyone can decide on their own which one is more benefitial/important for their project.
There's no such thing as a free lunch ... there are always trade-offs ... performance gains might be marginal and unnoticeable in real world usage ... if it sounds too good to be true, it probably isn't true.
preact-compatis the legacy compat, and isn't used in modern apps. Compat lives in core since v10 (which has been out for 2+ years), see v10/upgrade-guideNext, the comments will be about solidjs
Speed is fine in React.
Agree. Actually developers/companies who create browsers may eventually sober up and create some useful components and provide better means to validate so we don't have to reinvent the wheel in every framework and component library.
Date input was nearly unusable until a couple of years ago. It still sucks TBH.
Fixed table header was a thing for over a dekade. It still requires a considerable amount ot black magic.
Years ago I was working on a project and at this time chrome lacked the print preview and options dialog. Before developers released this feature, chrome got WebGL, WebSockets and whatnot, but printing was still waiting.
Firefox had an insanely useful plugin jsPrintSetup which no longer works. None of the browsers allows you to do some customizations to the page before printing something (like printing a barcode to a specialized label printer and the rest of the page on you regular one, like we did this with the old version of FF, all this with a single button click)
Recently I was offered to work on a project that was using Telerik's components, which by far are the biggest monstrosity I've ever met and surprisingly to me people are happily using them, and even more surprising to me users are patiently waiting for the page to appear and start working...
I can keep going on and on...
Thanks for the interesting post.
The performance comparison should also consider the change in performance metrics when the app gets more complex
Performance is not the most important thing.
How about hooks? Can't see those in description.
Yes, hooks exist and work in Preact exactly as you'd expect, see docs
Thanks for the post!
Will surely give Preact a try next!
I will try this, looking very interesting