👉 We are losing $$$$ because of less conversion, bad user experience
👉 It's mostly Frontend Responsibilities
Here is The List
👉 Optimize Network Transfer👉 Working with HTTPS and HTTP2
👉 CSS as Appetizer
👉 JavaScript
👉 Optimizing Images
👉 Defining Policy for HTTP Cache
👉 Using Service Worker
🚨 It turns out the time to Interatice on the website is still SLOW, as page load time goes from 1s to 10s, the probability of a mobile visitor to bound INCREASE BY 123%, we're losing client and money
👉 Latency is the TIME DELAY between when a data packet is sent and when it's received (express in milliseconds)
👉 EVERY Http Request to get the Response Will Have a LATENCY
Here is the List
👉 Time to First Byte (TTFB) - browser sending http request to the server to get the response, this metric is all about time for the browser to load the first Byte from the response👉 First Paint - First time browser paint something to the screen
👉 Page Load (Not using this event anymore at modern day)
👉 Browser centric metrics are NOT SO IMPORTANT for WEB PERFORMANCE OPTIMIZATION
👉 Simply means: The Main Thread has been Released, at least for several miliseconds
👉 Browser ONLY HAVE 1 THREAD, Single Thread
👉 BUT the user will have the FEELING of Amazon is Faster
👉 Speed Index used to measure that Feeling
👉 It's interactive enough for a couple of milliseconds
Today, Core Web Vitals is actually including 3 metrics
👉 Because it has to do with the screen, it'll be different on different viewport sizes
👉 It's Frontend Responsibility
👉 Optimize the Backend has LESS impact and it's not a simple or Cheap Task.
🌟 OPTIMIZE THE FRONTEND HAS HIGH IMPACT, It's relatively CHEAP to optimize and RESULTS are IMMEDIATE.
Typically we gonna focus on the Resource Discovery Queue
Browser check the cache to see if we have the version of that file or not.
👉 Define Cache Headers per file
- Absolute expiration date (1.0) - Example:
this file will expired at 4PM, May 21, 2024 - Relative expiration date (1.1) - Example:
this file will expired after 2 months, 1 year,... - More specs / values
👉 Browser needs a resource
-
It checks the Cache
A) Cache Miss: we go to the networkB) Cache HIT: the file we need are in the Cache
🚨 It's Expired --> It's make
conditional requestServer Response Can be:
- Not modified (updated cache Header) OR
- OK, New File
🟢 It's NOT expired => We use the file from the Cache
👉 It's automatic
👉 You shouldn't use unload events, Cache-Control: no-store
👉 Use Page Navigation API to Open / restore Connections Or Abort pending transactions
👉 A service worker is a web server written in JavaScript that we install locally on user's device
👉 It's kind of the similar algorithm with the Browser Cache, the difference is that this is written by us
👉 Instead of relying on the browser's cache, now you have your own cache
👉 Service worker might not help the first initial visit of user, BUT it might help from the second visit, because next time we can serve the files locally
👉 Can improve the core web vital (performance) a lot, because we dont need go to the network every time
One Use Case / Design Pattern for using Service Worker and Cache Storage
it will not read the rest of the HTML
👉 If we block PARSING, we're ALSO blocking RENDERING, because RENDERING happens AFTER Parsing.
Here is the Long List => Open to Read 👇
👉 Enable GZIP on text-based files (HTML Static and Dynamic), JS, CSS, JSON and SVG
👉 Make Static Content Expire Late in the FUTURE
👉 Use a CDN for static content (CDN has servers all across over the world => closer to the user => the latencies will be shorter => lead to better user experience)
👉 Consider implementing HTTP/2 and HTTPS
👉 Use cookie-less domain
👉 Reduce cookie size
👉 Reduce Redirects (redirects are expensive)
👉 JavaScript as Dessert => We should DEFER it AS MUCH AS POSSIBLE, it uses the main thread, remove or defer unused code, JS is the most expensive asset that you have in your website
👉 Compress / Obfuscate JS and CSS
👉 Release the Main thread ASAP
👉 Embrace Responsive Images, SVG
👉 Compress Images, Define placeholder size
➡️ Avoid http to httpS redirect (HSTS - HTTP Strict Transport Security) => can save around 150-200 milliseconds
Help the browser discover resources that are obscure in the document
So then your browser will know that CSS or that web file will be needed even before start rendering the HTML
<link rel="preload" href="style.css" as="style" /><link rel="preload" href="style2.css" as="style" fetchpriority="high" />
<link rel="preload" href="otherimage.png" as="image" fetchpriority="low" />
➡️ Use Zopfli (Save 3-8% data transfer with GZIP) but it's 80x slower for compression NOT for decompression
➡️ Brotli (Save 25% data transfer compared with GZIP, check Encoding header)
➡️ Use Modern Image Formats (Not just PNG and JPEG) - use SVG for instance
➡️ WebP, AVIF, Zopfl PNG, Guetzli JPEG
➡️ Muted videos instead of GIFs
Squoosh is the open source allow us to convert image
<img loading="lazy" /> <iframe loading="lazy"></iframe>font-display: optional or swap;➡️ We SHOULD NOT doing CLIENT-SIDE RENDERING - it's terible idea for initial load, terible for performance
better performance leads to better conversion
➡️ Move HEAVY tasks to WebAssembly
➡️ Stop serving legacy code
➡️ Reactive Web Performance
➡️ Provide a Constistent Experience
➡️ Get Reports from the Browser
➡️ Let us execute code on next frame before paiting it
➡️ It's GUARANTEE to be executed on next frame
➡️ Better than timers (set interval and set time out)
➡️ We should keep code small (< 10ms )
➡️ It sends an argument where we can query how much time is left before idle time is gone and next frame should start
➡️ We should stop and schedule a new Idle callback if time is zero