For Web developers, performance isn't optional now. Performance plays a major role in the success of any online venture. DoubleClick by Google foun...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks Mohan for sharing some great insights into the web performance. It is often one of the places which is more commonly overlooked in a lot of projects while it has far reaching consequences on where the project will be successful or not.
Beyond the points you have mentioned, one of the other common issues I have seen in quite some application frontends is the excessive use of animations on the DOM elements to add more visual aspect.
Though this adds to the added eye-candy, it also triggers frequent recalculations of the layout in the browser, again impacting the user where they face input lags while the browser is recalculating the layout. This is something I really wish also comes into picture and gets optimized.
Hi Saurabh,
Thanks for mentioning the cost of heavy animations. They can cause extra overheads on the main thread thus can lead to bad UX.
One of my senior also mentioned that Images should be served in ".webp" to optimize images for fast loading.
Bundle files should be served inn gZype format to optimize js-files for fast loading.
Need to make PWA (Progressive Web App), to cache JS-files to load faster from 2nd time refresh.
But I'm not sure that everyone should go to the PWA path of development.
Image formats like JPEG 2000, JPEG XR, and WebP often provide better compression than PNG or JPEG, which leads to faster downloads and less data consumption.
Well, peoples can partially adopt PWA by using benefits of the service worker to cache a few resources like fonts, images, styles, scripts, etc. and then moving to other approaches.
I am still in learning may I know what are other approaches, and also from my little experience I always feel that performance of a site with simple HTML, JS, CSS is way better than when we create them in any JavaScript framework.
Hi Mohan,
TTI(Time To Interactive) as a performance budget is a tricky issue because the metric is neither simple to evaluate nor easy to act upon, making its usage very complicated when discussion web performance with different web actors.
I wrote a piece on it (available on dev.to) and deeply recommend RUM metrics instead (like the distribution of First Input Delay) or Custom Metrics (for Synthetic Monitoring).
Says Google, when their article takes almost 10 seconds to load. Yes I am using a mobile connection. And their page is nearly 2 MB big.
Removing ads and trackers would definitely increase the performance. :)
Yes Tari, That's correct.
Yes, this article seems to focus on the "loading" performance of the website.
There is whole another bugs on how to keep your code itself performant, so it doesn't feel sluggish as you use it.
Yes, that's about rendering performance. The goal is to remove render blocking code bloats and reduce overheads of main thread while first contentful paint. This can be achieved by setting and achieving performance budget.