iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A low PageSpeed Insights score does not, by itself, show that a Three.js scene is the problem—or that JavaScript is innocent. Start by checking whether you are looking at a Lighthouse lab score or real-user Core Web Vitals, then identify the weak metric. If Largest Contentful Paint (LCP) is slow, trace the reported largest element and its loading and rendering timeline before changing the 3D scene.
First check what PageSpeed Insights is reporting
PageSpeed Insights (PSI) combines two kinds of evidence: Lighthouse diagnostics from a simulated test and field data from the Chrome User Experience Report (CrUX), which reflects real visitors. The lab result helps investigate a reproducible test; it is not a substitute for real-user performance. Google notes that lab data may not capture real-world bottlenecks. Google’s PSI documentation explains the distinction.
PSI may show data for the tested URL or, when the URL does not have enough CrUX data, data for its origin. Check which level is displayed before treating the field result as representative of one page.
Performance score and Core Web Vitals are different
The PSI Lighthouse performance score is classified as good at 90 or above, needs improvement from 50 to 89, and poor below 50. Those are categories for the lab score, not the field Core Web Vitals assessment.
#1 Best Overall
Core Web Vitals are LCP, Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP). Google’s documented good thresholds are LCP at or below 2.5 seconds, CLS at or below 0.1, and INP at or below 200 milliseconds. The field assessment uses the 75th percentile of eligible data, reported separately for mobile and desktop; where all three metrics have enough data, all three must meet their good thresholds to pass. Google’s PSI documentation describes the score bands and assessment, while Google’s LCP guidance explains the LCP target.
If LCP is slow, find the element before blaming the canvas
LCP measures when the largest visible content element is rendered. On a Three.js page, that element might be a heading, image, or other HTML content rather than the WebGL canvas. The canvas can still matter if its setup or other work delays the browser from rendering the LCP element, but its presence alone does not establish the cause.
Use PSI’s LCP element details, then inspect the page in browser performance tools and the network waterfall. Google breaks LCP into four parts: time to first byte (TTFB), resource load delay, resource load duration, and element render delay. Google’s LCP guide explains these timings.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →- TTFB: How long it takes for the browser to receive the first byte of the HTML response.
- Resource load delay: How long after the response begins before the LCP resource starts loading. A resource discovered late can contribute to this delay.
- Resource load duration: How long the LCP resource takes to download.
- Element render delay: How long after the resource is available before the element is actually painted.
Compare when the HTML arrives, when the LCP resource starts and finishes, and when the element appears. A late resource start points toward discovery or delivery; a long gap after loading points toward work that is keeping the browser from painting. These timings help narrow the problem instead of assuming every delay comes from scene complexity.
JavaScript can still delay an unrelated LCP element
The claim that a poor score is “not JavaScript” needs a qualification: a large JavaScript file can delay LCP even if it neither creates the LCP element nor blocks rendering in the conventional sense. Parsing and executing scripts uses the main thread, where work can compete with rendering. Google states in its LCP guidance that JavaScript can still delay LCP even when it is not render-blocking and does not render the elements.
Inspect main-thread activity around the delayed paint, including large script execution. A Three.js scene that appears smooth on your own device does not rule out JavaScript delaying an HTML heading or image during the PSI run or for visitors on different devices.
Rank #4
Check other causes when CLS or INP is weak
For CLS, look for content that changes size or position
CLS measures unexpected layout movement. Images or videos without reserved dimensions, a font swap that changes text layout, or third-party content that changes size after loading can move nearby content. These issues can harm page experience independently of the complexity of the 3D scene. Google’s CLS guidance describes these causes.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesFor INP, investigate interaction responsiveness
INP measures responsiveness to user interactions. Its good threshold is 200 milliseconds or less; over 500 milliseconds is poor. If INP is the weak metric, focus on the reported interaction and the work occurring around it rather than treating an LCP diagnosis as the answer. PSI documents these thresholds in its Core Web Vitals guidance.
Best Value
A practical diagnosis sequence
- Record the context. Note whether the report is for mobile or desktop, the Lighthouse performance score, each individual metric, and whether field data is URL-level or origin-level.
- Separate lab from field evidence. A poor lab score is a debugging signal; check CrUX field data to understand measured visitor experience when it is available.
- Start with the weak metric. For LCP, identify the reported largest element and find its resource and timing in the report or browser performance tools. For CLS, observe which content moves as assets load. For INP, examine the interaction that is slow.
- For LCP, compare all four timing parts. Check TTFB, resource load delay, resource load duration, and element render delay to distinguish server response, late discovery, slow transfer, and delayed painting.
- Inspect main-thread work. Look for large JavaScript execution, including scene-related code, without assuming it is the cause until its timing matches the delay.
- Check layout stability. Verify that images and video reserve space, observe font swaps, and examine third-party content that changes size after loading.
- Look for patterns across pages. Search Console’s Core Web Vitals report uses actual-user data and groups similar URLs. For a group with enough data, its displayed status reflects its slowest reported metric. See Google Search Central’s Core Web Vitals report documentation.
- Change one plausible cause at a time. Rerun the same metric under comparable conditions so you can tell whether the change helped.
Do not assume PSI always tests Three.js with software rendering
A September 28, 2026 Three.js forum post describes one contributor’s view that Lighthouse and PageSpeed run headless Chrome with software rendering, along with anecdotal advice about shader compilation, profiling, and test variability. It is a community post, not Google documentation: the forum discussion does not establish a universal PSI rendering configuration. Google’s PSI documentation describes simulated mobile and desktop conditions but does not confirm that every run uses software rendering or lacks a GPU. Treat a suspected rendering-environment difference as something to test, not as a settled explanation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
