Toggle navigation
MeasureThat.net
Create a benchmark
Tools
Feedback
FAQ
Register
Log In
Fetch cache (default) vs no cache (no-store) GET method/text
(version: 0)
Comparing performance of:
Fetch (default) vs Fetch (no-store)
Created:
6 years ago
by:
Guest
Jump to the latest result
HTML Preparation code:
<div id="test"></div>
Tests:
Fetch (default)
fetch('https://jsonplaceholder.typicode.com/todos', { method: 'GET' }) .then((response) => { return response.text(); }) .then((data) => { console.log(data); });
Fetch (no-store)
fetch('https://jsonplaceholder.typicode.com/todos', { method: 'GET', cache: 'no-store' }) .then((response) => { return response.text(); }) .then((data) => { console.log(data); });
Rendered benchmark preparation results:
Suite status:
<idle, ready to run>
Run tests (2)
Previous results
Fork
Test case name
Result
Fetch (default)
Fetch (no-store)
Fastest:
N/A
Slowest:
N/A
Latest run results:
No previous run results
This benchmark does not have any results yet. Be the first one
to run it!
Autogenerated LLM Summary
(model
llama3.2:3b
, generated one year ago):
Let's dive into the world of measuring JavaScript performance. **What is being tested?** The benchmark is testing two different approaches for making HTTP GET requests using the `fetch` API: with caching enabled (`default`) and without caching enabled (`no-store`). The test cases are designed to measure the execution time, number of executions per second, and other metrics for both scenarios. **Options being compared** In this case, we have only two options being compared: 1. **Fetch with caching enabled**: This option uses the `cache` property in the `fetch` options object to enable caching. The request is cached by the browser or a proxy server, which means that subsequent requests for the same URL will use the cached response instead of re-downloading it from the server. 2. **Fetch without caching enabled (no-store)**: This option omits the `cache` property in the `fetch` options object, effectively disabling caching. The request is always sent to the server, even if it's a repeat request. **Pros and Cons** Here are some pros and cons of each approach: * **Fetch with caching enabled**: + Pros: Can reduce latency and improve performance for repeated requests. + Cons: May lead to stale responses or incorrect data if the cached response is outdated or corrupted. * **Fetch without caching enabled (no-store)**: + Pros: Ensures that you always get the most up-to-date response from the server, reducing the risk of stale or incorrect data. + Cons: Can increase latency and reduce performance for repeated requests. **Library usage** In this benchmark, the `fetch` API is used to make HTTP GET requests. The `fetch` API is a modern JavaScript API introduced in 2015, which allows you to make asynchronous HTTP requests without requiring manual implementation of AJAX-like code. **Special JS feature or syntax** There doesn't appear to be any special JavaScript features or syntax used in this benchmark. The test cases are written in standard JavaScript and use the `fetch` API as described above. **Other alternatives** If you're interested in exploring alternative approaches for making HTTP requests, here are some options: * **XMLHttpRequest**: A legacy JavaScript API that's still supported in modern browsers. * **AJAX-like libraries**: Libraries like jQuery or Axios provide a simpler interface for making HTTP requests and may offer more features than the `fetch` API. * **Node.js modules**: If you're developing server-side applications, you can use Node.js modules like `http` or `https` to make HTTP requests. Overall, this benchmark provides a useful insight into the performance differences between fetching with caching enabled versus without caching.
Related benchmarks:
jQuery by id vs Document.getElementById
cache vs hard
Fetch cache (default) vs no cache (no-store)
Fetch cache (default) vs no cache (no-store) GET method
Comments
Confirm delete:
Do you really want to delete benchmark?