Benchmark: addEventListener('resize') + innerWidth VS matchMedia() + matchMedia.addListener() VS Without JS

HTML Preparation code:

<style>
  #before:before {
  	content: "a";
 	 display: none;
  }
  @media(min-width: 200px) {
  	#body {
  		background: red;
  	content: "b";
  	}
  }
  @media(min-width: 600px) {
  	#body {
  		background: blue;
  	content: "c";
  	}
  }
  @media(min-width: 1000px) {
  	#body {
  		background: yellow;
  	content: "d";
  	}
  }
</style>
<div id="body">
</div>

Tests:

Without JS
const none = () => {}; none();
MatchMedia with JS
const matchMedia = window.matchMedia("(min-width: 400px)"); matchMedia.addListener((query) => { if (query.matches) { console.log(true); } })
Resize
let currentWidth = window.innerWidth; window.addEventListener('resize', () => { currentWidth = window.innerWidth; }); if (currentWidth > 400) { console.log(true); }

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Without JS
MatchMedia with JS
Resize

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated one month ago):

LLMs can make mistakes. Check important info.

Let's dive into the world of JavaScript microbenchmarks on MeasureThat.net.

**Benchmark Overview**

The benchmark measures the performance difference between three approaches to detect screen size changes: using JavaScript event listeners, `matchMedia`, and not using JavaScript at all (basically checking the window's inner width).

**Options Compared**

1. **Without JS**: The first approach is to simply check the `innerWidth` property of the window object without any additional code or event listeners.
2. **MatchMedia with JS**: This approach uses the `matchMedia` API, which provides a way to query the media queries defined in CSS and listen for changes when they are triggered. In this case, it's used to check if the screen width is greater than 400 pixels.
3. **Resize**: The third approach uses an event listener to capture screen size changes by updating the `innerWidth` variable on every window resize event.

**Pros and Cons of Each Approach**

1. **Without JS**:
	* Pros: No additional JavaScript code or overhead required, simple to implement.
	* Cons: May not be as accurate or responsive as other methods, as it relies solely on the browser's `innerWidth` property which may not always be up-to-date (e.g., during page loading).
2. **MatchMedia with JS**:
	* Pros: More accurate and responsive than the "Without JS" approach, as it listens for changes in media queries.
	* Cons: Requires an additional JavaScript library or API call to work, which may add overhead.
3. **Resize**:
	* Pros: Provides a more accurate response to screen size changes, as it captures events from the browser's event listener queue.
	* Cons: May introduce unnecessary overhead due to the event listener and repeated updates of the `innerWidth` variable.

**Other Considerations**

When choosing an approach, consider factors like performance, accuracy, and code complexity. The "Resize" approach may provide the most accurate results but also introduces more complexity. The "MatchMedia with JS" approach balances accuracy and simplicity while requiring additional JavaScript overhead.

**Special JavaScript Features or Syntax**

The `matchMedia` API is a relatively new feature introduced in modern browsers (from around 2012). It allows developers to query media queries defined in CSS and listen for changes when they are triggered. This API is widely supported across modern browsers, including Chrome, Firefox, Safari, and more.

**Other Alternatives**

In addition to the three approaches mentioned above, there are other methods to detect screen size changes:

* Using CSS media queries with JavaScript event listeners (e.g., `addEventListener('resize', () => {...})`)
* Utilizing browser-specific APIs like `window.screen.width` or `screen.width`
* Implementing a custom solution using canvas or other low-level HTML/JavaScript APIs

Keep in mind that each approach has its pros and cons, and the best choice depends on your specific use case, performance requirements, and code complexity considerations.

Latest run results:

Run details: (Test run date: 2 years ago)

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36

Browser/OS: Chrome 104 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
Without JS	909419136.0 Ops/sec
MatchMedia with JS	335227.7 Ops/sec
Resize	1970.8 Ops/sec

Related benchmarks:

addEventListener('resize') + innerWidth VS matchMedia() + matchMedia.addListener() VS Without JS (version: 0)

Comparing performance of: Without JS vs MatchMedia with JS vs Resize

Created: 2 years ago by: Guest

Jump to the latest result

Without JS

MatchMedia with JS

Resize

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated one month ago):