Benchmark: clientWidth vs offsetWidth vs window.getComputedStyle

HTML Preparation code:

<div id="teste">teste</div>

Script Preparation code:

var teste_n = '123px';
var _style = window.getComputedStyle(document.getElementById('teste'));

Tests:

clientWidth
document.getElementById('teste').clientWidth;
offsetwidth
document.getElementById('teste').offsetwidth;
window.getComputedStyle
parseFloat(_style['width'])

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
clientWidth
offsetwidth
window.getComputedStyle

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: one month ago)

User agent: Mozilla/5.0 (iPhone; CPU iPhone OS 18_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.3 Mobile/15E148 Safari/604.1

Browser/OS: Mobile Safari 18 on iOS 18.3.1

View result in a separate tab

Test name	Executions per second
clientWidth	15373623.0 Ops/sec
offsetwidth	75036824.0 Ops/sec
window.getComputedStyle	4585675.5 Ops/sec

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

LLMs can make mistakes. Check important info.

Let's break down the provided benchmark definition and test cases to understand what is being tested.

**Benchmark Definition**

The benchmark definition consists of three test cases:

1. `document.getElementById('teste').clientWidth;`
2. `document.getElementById('teste').offsetWidth;`
3. `parseFloat(window.getComputedStyle(document.getElementById('teste')).width);`

These test cases measure the performance of accessing different properties related to a DOM element's size.

**Options Compared**

The benchmark is comparing three options:

1. `clientWidth`: The client width property returns the width of an element, including padding and border.
2. `offsetWidth`: The offset width property returns the total width of an element, including content, padding, border, margin, and scrolling positions.
3. `window.getComputedStyle(document.getElementById('teste')).width;` : This option uses the Web API to get the computed style of the element's width.

**Pros and Cons**

Here are some pros and cons of each approach:

1. **clientWidth**: Pros: Simple, easy to understand. Cons:
	* May not account for padding, border, or other layout boxes.
	* May be slower due to unnecessary calculations.
2. **offsetWidth**: Pros: More accurate, as it includes content, padding, and borders. Cons:
	* Can be slower due to the need to consider all these factors.
3. **window.getComputedStyle**: Pros: More accurate, as it returns the exact computed style of the element. Cons:
	* May be slower due to the overhead of the Web API.
	* Requires more computation and parsing.

**Library and Purpose**

The `window.getComputedStyle` function uses the Web APIs for getting the computed style of an element. The purpose is to accurately retrieve the current styles applied to an element, including any layout adjustments.

**Special JS Feature or Syntax**

There isn't a special JavaScript feature or syntax used in this benchmark. However, it's worth noting that `window.getComputedStyle` uses a proprietary Web API, which might not be supported by older browsers.

**Other Alternatives**

If you want to explore alternative approaches, here are a few options:

1. **CSSOM**: The CSS Object Model (CSSOM) provides a more modern and efficient way of accessing the computed styles of an element.
2. **DOM APIs with computed properties**: Some DOM APIs provide computed properties that can be used to access the styles of an element, such as `getComputedStyle` for the browser's default styling or `style` property for specific elements.

Keep in mind that each alternative has its own pros and cons, and might not match the exact requirements of your use case.

Related benchmarks:

clientWidth vs offsetWidth vs window.getComputedStyle (version: 0)

Comparing performance of: clientWidth vs offsetwidth vs window.getComputedStyle

Created: 5 years ago by: Registered User

Jump to the latest result

clientWidth

offsetwidth

window.getComputedStyle

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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