A 30-line userscript that strips a recipe page down to the recipe

A 30-line userscript cut an Allrecipes cookie page from 461 requests and 9.63 MB to 26 requests and 0.91 MB while keeping all 11 ingredients and 9 steps; the ingredients had started 6.17 screens down, and turning the script off brought the full page back.

Score

10.0/10

claims that held up

Verdict

Reproduced

4

Access needed

L0 Public web only

Run 23 Oct 2026

We re-ran it and got the claimed kind of result, checked against ground truth.

4

claims scored

all tested

4 of 4

held up in full

1

sites and APIs touched

about 4 minutes

run time

Claim by claim

The page makes you scroll several screens before the ingredientscoreHeld up

6.17 screens (4,939 px at 1280x800) on both loads without the script.

A ~40-line userscript keeps only the recipecoreHeld up

30 lines; 11 of 11 ingredients and 9 of 9 steps, as in the page's recipe data.

Requests and MB drop massivelycoreHeld up

461 to 26 requests (-94%), 9.63 to 0.91 MB (-91%). Not as low as the post's 14 and 0.4 MB.

Turning the script off brings the full page backcoreHeld up

447 requests, 13.0 MB, same page height as before.

Open a claim to see what we checked.

Access it needs
L0 Public web only
Run on
23 Oct 2026, 08:18 to 08:21 (UTC+8)
Run by
Grok Bot
Check again by
22 Nov 2026

What was claimed

'This cookie recipe page makes you scroll 6.4 screens to reach the ingredients, so my agent (Grok Bot) wrote a 40-line userscript that keeps only the recipe. Same page after: 823 requests became 14. 13.9 MB became 0.4. Turn it off and the full page is back.'

@LankC11 on X. Original post

What we found

It works. The ingredients started 6.17 screens down. With the 30-line script the page needed 26 requests instead of 461 (-94%) and 0.91 MB instead of 9.63 MB (-91%), and showed all 11 ingredients and 9 steps. With the script off, the full page came back (447 requests, 13.0 MB). We did not get as low as the post's 14 requests and 0.4 MB: the leftover requests are files the server asks the browser to preload in its response headers, which a userscript cannot stop, plus our one re-read of the page.

How we checked it

Browser network counts (Chrome DevTools Protocol) saved per load as JSON with screenshots; ingredients and steps compared with the page's own schema.org Recipe data. Answer key written 08:18:13 UTC+8, before the run.

What the agent did

  1. Load 1, no script: 'Ingredients' heading 4,939 px down = 6.17 screens; 461 requests, 9.63 MB from 146 hosts
  2. Wrote recipe-only.user.js (30 lines): stops the page loading, re-reads its HTML once and shows only the recipe from the page's own recipe data; add ?full=1 to see the full page
  3. Load 2, with script: 26 requests, 0.91 MB from 4 hosts; 11 of 11 ingredients and 9 of 9 steps shown
  4. Load 3, script off: 447 requests, 13.0 MB, page height 20,215 px, same as load 1

Sites and APIs touched: allrecipes.com.

Where it went wrong

  • The first version of the script left a blank page (it rewrote the document after stopping it); the second version fixed it.
  • The recipe data words two ingredients slightly differently from the visible list ('2 eggs' vs '2 large eggs', '0.5 teaspoon salt' vs '½ teaspoon salt').
  • A userscript can't stop files the server preloads, so some requests remain.
  • One page, one load each way; ad-heavy pages vary from load to load (447-461 requests without the script).

Try it yourself

Exact prompt we used
This cookie recipe page makes me scroll forever to reach the ingredients. Write me a short userscript (about 40 lines) that keeps only the recipe, and measure how many screens, requests and MB the page takes before and after. Turning the script off must bring the full page back.

Lowest-access way to try it

L0. Ask for a userscript (Tampermonkey or Violentmonkey) that shows only the recipe from the page's recipe data, with a way to see the full page. Check one ingredient against the original page.

Run details

Status
Reproduced (V2)
Access level used
L0: No account access
Original post's setup
L0
Method
Picked a popular cookie recipe (Allrecipes' Best Chocolate Chip Cookies) because the post did not name its page. Loaded it without the script, with the script, and without it again, 15 seconds each, and counted screens to the ingredients, requests, megabytes and page height. Compared the stripped page with the recipe data the page itself publishes.
Run by
Grok Bot (this assistant) on its own Linux computer with web search/fetch/shell/browser tools; this run: wrote the userscript, then measured with headless Chrome (1280x800 window, network bytes counted by the browser) on a public recipe page (no login)
Agent in the original post
Grok Bot (per post)
Run date
2026-10-23 (UTC+8)
Time
About 4 minutes (08:18:19-08:21:59 UTC+8)
Cost
Not metered (subscription agent); no paid APIs, no purchases
Re-verify by
2026-11-22

How to cite

TriedAgents, "A 30-line userscript that strips a recipe page down to the recipe", reproduced, checked 2026-10-23, https://triedagents.com/cases/recipe-page-bloat-userscript/

Get one re-run case every weekday

One agent use case we actually re-ran, every weekday. Free.

We only store your email address. Every issue has a one-click unsubscribe link. Privacy