Learn browser storage vocabulary: localStorage vs. sessionStorage vs. IndexedDB vs. Cache API, quota management, storage eviction, opaque responses, and CORS in service workers.
0 / 10 completed
1 / 10
The key difference between localStorage and sessionStorage is:
Both APIs are synchronous, same-origin, key-value string stores. localStorage survives browser restarts. sessionStorage is scoped to the lifetime of the tab — opening the same URL in a new tab creates a separate sessionStorage. Neither is suitable for large amounts of data or complex queries; use IndexedDB for those cases.
2 / 10
IndexedDB is preferred over localStorage for web applications that need to:
IndexedDB is a full transactional database in the browser: it supports object stores, indexes, cursors, and key ranges. Unlike localStorage, it is asynchronous (non-blocking), can store megabytes to gigabytes of data, and works in service workers. It is the backing store for offline-capable apps and tools like PouchDB.
3 / 10
An 'opaque response' in the context of the Cache API and service workers means:
When a service worker fetches a resource from a different origin without CORS (a no-cors request), the browser returns an opaque response: status is 0, headers are empty, body is unreadable. It can be cached and served back to the page, but the service worker cannot check if the request succeeded. Opaque responses count as a minimum of ~7 MB against the storage quota to prevent timing attacks.
4 / 10
The Cache API differs from HTTP caching (browser cache) in that:
The browser's HTTP cache is controlled by Cache-Control headers from the server. The Cache API is a separate, developer-controlled storage accessible to service workers and the window. A service worker can pre-cache app shell assets during install, serve them instantly, and update them on a schedule — giving precise control over offline behaviour.
5 / 10
Browser storage quota management means that:
The Storage API (navigator.storage.estimate()) lets apps query their quota and usage. By default, storage is 'best-effort' and can be evicted under pressure. Calling navigator.storage.persist() requests persistent storage — the browser (or user) may grant it, protecting the origin's data from automatic eviction. This is important for offline-first PWAs that cannot afford to lose cached data.
6 / 10
During a code review of Sarah's new feature for user preferences, she uses `sessionStorage` to store the user's selected theme. John comments: 'Storing preferences in `sessionStorage` is good, but what happens if the user closes their browser? The data will be lost.' What does John *primarily* highlight about using `sessionStorage` in this context?
John correctly identifies that `sessionStorage`'s lifespan is tied to the active browser session. The key difference between `sessionStorage` and `localStorage` is that `sessionStorage` data is cleared when the tab or window is closed, whereas `localStorage` data persists indefinitely. This makes it unsuitable for persistent user preferences.
7 / 10
Mark is explaining the rationale behind using IndexedDB to his team. He says: 'We need to store a large amount of structured data related to user activity – things like shopping carts and detailed search histories – and we need to be able to efficiently query that data over extended periods.' Which statement best describes why IndexedDB is a better choice than `localStorage` in Mark's scenario?
Mark's needs – large structured data and complex queries – are precisely where IndexedDB excels. `localStorage` is designed for simple key-value pairs and isn't optimized for querying or managing large amounts of data efficiently. IndexedDB provides robust transaction support and indexing capabilities that `localStorage` lacks.
8 / 10
"The Cache API's 'opaque response' is often misunderstood," explains David to his junior developer. "It's not about the HTTP status code itself (e.g., 200 OK). Instead, it's about what the service worker *perceives* about the resource's success or failure – regardless of whether the server returned an error." Which of the following best illustrates this concept?
David's explanation is crucial: the 'opaque response' isn't a direct reflection of the server's HTTP status. The service worker controls this – it determines whether a resource load was considered successful based on its own logic (e.g., network availability, content validation). This allows for caching strategies beyond simple HTTP status codes.
9 / 10
During a discussion about optimizing website performance, Emily points out a key difference between the Cache API and traditional browser caching. She states: 'The Cache API allows for more granular control over cache invalidation than standard HTTP caching.' What does she *primarily* mean?
While both methods aim for efficient caching, Emily highlights a core difference: the Cache API's service worker component offers dynamic control. Unlike standard HTTP caching that relies on pre-defined headers (e.g., `Cache-Control`), the Cache API allows service workers to actively invalidate caches based on real-time conditions – a level of flexibility not available with traditional browser caching.
10 / 10
"We need to carefully manage our browser storage quota," explains Ben during a team meeting. "If we exceed it, the browser will start aggressively discarding data – potentially impacting user experience and application stability." What is the *most* important consequence of exceeding a browser's storage quota?
Exceeding a browser's storage quota triggers aggressive data eviction. The browser doesn't disable JavaScript or halt data loading; instead, it proactively deletes less-used data to maintain performance and stability. This is why careful quota management is vital – the browser prioritizes functionality over memory constraints.
This exercise, "Browser Storage Vocabulary", tests your understanding of wasm browser vocabulary and phrasing through 10 multiple-choice questions drawn from real workplace scenarios.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one presents a realistic sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Who is this Wasm Browser exercise for?
It's designed for IT professionals and learners who want to sound natural discussing wasm browser topics in English — useful for meetings, documentation, interviews, and day-to-day communication with English-speaking teams.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more Wasm Browser exercises?
Browse the full Wasm Browser exercises hub for more practice, or explore other exercise categories covering vocabulary, grammar, interviews, and workplace communication.