Why Deleting Object Properties Can Hurt V8 Performance: Understanding Hidden Classes, Deoptimization, and Dictionary Mode

Most JavaScript developers have used the delete operator countless times.

const user = {
  name: "John",
  age: 30,
  city: "Bangalore"
};

delete user.age;

Simple, right?

The property is removed, the application continues to work, and everyone moves on.

But have you ever wondered what happens inside the JavaScript engine after that line executes?

As frontend developers, we often focus on writing clean and maintainable code, but understanding how JavaScript engines optimize our code can help us make better decisions — especially in performance-critical applications.

In this article, we’ll explore how Google’s V8 engine optimizes objects, what Hidden Classes are, why deleting properties can affect performance, and when it actually matters.

JavaScript Objects Are Smarter Than You Think

Most developers assume JavaScript objects behave like hash maps.

For example:

const user = {
  name: "John",
  age: 30,
  city: "Bangalore"
};

It seems reasonable to think that when we access:

user.age;

JavaScript searches for the key "age" and returns the corresponding value.

If engines worked this way for every property lookup, JavaScript applications would be much slower.

Modern engines like V8 use a much more efficient approach.

Meet Hidden Classes

V8 attempts to optimize JavaScript objects by treating them similarly to structures in lower-level languages.

When an object is created, V8 generates an internal blueprint known as a Hidden Class.

Think of a Hidden Class as a map describing where properties are stored in memory.

For our user object:

const user = {
  name: "John",
  age: 30,
  city: "Bangalore"
};

V8 internally thinks of it like this:

Hidden Class A

Slot 0 → name
Slot 1 → age
Slot 2 → city

Memory might look something like:

+-----------+
| John      | ← Slot 0
+-----------+
| 30        | ← Slot 1
+-----------+
| Bangalore | ← Slot 2
+-----------+

Now, when JavaScript accesses:

user.age

V8 doesn’t need to search for "age".

It already knows age is located in Slot 1.

This makes property access incredibly fast.

Why Consistent Object Shapes Matter

Consider the following objects:

const user1 = {
  name: "John",
  age: 30,
  city: "Bangalore"
};

const user2 = {
  name: "Jane",
  age: 25,
  city: "Mumbai"
};

const user3 = {
  name: "David",
  age: 40,
  city: "Delhi"
};

All three objects share the same structure.

name
age
city

Because the shape is identical, V8 can reuse the same Hidden Class for all of them.

This allows the engine to generate highly optimized machine code and apply techniques such as Inline Caching.

The result?

Faster property access and better runtime performance.

The Moment We Delete a Property

Now let’s remove a property:

delete user1.age;

The object becomes:

{
  name: "John",
  city: "Bangalore"
}

At first glance, nothing seems unusual.

However, internally the object’s shape has changed.

Before deletion:

Slot 0 → name
Slot 1 → age
Slot 2 → city

After deletion:

Slot 0 → name
Slot ? → ?
Slot ? → city

The Hidden Class V8 was using may no longer be valid.

The engine must now determine:

• Does the object need a new Hidden Class?
• Can previously optimized code still be used?
• Are existing assumptions still correct?

This is where performance costs begin to appear.

Understanding Deoptimization

One of V8’s biggest strengths is its ability to generate optimized machine code based on observed object shapes.

Suppose a function repeatedly receives objects with the same structure:

function getAge(user) {
  return user.age;
}

After enough executions, V8 may optimize the function.

Internally it might become something similar to:

Read Slot 1

Extremely fast.

But once a property is deleted, those assumptions may no longer hold true.

V8 may need to discard optimized code and return to a slower execution path.

This process is called deoptimization.

While a single deoptimization is usually insignificant, repeated shape changes can prevent V8 from maintaining its best optimizations.

Dictionary Mode: When Flexibility Wins Over Speed

If an object undergoes frequent additions and deletions, V8 may eventually abandon its fixed-slot representation altogether.

Consider:

delete obj.a;
delete obj.b;
obj.c = 1;
delete obj.d;
obj.e = 2;

After enough structural changes, maintaining Hidden Classes becomes inefficient.

At that point, V8 may switch the object into Dictionary Mode.

Instead of fixed memory slots:

Slot 0 → name
Slot 1 → age
Slot 2 → city

the object behaves more like a dynamic lookup table:

"name" → John
"city" → Bangalore

Now property access involves searching for keys rather than directly accessing memory locations.

This provides flexibility but generally sacrifices performance.

Why Setting Undefined Is Different

Instead of deleting a property:

delete user.age;

we can assign:

user.age = undefined;

The value changes, but the object’s shape remains the same.

Slot 0 → name
Slot 1 → age
Slot 2 → city

V8 can continue using the same Hidden Class and preserve many of its optimizations.

This is why developers sometimes recommend using undefined in performance-sensitive code paths.

Should You Stop Using Delete?

Absolutely not.

One of the biggest misconceptions in JavaScript performance discussions is that delete should never be used.

That’s not true.

Use delete when:

delete payload.debugInfo;
delete request.internalMetadata;
delete response.tempData;

The property genuinely shouldn’t exist anymore.

These operations usually occur infrequently and have negligible performance impact.

Be careful when:

for (let i = 0; i < 1000000; i++) {
  delete users[i].cache;
}

or inside rendering loops, data processing pipelines, or high-throughput server code.

Repeated shape changes can interfere with V8’s optimization strategies.

The Real Lesson

The performance concern isn’t that deleting a property is expensive.

The real concern is what happens afterward.

Delete Property
        ↓
Object Shape Changes
        ↓
Hidden Class Changes
        ↓
Optimization Assumptions Break
        ↓
Potential Deoptimization
        ↓
Possible Dictionary Mode
        ↓
Slower Property Access

Understanding this chain of events gives developers a deeper appreciation of how JavaScript engines work under the hood.

Summary

Most applications will never experience noticeable performance issues from a few delete statements.

Readability and correctness should always come first.

However, understanding Hidden Classes, object shapes, deoptimization, and dictionary mode provides valuable insight into how modern JavaScript engines optimize our code.

As developers, we write JavaScript every day.

The more we understand what happens behind the scenes, the better equipped we are to write efficient, predictable, and scalable applications.

Sometimes, the most interesting performance lessons come from a single line of code:

delete user.age;

A simple statement with far more happening behind the scenes than most developers realize.