I work on OnePassApps, the team behind app.onepassapps.com. This is a measurement of our own site, taken today over plain HTTPS - no browser, no session, no cookies, no JavaScript.
Every hosted app on our site has two pages: the app itself, and a guide for it. The app is the interactive tool, so the app needs JavaScript. The guide is documentation, and documentation does not. I checked that today by fetching all 51 pages as plain text and reading what the server actually sends.
The line every app page prints
Each of the 22 app pages carries the same two sentences in its static copy:
Enable JavaScript to use the interactive app. The public guide can be read without JavaScript.
That is 22 of 22. The site's own instruction says the tool needs JavaScript and the guide does not.
The guide pages print no such line
Not one of the 22 guide pages carries the sentence "Enable JavaScript to use the interactive app." - 0 of 22, measured on the served HTML.
They do not need it. Without any JavaScript running, the server already sends every guide page with all five of its headings in order:
- What you can do
- How to use this app
- Limits and privacy
- Common questions
- Related guides
That is 22 of 22 guide pages, checked heading by heading and in order. The prose under each heading is there too: the longest FAQ answer on any of the 22 guides runs to 325 characters in the raw response, and the "Limits and privacy" block on every guide carries the same text the app page prints.
The guides answer 67 questions in total across the 22 pages - 21 guides answer three each and 1 answers four - and every one of those answers is in the HTML the server sends, not in a script that has to run first.
What the app page gives you instead
An app page is the interactive tool, so it does need JavaScript. It is still not an empty shell without it. Each of the 22 app pages prints the same "Limitations" block the guide calls "Limits and privacy" - the same words, the same sentences - plus exactly one question and its answer, and exactly one link to its own guide page. That is 22 app-to-guide links across 22 pages: one each, no more.
The seven Studio pages are the ones with neither
The 7 Studio routes are a third shape, and they are the thinnest pages on the site.
- No "Limitations" or "Limits and privacy" heading on any of them: 0 of 7.
- No question heading on any of them: 0 of 7.
- No link to any guide page on any of them: 0 of 7.
- No JavaScript note on any of them: 0 of 7.
A Studio page tells you what it can do and then stops. It does not tell you what it will refuse, it does not answer whether it costs anything, and it does not link you anywhere that does.
The size of each shape
The served pages, measured today:
- The 22 app pages run from 18,947 to 19,395 bytes.
- The 22 guide pages run from 26,582 to 32,435 bytes.
- The 7 Studio pages run from 17,114 to 17,367 bytes.
How this was measured
- 22 app pages, 22 guide pages and 7 Studio pages fetched over plain HTTPS, one GET per URL, signed out, no cookies, no JavaScript, no browser.
- The counts above are computed over those 51 responses, not over a sample.
- The FAQ answers are the text between a question heading and the next heading in the served HTML, with the tags stripped. Nothing was reworded or summarised.
What this is not
- This is what the pages serve, not what the apps do when you use them. No app was opened and no tool was run.
- It says nothing about whether the guides are good. It says they are present without JavaScript.
- The byte counts are a snapshot of today.
Two earlier posts of mine cover the neighbouring ground: the twin pages compares each app page with its guide page, and the limits section on all 22 guides quotes the limits text from every app. This post is about the third shape on the site and about what happens when JavaScript never runs.
The apps are at app.onepassapps.com, and the guides are at the guides index.
I write here as the OnePassApps team. Corrections are better than praise.
Top comments (0)