Loading...
Ready to test your patience?
Elapsed
0s
Remaining
--:--
Speed
0%/s
Target
1 hour
Fun fact: This loading bar uses an exponential decay function!
The formula: progress = 100 × (1 - e^(-0.00128 × time))
Most people give up around 80%... will you make it?
About The Infinite Loading Bar
Infinite Loading is a browser-based utility that renders a progress bar completing over a duration of exactly one hour, or 3600 seconds. It serves as a high-fidelity reference for long-duration timing on the web, leveraging modern browser APIs to achieve precision and performance. The tool provides a stable, predictable baseline for developers, researchers, and engineers studying user perception of time, front-end performance, and the implementation details of web standards.
The core of the tool's precision lies in its use of the High Resolution Time API[13], specifically the `performance.now()` method. Unlike `Date.now()`, which is based on the system clock and susceptible to drift and adjustments, `performance.now()` provides a timestamp from a monotonic clock[5] that increases consistently from the moment the page navigation begins. Animation updates are scheduled using `requestAnimationFrame`, which synchronizes rendering with the display's refresh rate[6]. This is crucial for smooth visuals and is managed by the browser's event loop[3] to ensure updates occur just before the browser repaints the screen, providing a more efficient and visually stable result than legacy methods like `setInterval`.
The visual progress bar is implemented as a `<div>` element animated using the CSS `transform` property. Specifically, `transform: scaleX()` is updated on each animation frame. This technique is chosen for its performance characteristics, as `transform` is a property that can typically be handled by the browser's compositing[2] thread, often with GPU acceleration. This avoids triggering a full layout reflow and repaint[1] cycle, which would be caused by animating properties like `width` or `margin`. By isolating the animation to the compositing layer, the tool minimizes its impact on the critical rendering path and ensures a low CPU footprint over its one-hour execution.
Progress indicators are a foundational component of Human-Computer Interaction[4] (HCI), designed to manage user expectations during delays. Early examples include the animated throbber[9] from browsers like Netscape Navigator. Research in HCI has established that providing feedback for system processes is critical for usability. The perceived duration of a wait can be manipulated by the design of the progress bar, with non-linear or pulsating bars often feeling faster than a linearly progressing one. This tool's perfectly linear, hour-long progression provides a stark, unadorned representation of time, serving as a scientific control for experiments in perceived performance and user psychology.
While a custom `<div>` is used for animation performance, the tool adheres to accessibility standards by incorporating attributes from WAI-ARIA[10], the standard for Accessible Rich Internet Applications. The element is assigned `role="progressbar"` along with `aria-valuenow`, `aria-valuemin`, and `aria-valuemax` to communicate its state to assistive technologies like screen readers[7]. This approach balances custom visuals with the semantic clarity offered by the native HTML `<progress>` element, which is defined in the WHATWG HTML Living Standard[15]. Furthermore, the tool respects device resources by implicitly using the Page Visibility API[14]; when the tab is inactive, `requestAnimationFrame` callbacks are paused by the browser, conserving CPU and battery life until the tab is visible again.
How to Use
- Load the page in your web browser.
- The progress bar begins filling from 0% immediately upon page load.
- The animation is driven by `requestAnimationFrame` for smooth visual updates.
- Progress is calculated against a total duration of 3600 seconds using the High Resolution Time API.
- The bar will reach 100% after exactly one hour has elapsed.
- If the tab is backgrounded, progress calculation continues and the bar will update to the correct state upon your return.
Frequently Asked Questions
How is the one-hour duration measured so precisely?
It uses the `performance.now()` method from the High Resolution Time API[13]. This provides a timestamp with sub-millisecond resolution based on a monotonic clock[5], which is not affected by system time changes, unlike `Date.now()`.
What happens if I switch to another tab or minimize the browser?
The animation, driven by `requestAnimationFrame`, will pause to conserve CPU and battery, as handled by the browser in accordance with the Page Visibility API[14]. However, the elapsed time is calculated from a start timestamp. When you return, the progress bar will jump to the correct position based on the total time elapsed.
Why does this tool exist?
It serves as a reference implementation and educational tool for several web technologies. It demonstrates precise long-duration timing, efficient browser animation, the trade-offs of different rendering techniques, and principles of Human-Computer Interaction[4] related to perceived performance.
Is the progress bar implemented with CSS, SVG, or Canvas?
This implementation uses a `<div>` element whose `transform: scaleX()` CSS property is updated. This is often more performant than animating the `width` property because it can be offloaded to the GPU for compositing[2], avoiding costly layout reflows[1] on each frame.
Why not use the HTML `<progress>` element?
While the native `<progress>` element, part of the WHATWG HTML Living Standard[15], is excellent for accessibility[11], it offers limited styling capabilities. This tool uses a custom element to demonstrate fine-grained animation control and performance optimization, while implementing accessibility manually via WAI-ARIA[10] attributes.
How does this relate to the JavaScript event loop?
The animation is scheduled using `requestAnimationFrame`, which places a callback in a queue to be executed by the event loop[3] just before the browser's next repaint. This ensures the animation is smooth and synchronized with the display's refresh rate[6].
Could a Web Worker be used for this?
Yes, a Web Worker[12] could manage the timing logic in a separate thread to prevent any possibility of blocking the main UI thread. However, for a simple calculation like this, `requestAnimationFrame` on the main thread is sufficiently efficient and avoids the complexity of worker communication.
What is the theoretical limit on the timer's accuracy?
The accuracy is primarily limited by the resolution of the High Resolution Time API[13], which can be in the range of microseconds. However, browsers may reduce this precision to mitigate timing attacks like Spectre[8]. The visual update frequency is limited by the display's refresh rate[6], typically 16.67ms for a 60Hz display.
Sources (15)
- Wikipedia: Browser Engine (Layout, reflow and repaint)
- Wikipedia: Compositing Window Manager
- Wikipedia: Event Loop
- Wikipedia: Human-Computer Interaction
- Wikipedia: Monotonic Function
- Wikipedia: Refresh Rate
- Wikipedia: Screen Reader
- Wikipedia: Spectre (security vulnerability)
- Wikipedia: Throbber
- Wikipedia: WAI-ARIA
- Wikipedia: Web Accessibility
- Wikipedia: Web Worker
- W3C Recommendation: High Resolution Time Level 3
- W3C Recommendation: Page Visibility Level 2
- WHATWG: HTML Living Standard (The progress element)
About Matt George
I'm Matt George, a software engineer in the startup space. I run my own shop building software for early-stage founders, and I love making free tools and experiences that people actually use. Enjoy using The Infinite Loading Bar!