Toggle navigation
MeasureThat.net
Create a benchmark
Tools
Feedback
FAQ
Register
Log In
setIsMinViewportSize on resize event vs matchMedia vs ResizeObserver
(version: 2)
Comparing performance of:
resize event vs matchMedia vs ResizeObserver
Created:
3 years ago
by:
Registered User
Jump to the latest result
HTML Preparation code:
<div> Hello </div>
Script Preparation code:
isMinViewportSize = false; minViewportSize = 500 function setIsMinViewportSize(value) { if (isMinViewportSize !== value) { isMinViewportSize = value; // simulate rendering getComputedStyle(document.body) } } function resize() { let direction = 'up'; for (let i = 400; direction === 'up' || i > 400; direction === 'up' ? i++ : i--) { window.resizeTo(i, 1000) if (i === 600) { // up 200, down 200 direction = 'down'; } } }
Tests:
resize event
const handleResize = event => { setIsMinViewportSize(window.innerWidth >= minViewportSize); } window.addEventListener("resize", handleResize); resize();
matchMedia
const handleMatchChange = ({ matches }) => { setIsMinViewportSize(matches); } const match1 = window.matchMedia(`screen and (min-width: ${minViewportSize}px)`) match1.addEventListener('change', handleMatchChange); resize();
ResizeObserver
const observer = new ResizeObserver(entries => { setIsMinViewportSize(entries[0].contentRect.width >= minViewportSize) }) observer.observe(document.body) resize();
Rendered benchmark preparation results:
Suite status:
<idle, ready to run>
Run tests (3)
Previous results
Fork
Test case name
Result
resize event
matchMedia
ResizeObserver
Fastest:
N/A
Slowest:
N/A
Latest run results:
Run details:
(Test run date:
one year ago
)
User agent:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
Browser/OS:
Chrome 131 on Mac OS X 10.15.7
View result in a separate tab
Embed
Embed Benchmark Result
Test name
Executions per second
resize event
9146.4 Ops/sec
matchMedia
46885.2 Ops/sec
ResizeObserver
49072.5 Ops/sec
Autogenerated LLM Summary
(model
llama3.2:3b
, generated one year ago):
**What is being tested?** On MeasureThat.net, the provided JSON represents a JavaScript microbenchmark that tests the performance of three different approaches to check if the viewport size has reached a minimum threshold (`minViewportSize`) on resize events: 1. **Resize Event**: This approach uses the `window.addEventListener("resize", handleResize)` method to listen for resize events and update the `isMinViewportSize` flag accordingly. 2. **matchMedia**: This approach uses the `window.matchMedia()` API to check if the viewport meets a specific media query condition (`screen and (min-width: ${minViewportSize}px)`) on every frame of the animation loop. 3. **ResizeObserver**: This approach uses the `ResizeObserver` API to observe changes in the viewport size and update the `isMinViewportSize` flag accordingly. **Options being compared** The three approaches are being compared to determine which one is the fastest: * `resize event`: The overhead of listening for resize events and handling them. * `matchMedia`: The overhead of using the `matchMedia()` API to check for media query matches. * `ResizeObserver`: The overhead of using the `ResizeObserver` API to observe changes in viewport size. **Pros and Cons** Here are some pros and cons for each approach: 1. **Resize Event** * Pros: + Simple and lightweight + Fast because it only needs to check once per frame. * Cons: + Can be slow if there are many resize events (e.g., due to frequent scrolling). 2. **matchMedia** * Pros: + More precise control over the media query condition. + Can be faster than `resize event` because it only needs to check once per frame, regardless of how often the viewport changes size. * Cons: + Requires more JavaScript code and setup (e.g., creating a new `matchMedia()` instance). 3. **ResizeObserver** * Pros: + More efficient than `resize event` because it only needs to observe the viewport size once, regardless of how often it changes. + Can be faster than `matchMedia` because it uses a more efficient API that doesn't require frequent checks. * Cons: + Less precise control over the viewport size comparison (only compares the current width). + May not work in older browsers or environments that don't support `ResizeObserver`. **Other considerations** * The use of `getComputedStyle(document.body)` to simulate rendering is likely a performance optimization to ensure the benchmark results are accurate. * The `resize()` function simulates a complex animation loop with multiple resize events, which can affect the results. **Special JS features or syntax** The test uses some advanced JavaScript features: * **Closures**: The `handleResize` and `handleMatchChange` functions use closures to capture the current state of the `isMinViewportSize` flag. * **Asynchronous execution**: The tests use asynchronous execution (e.g., `window.addEventListener()`) to allow for concurrent testing. **Alternative approaches** Other alternatives could include: * Using a web worker or worker thread to offload the viewport size checking and resizing tasks. * Implementing custom JavaScript code to handle the viewport size changes instead of relying on built-in APIs like `ResizeObserver` or `matchMedia`. * Using a third-party library that provides optimized viewport size checking and resizing functionality.
Related benchmarks:
toFixed vs toPrecision vs Math.round() vs Math.floorfaster test
toFixed vs toPrecision vs Math.round() vs Math.floorfast 0
parseFloat(toFixed) vs Math.round()
toFixed vs toPrecision vs Math.round() 22222
Benchmark math.round *100/100 vs toFixed(2)
Comments
Confirm delete:
Do you really want to delete benchmark?