Analyse a page

Use to measure a page in the lab and find what to fix (scores with their spread, failing audits ranked by what fixing them is worth, real-user data beside them, and a page to send on); for real-user data alone use get_field_data, which is fast, and for "did that change help" use compare_to_baseline. include picks the parts, "scores", "issues", "field_data" and "html", default all four. ONE MEASUREMENT SERVES EVERY PART, so asking for more costs no extra API calls, while asking in separate calls measures again. SLOW, several minutes. It reports the MEDIAN of several DISTINCT analyses with the min-max spread, so the number comes with its uncertainty. A single Lighthouse run is noise, Total Blocking Time swings threefold between runs on an unchanged page, so runs=1 is fast but its score is not a reliable figure. Google re-analyses a URL only about once a minute and replays the cached result in between, so this keeps asking until it has genuinely different analyses rather than the same one several times. That means runs=5 takes roughly 150 seconds and asking harder will NOT speed it up. Reports fewer analyses honestly if time runs out. Anything that will not fit inside one tool call returns a JOB ID instead and keeps working: collect it with get_job_result, polling about every 15 seconds. Only runs=1 on a single URL with include ["scores"] answers immediately, and that is the noisy single run described above. ISSUES are what is FAILING on the page, from Google's own audit findings and remediation text. Only a fault that failed in EVERY distinct analysis is reported, because audits are as noisy as scores and a one-off failure is the instrument moving rather than a fact about the page. Estimated savings carry their median and spread for the same reason. Ranked by what actually moves the score: the performance score is five metrics and every other performance audit weighs zero, so a big estimated saving on an unweighted diagnostic is not the first thing to fix. Savings do NOT add up, they overlap, so the order is meaningful and the sum is not. FIELD_DATA is real-user data if Google has any. HTML is a complete self-contained page carrying all of it, made to be saved as a file the user can open or forward, because several of the largest findings are usually hosting or third-party decisions that the person running the check cannot fix alone. Set html false if they only want the answer in conversation. TO SAVE IT AS A FILE, pass directory, a folder on the user's own machine that the report is written into. The server writes into whichever existing folder directory names and does not check where that path came from. The folder is checked BEFORE the measurement starts, which takes minutes, so a folder that does not exist or cannot be written to is refused at once. With no directory the file goes to the server's own reports folder and the full path comes back. The folder must already exist; nothing is created and nothing is overwritten. Saved files keep their embedded fonts and are about 150KB; the copy returned in conversation drops them to stay small, so a saved file is the fuller of the two. Returns a readable report and the same figures as JSON.