# Weekly site speed audit that files its own fix tickets > Every Monday we check how fast your key pages load, rank the fixes that would help most, and open tickets only for problems that are genuinely new. - Workflow type: agent - Services: Browserless, Linear, Slack Bot - Categories: Engineering, Marketing - Published: 2026-08-14 ## What it does - Checks your homepage, pricing page and top landing pages every Monday for speed, accessibility, SEO and best practice scores. - Flags any page that falls below the targets you set, then reads the detail and ranks the specific fixes that would recover the most score. - Searches your existing tickets first and only opens a new one for a genuinely new problem, so a recurring issue never gets filed twice. - Posts a single Slack recap with every page's scores and links to any tickets raised, and says plainly when everything passed. ## What you'll need - A Browserless account, which runs the page checks for you in the background. - A Linear workspace, plus the team you want any fix tickets to land in. - A Slack workspace with the bot added to your web team channel. - The list of pages you care about, usually your homepage, your pricing page and your best performing landing pages. ## Prompt Every Monday at 7am, run a Lighthouse audit on each of my key pages and turn the results into action instead of a raw score dump. These are the pages I want checked every week. Replace this list with my real URLs: my homepage, my pricing page, and my top landing pages. Audit each one separately so I get a score per page rather than one blended number. For each URL, use the Browserless Run Lighthouse Audit action and collect the performance, accessibility, best practices and SEO scores along with the underlying metrics. Check every page against these budgets. A page fails if performance is below 80, accessibility is below 90, best practices is below 90, SEO is below 90, largest contentful paint is above 2.5 seconds, total blocking time is above 300 milliseconds, or cumulative layout shift is above 0.1. These are my starting numbers and I will want to adjust them later, so keep them together in one place that is easy to edit. Judge each page against those absolute budgets rather than against last week's numbers. I do not want this workflow to depend on storing history anywhere. A breach is a breach on its own terms, and Linear is the memory for what has already been reported. For every page that breaches a budget, read the individual failing audits inside the Lighthouse result and write a short ranked list of the specific fixes that would recover the most score. Rank by score impact, and name the actual offending resource or element wherever the audit gives it to you, for example the specific oversized image, the render blocking script, or the form field missing a label. Generic advice like optimize your images is not useful to me, so be concrete. Before creating any ticket, use Linear Search Issues to check whether an open issue already covers that page and that problem. Search on the page URL and on the nature of the failure. If a matching open issue already exists, do not create another one, and carry the existing issue link through to the summary instead. This dedupe step matters more than anything else here, because without it I get the same ticket filed every Monday. Only when the problem is genuinely new, use Linear Create Issue. Put the page URL, the failing metrics with their actual values next to the budget they missed, and the ranked recommended fixes into the issue description. Give the issue a title that names both the page and the problem, so that next week's search can find it. Finish with exactly one Slack Bot Send a Message post to my web team channel. Summarize each page's four scores, call out which budgets failed and by how much, and link to any tickets created as well as any existing tickets that already cover a breach. Keep it scannable, with one short block per page. When every page passes, still post the message and state clearly that all pages are within budget. A clean week should read as a useful all clear, not as silence, because silence is indistinguishable from the check never having run. ## How to customize - Change the day and time. Monday at 7am is only a default, and some teams prefer a Friday check before the weekend. - Set your own score targets. Raise the bar if your site lives on search traffic, or lower it while you work through a known backlog. - Add or remove pages whenever you like, and point the tickets at a different Linear team or the Slack channel your web team actually reads. ## FAQ ### Do I need to be technical to use this? No. You give it a list of page addresses and the scores you want to hit. The Slack summary is written in plain language, and each ticket spells out what needs changing, so you can hand it straight to a developer or your agency. ### Will it file the same ticket every week? No. Before it opens anything it searches your Linear workspace for an open ticket already covering that page and that problem. If one exists it links to it in the Slack recap instead of creating a duplicate, so your backlog stays clean. ### What happens on a week when nothing is wrong? You still get the Monday post, and it says clearly that every page passed. A clean week reading as a deliberate all clear is far more useful than silence, because silence could just mean the check never ran. ### How many pages can I check? As many as you like, though most teams start with five to ten: the homepage, pricing, and the landing pages that bring in the most traffic. Every page is checked on its own, so you get a score per page rather than one blended number. ### Where do the scores come from? They come from Google Lighthouse, the same standard set of checks built into Chrome that developers and agencies use to grade a page. Running them on a schedule gives you a consistent weekly reading instead of a one off spot check. Use this prompt in General Input: https://www.generalinput.com/prompts/weekly-site-speed-audit-that-files-its-own-fix-tickets