chrome dev tools -> ligthHouse -> check performance under categories -> analyse page load
check the page performance and see the oppurtunities to improve site perf
** oppurtunities**
- Reduce unused JavaScript
- click ctrl shift p and click on show coverage - run coverage and check the percentage
- click on file. red block will be unused code and green will be used one
- remove unused libs
- click on ctrl shift p - show n/w request blocking
- add pattern /lib/*
- go to network tab and reload page
- unused libs will be marked in red
- use file compression
- in node js use compression module
- app.use(compression())
- click on perf tab
- start profiler
Metrics
Visual Metrics - - how fast stuff is painted on screen (FCP) - first contentful paint, speed index Intractive Metrics - how quickly site become usable for users- time to be intrective(TTI)
Events DCL - dom contentful loaded event - > FP Firs paint -> FCP -> first contentful paint -> LCP largest contentful paint -> L -> on load Event
Analysis tools
https://pagespeed.web.dev/
https://www.webpagetest.org/
monitoring tools
GTmetrix
speed Curve
fireFox performance tab
- inspect dev tool and click on performance tab -> click on refresh -> stop
- analyse the profile
- profile is better in dev mode rather than production mode as code is compressed and source map are disabled in prod code
- You can enable screenshot option to see what happens on screen during the profile analysis, intermedaitae state of UI which is usually not visible on load
- yellow color - javascript ctivity, green - repainting, blue - html parsing , purple - style calculation
- network tab in profile shows detailed data of n/w console tab. what happen in that time frame i.e. js request, html ,images loaded
- main tab - we should use this for performace gaps
- used to identify user experience issues in following area
- page loading perf
- ease of interraction
- visual stability
visual vitals
- FP - first paint - background color
- FCP - first contentful paint - first text anywhere in page
- FMP - first meaningful paint -
- LCP -largest contentful paint - for the current viewport 0- screen which is visible
- page load time - when everything on page is loaded, all resources, scripts, css images etc
- time to visual ready
ux vitals
- TTI - time ot intractive
- TBT - time b/w FCP -TTI- blocked time, sum of all tasks which are taking more than 50ms
- INP - interaction to next paint - give you all interaction which were below the mark - TTI is subset of INP
- FID - first inpoit deplay
Core Web Vitals
- LCP - largest contentful paint - good if within 2.5sec
- FID - first inut delay - when user interact with page ie.e from button click to the response - good if less than 100ms
- CLS - commulative layout shift -changes in display when the content loads and provides bad exp to user- shd be less than 0.1 - it is evaluated for whole page. if while scrolling page is layout is shifting then it is calculated for all. in SPA website, if pages are not refreshed then cls is calculated for all refreshed component. as it tracks for whole journey. CLS will be 0 if layout shift is done within 300ms.
- async and defer normal JS html parse and wherever it sees js it download js and execute it and block rest of te execution async - script is executed only once downloading is complete i.e. without blocking defer - all the html parsing happens first then script downloading and execution
- use link rel='preconnect' and prefetch, preload
- use lazy loading images *use CDN
- can be installed
- have push notificatiosn
Improves User experience and bussiness growth.
browser cache improved page load time Browser Cache
- cache headers expires - in seconds cache-control : max-age, public(can be cached at client/server) - max-age takes priority over expires eTag - browser add it
- Service worker caching
CDN cache
compression we can compress files using GZIP and brotili- brotili compression is better than gzip
Static Compression when files are compressed before storing in server
Dymanic Compression files are compressed as response from server
where do we compress data? - better to compress at build if dynamic then cdn
Responsive Images if we have high resloution picture, when it is rendered on mobile then it has perf issues. use img srcSet tag which takes nultiple images as per the diffrent sizes.
picture source is heavy so use srcset as it is lightweight
User webP and avif image formats as these are smaller()25-30% in size as compared to png and jpegs
preload 4-6 preloads shd be fine what to preload - font-face
Hydration react hydration - event binding to html earlier we used to use react render but it is not replaced with hydrate
- if code cant be split then do tree shaking, compress code and uglify
but best is code splitting(load only bundles which are required for page) - can be achieved by routes or by component based.
- we can use dynamic imports
Bundle Phobia for evaluating size of bundle - provides you alternative option, and n/w cost webpack bundle analyser
- optimistic UI
- Async & defer - defer script load to end or wait till window onload event and then load script
- builder.io - partytown- score goes down with analytics lib, using party town increases the score
- Avoid repaint(changing the style not the dom node ) and reflow(changing the tree)- batch dom changes, set element to none and do changes and aagain set visibility, -- use absolute and fixed position -- avoid inline style as it causes reflow(more inline style more reflows)
- partial hydration
- server side performance
metrics- performance is 80% on frontend and 20% on server side. if first html is returnned after 1000ms then we will be working on that
- CPU utilization
- memory utilization - if memory uses is higher the gc will start acting but we will not be able to access data during that time
- average latency - if server is far from clinet location
- throughput
- server uptime
- disk i/o - using sdd instead of hd as reading data is faster from sdd rather than hd
recomendadtions - minimize n/w latency. - reduce distance using CDN, use compression (gzip, brothili),
- load balancing & scaling(vertical/horizontal)
- optimize server response time
- optimize caching
- database perf - optimize schema (normaliztaion), indexing , stored procedures, db caching(redis, memcache), optimize query, connection polling (opening con takes time if we keep few open then it will available readily for use)
- deded