Benchmark: clientWidth / clientHeight vs. getBoundingClientRect()

clientWidth / clientHeight vs. getBoundingClientRect() (version: 0)

Comparing performance of: clientWidth / clientHeight (destructured and renamed) vs clientWidth / clientHeight (destructured) vs clientWidth / clientHeight (simple property access) vs getBoundingClientRect() (destructured) vs getBoundingClientRect() (simple property access)

Created: 3 years ago by: Guest

Jump to the latest result

HTML Preparation code:

<div id="el">
  <h2>Lorem ipsum dolor sit amet</h2>
</div>

Script Preparation code:

var el = document.getElementById("el");

Tests:

clientWidth / clientHeight (destructured and renamed)
const { clientWidth: width, clientHeight: height } = el; const perim = (width + height) * 2;
clientWidth / clientHeight (destructured)
const { clientWidth, clientHeight } = el; const perim = (clientWidth + clientHeight) * 2;
clientWidth / clientHeight (simple property access)
const width = el.clientWidth; const height = el.clientHeight; const perim = (width + height) * 2;
getBoundingClientRect() (destructured)
const { width, height } = el.getBoundingClientRect(); const perim = (width + height) * 2;
getBoundingClientRect() (simple property access)
const rect = el.getBoundingClientRect(); const width = rect.width; const height = rect.height; const perim = (width + height) * 2;

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
clientWidth / clientHeight (destructured and renamed)
clientWidth / clientHeight (destructured)
clientWidth / clientHeight (simple property access)
getBoundingClientRect() (destructured)
getBoundingClientRect() (simple property access)

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: 6 days 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

Test name	Executions per second
clientWidth / clientHeight (destructured and renamed)	1532211.0 Ops/sec
clientWidth / clientHeight (destructured)	1586436.5 Ops/sec
clientWidth / clientHeight (simple property access)	1571216.9 Ops/sec
getBoundingClientRect() (destructured)	1956623.4 Ops/sec
getBoundingClientRect() (simple property access)	1995505.4 Ops/sec

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

LLMs can make mistakes. Check important info.

Let's dive into the Benchmark Definition and explain what is being tested.

The benchmark is comparing four different approaches to calculate the perimeter of an HTML element:

1. **Simple Property Access**: `const width = el.clientWidth; const height = el.clientHeight; const perim = (width + height) * 2;`
	* This approach accesses the `clientWidth` and `clientHeight` properties directly on the `el` element.
	* Pros: Simple, straightforward, and easy to understand.
	* Cons: Might be slower due to property access, which can lead to additional function calls or method invocations.
2. **Destructured Property Access**: `const { clientWidth, clientHeight } = el; const perim = (clientWidth + clientHeight) * 2;`
	* This approach uses destructuring assignment to extract the `clientWidth` and `clientHeight` values from the `el` element.
	* Pros: More concise and readable than simple property access.
	* Cons: Might be slightly slower due to the destructuring assignment, which can lead to additional function calls or method invocations.
3. **Destructured and Renamed Property Access**: `const { clientWidth: width, clientHeight: height } = el; const perim = (width + height) * 2;`
	* This approach uses destructuring assignment with renamed variables for better readability.
	* Pros: Similar to destructured property access but with more descriptive variable names.
	* Cons: Slightly less concise than destructured property access.
4. **getBoundingClientRect()**: `const { width, height } = el.getBoundingClientRect(); const perim = (width + height) * 2;`
	* This approach uses the `getBoundingClientRect()` method to get the element's bounding rectangle and then extracts the `width` and `height` values from it.
	* Pros: Might be faster since `getBoundingClientRect()` is a single method call that returns an object with multiple properties, which can reduce the number of function calls or method invocations.
	* Cons: More verbose and may require more CPU cycles to calculate the bounding rectangle.

The benchmark results show the execution frequency per second for each approach on a specific device (Firefox 131 on Ubuntu). The results suggest that:

* Destructured property access is the fastest approach, followed closely by getBoundingClientRect().
* Destructured property access is faster than simple property access.
* Destructured and renamed property access has slightly slower performance compared to destructured property access.

Other alternatives for calculating the perimeter of an HTML element include:

* Using a library like jQuery or Lodash, which provide their own methods for accessing and manipulating DOM elements.
* Implementing custom logic using JavaScript functions or object-oriented programming (OOP) principles.
* Utilizing native Web APIs like CSS Grid or SVG, which offer more advanced layout and geometry capabilities.

Keep in mind that the performance differences between these approaches may vary depending on the specific use case, device, and browser.

Related benchmarks:

clientWidth / clientHeight vs. getBoundingClientRect() (version: 0)

Comparing performance of: clientWidth / clientHeight (destructured and renamed) vs clientWidth / clientHeight (destructured) vs clientWidth / clientHeight (simple property access) vs getBoundingClientRect() (destructured) vs getBoundingClientRect() (simple property access)

Created: 3 years ago by: Guest

Jump to the latest result

clientWidth / clientHeight (destructured and renamed)

clientWidth / clientHeight (destructured)

clientWidth / clientHeight (simple property access)

getBoundingClientRect() (destructured)

getBoundingClientRect() (simple property access)

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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