Learn JavaScript - Performance, Memory, Optimization, and Production-Ready Code

#Introduction

Congratulations — you've made it to the final episode. Twenty-one episodes built your understanding from basic syntax to modern tooling. Episode 22 closes the journey with two themes that define application quality in the real world: performance and readiness.

Performance means the application doesn't just function — it functions fast and stable: light to load, smooth to respond, and without leaking memory over time. Readiness means your code is secure, tested, and released in a structured way. Both are what separates a prototype from a production application. Hold one principle from the start: don't optimize without evidence — measure first, find the real problem, then optimize.

#Measuring Performance with Evidence

#The Performance API and Timing

Before changing anything, measure. performance.now gives precise timing:

Measuring a function's duration

function prosesData(angka) {
  let total = 0;
  for (const nilai of angka) {
    total += nilai * 2;
  }
  return total;
}
 
const mulai = performance.now();
const hasil = prosesData([1, 2, 3, 4, 5]);
const selesai = performance.now();
 
console.log(`Hasil: ${hasil}, durasi: ${selesai - mulai} ms`);

#Finding the Slow Spots

The tools you already know from episode 19 become useful again: the Performance tab in DevTools records a session and shows where time is actually wasted. Look for long tasks that block the page, then inspect the functions or layouts that dominate. Measurement results determine priority — sometimes the "coolest" optimization has no impact on a real application at all.

#DOM and Rendering Optimization

#Batching DOM Manipulation

Accessing and manipulating the DOM is far slower than in-memory operations. Collect changes and mount them at once:

Batching DOM manipulation

const kontainer = document.querySelector("#daftar");
const fragmen = document.createDocumentFragment();
 
for (let i = 1; i <= 100; i++) {
  const item = document.createElement("li");
  item.textContent = `Item ${i}`;
  fragmen.append(item);
}
 
kontainer.append(fragmen);

document.createDocumentFragment() holds elements in memory first, then mounts them all at once. Without this, 100 additions mean 100 render triggers; with a fragment, the browser renders once. The same principle applies to reflow — the expensive layout recalculation: gather style changes into one batch, for example kotak.style.display = "none", then change the class, then show it again, so it's one batch rather than three separate reflows.

#Memory and Leaks

#Causes of Leaks

JavaScript manages memory with garbage collection — objects that are no longer reachable are cleaned up automatically. A memory leak happens when objects that should be dead remain reachable, so the GC doesn't dare clean them up. The most common causes in web applications:

Event listeners never removed from deleted elements.
Global references holding large objects.
Closures retaining variables from finished scopes.

#Removing Listeners Correctly

Every addEventListener holds a reference to its handler. If an element is removed but the listener isn't, the reference stays alive:

Removing an event listener

function buatKartu() {
  const tombol = document.querySelector("#tombol");
 
  function handler() {
    console.log("Diklik");
  }
 
  tombol.addEventListener("click", handler);
 
  return function hapus() {
    tombol.removeEventListener("click", handler);
  };
}
 
const bersihkan = buatKartu();
bersihkan();

tombol.removeEventListener("click", handler) removes the listener with the exact same handler — which is why the handler must be stored in a variable rather than written inline anonymously. The returned hapus function gives you control over when cleanup happens.

#Practical Optimization Patterns

#Debounce and Throttle

Expensive operations triggered frequently — search-as-you-type, scrolling, resizing — can overwhelm an application. Debounce delays execution until a pause in activity; throttle limits execution to at most once per interval:

A simple debounce

function debounce(fungsi, jeda) {
  let timer = null;
 
  return function (...argumen) {
    clearTimeout(timer);
    timer = setTimeout(() => {
      fungsi(...argumen);
    }, jeda);
  };
}
 
const cari = debounce((kata) => {
  console.log("Mencari:", kata);
}, 300);

#Lazy Loading and Code Splitting

Loading the entire application at once slows down the first visit. Code splitting breaks the bundle into parts loaded on demand:

Lazy loading a module

async function muatModulBerat() {
  const modul = await import("./modul-berat.js");
  return modul.proses();
}
 
tombol.addEventListener("click", () => {
  muatModulBerat().then(console.log);
});

#Structuring Production-Ready Code

#Non-Negotiable Basic Security

Production code must consider security. The two rules most frequently violated:

Don't put user input into innerHTML — an XSS hole. Always use textContent or escape the HTML.
Don't store tokens in localStorage — any script can read it. Use an HttpOnly cookie.

Making text safe to display

function teksAman(teks) {
  const div = document.createElement("div");
  div.textContent = teks;
  return div.innerHTML;
}

div.textContent = teks makes the browser escape special characters, so <script> becomes safe plain text to display. This pattern is a simple trick for showing user input without opening a hole.

#Testing, Versioning, and Release

Production-ready code also means structured processes:

Test: write unit tests for core logic, at minimum for pure functions.
Version: use semantic versioning — major.minor.patch — for breaking changes, features, and fixes.
CI: run lint, test, and build automatically before merging.
Release: release through an automated process, not manual deploys.

All the tools were already covered in episodes 20 and 21: automated lint and format, reproducible builds with a lockfile, and npm scripts CI can invoke. Combining them into a release pipeline is the final step toward production.

#Wrap-Up

Episode 22 closed your journey: measuring performance with performance.now and the Performance tab, optimizing the DOM with batching, preventing memory leaks by removing listeners, applying debounce and lazy loading, and structuring production code that is secure, tested, and released systematically.

Key takeaways:

Don't optimize without measuring — start from the data.
Use fragments and batching to minimize DOM reflow.
Memory leaks happen because of references that are never released.
removeEventListener must use the exact same handler.
Debounce delays execution; throttle limits frequency.
Escape user input and don't store tokens in localStorage.
Test, version with semantic versioning, and release through automated CI.

This is the end of the Learn JavaScript series. From episode 0, which prepared your environment, to episode 22, which prepared production, you've built a complete foundation: syntax, data structures, functions, the DOM, asynchrony, tooling, and performance. The real journey begins now — apply everything you've learned in real projects, and keep writing code every day. Happy coding!