A page with a heading, a paragraph, and a contact button can look simple while returning a surprisingly expensive document. Its HTML may carry unused data, synchronous scripts, or images whose dimensions are left for the browser to discover. The screenshot does not show any of that.
MachineRead's Crawl Efficiency & HTML Performance check examines the fetched document and response headers for clues worth investigating. It does not load the page in a browser or measure how visitors experience it. That distinction determines what to do with a finding: inspect the flagged condition, then measure the effect of changing it.
Start with the response, not the appearance
The check considers the elapsed audit fetch, caching headers, selected stylesheets and scripts, image and video dimensions, document size, and mobile viewport markup. These components contribute to one three-point Essentials group. They are not separate measurements of loading speed, visual stability, or responsiveness.
A slow audit fetch is a reason to repeat the request and investigate the response path. It is not a distribution of visitor load times. Likewise, the presence of an ETag or Last-Modified header is a useful configuration signal, but MachineRead does not test whether a later conditional request receives the right response. A header can be present while its behavior still needs checking.
For a practical review, compare the same page before and after a change under similar conditions. Keep the HTML and response headers with the measurements. A lower response time from one request is less convincing than a repeated improvement, and a faster fetch does not tell you whether the browser still has expensive work left to do.
A script count tells you where to look
MDN explains that parsing and executing JavaScript can block parsing of the HTML that follows it. Its performance guidance distinguishes ordinary script loading from the behavior of async and deferred scripts (MDN Web Docs).
MachineRead checks a narrower condition: external scripts in the document head that lack async or defer, excluding module scripts. A finding can therefore point to a script worth inspecting, but the count says nothing about that script's download size or execution cost. One large script can matter more than several small ones.
Do not add async indiscriminately to improve the count. First check whether the script depends on another script or on page elements that have not been parsed yet. Change the loading behavior only when it preserves the page's functionality, then verify it in a browser. A cleaner audit result is not worth a broken form.
The stylesheet and media checks need similar interpretation. MachineRead counts selected stylesheet links and looks for explicit image and video dimensions in markup or inline styles. It does not inspect the complete external stylesheet cascade. If a flagged image already has space reserved by CSS, confirm the rendered behavior before treating the markup observation as a visible layout defect.
Document-size limits need a current source
A widely repeated Google figure comes from its June 2022 post, "Googlebot and the 15 MB thing." That post says: "The content after the first 15 MB is dropped by Googlebot, and only the first 15 MB gets forwarded to indexing" (Google, "Googlebot and the 15 MB Thing"). The sentence is historical guidance, not the current limit.
Google's current Googlebot documentation specifies the first 2 MB of supported non-PDF files and the first 64 MB of PDF files, with limits applied to uncompressed data. It also says referenced resources are fetched separately (Google, "Googlebot"). A document-size limit is not a combined budget for every image, stylesheet, and script on the page.
MachineRead's existing size heuristic uses 15 MiB. It must not be read as validation against Google's current threshold, or as a limit shared by all crawlers. A pass on that component does not establish that Googlebot will read the entire document. For a large page, inspect the actual uncompressed HTML and consult the current documentation of the client you care about.
Use a browser measurement for a browser question
The viewport check looks for basic mobile declarations, including device-width and whether the markup restricts zoom. It can also observe selected responsive hints. It cannot tell whether a menu fits a narrow screen or whether an overlay covers the submit button.
Google's web.dev guidance makes a useful distinction: lab data describes how hypothetical users may experience a site, while field data describes how real users experienced it. Lighthouse is a diagnostic tool run under defined conditions; field measurements answer a different question (Google, "Core Web Vitals Workflows"). MachineRead's static proxies are neither of those datasets.
Use the Essentials finding to choose the next inspection. For scripts, examine loading order and browser execution. For media, check whether space is reserved before it loads. For caching, test the response behavior rather than merely the header name. For mobile markup, inspect the page at a narrow viewport and test zoom. Then use appropriate browser or field measurements to determine whether the change improved the experience.
The result should leave you with a specific condition to investigate, not a claim that the site passes or fails Core Web Vitals.
Works Cited
Google. "Googlebot." Google Search Central, https://developers.google.com/search/docs/crawling-indexing/googlebot. Accessed 10 Sept. 2026.
Google. "Googlebot and the 15 MB Thing." Google Search Central, 23 June 2022, https://developers.google.com/search/blog/2022/06/googlebot-15mb. Accessed 10 Sept. 2026.
Google. "Core Web Vitals Workflows with Google Tools." web.dev, https://web.dev/articles/vitals-tools. Accessed 10 Sept. 2026.
MDN Web Docs. "HTML Performance Optimization." MDN Web Docs, https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Performance/HTML. Accessed 10 Sept. 2026.