This document now also holds everything that is with Austin (section 10). Kevin and Kamil each have a separate brief; anything in those briefs marked "Austin to approve" is listed in section 10 as well.
The homepage appears quickly and then, for about a second, is too busy running its code to act on a click. That is what visitors feel as "slow". It is fixable in roughly three to four days of engineering without removing any advertising pixel, and it should ship before ads start. Separately, the page has six purchase buttons with four different labels, no purchase button in the header, and after the pricing card the only one is a small floating card. Most of those fixes are cheap and standard.
| Measure | Now | Good is | Verdict | What it means |
|---|---|---|---|---|
| GTmetrix grade | C performance 61, 62, 63 structure 84 and 87 | A | Poor | GTmetrix is a free speed-testing service. The grade combines a performance score (70% weight) and a structure score (30%). Structure in the mid 80s is fine; performance in the low 60s is what pulls the grade to C. Three runs, same answer. |
| Largest Contentful Paint (LCP) | 925 to 1,100 ms | under 2,500 ms Google standard | Good | How long until the biggest thing on the screen has appeared. About a second is fast. |
| Total Blocking Time (TBT) | 897 to 1,100 ms | under 200 ms Google standard | Poor | After the page appears, the browser runs the page's code. While it does, a click is not acted on until it finishes. TBT adds up every such moment. Here they add up to about a second. GTmetrix attributes about half to third-party scripts; the other half comes from scripts served from hypertune.gg addresses: Hypertune's own code, and possibly Clerk, which is served from clerk.hypertune.gg and may be counted as first-party. The profile in step 0 splits it. |
| Cumulative Layout Shift (CLS) | 0 | under 0.1 Google standard | Perfect | Whether things jump around as the page loads. They do not. |
| Speed Index | 3.0 s | under 1.3 s GTmetrix standard | Poor | How quickly the visible part of the screen fills in, averaged over the load. The headline appears at about a second; something on the first screen keeps painting until 3 seconds. The likely cause is the hero animation, but the report does not say which element, so this is a hypothesis for the profile in step 0 to confirm. |
| Main thread busy | 12.9 s 7.7 s of it running code | as little as possible | Poor | The main thread is the part of the browser that does everything, including reacting to clicks. 12.9 seconds of work for one page is heavy. The report does not split this between Hypertune's code and third parties; the profile in step 0 will. |
| Total page weight | 4.45 MB 120 requests · 7.94 MB unpacked | under 3 MB our target; GTmetrix flags this 4.43 MB run as medium-high | Poor | Everything the page downloads: video 1.73 MB, code 1.26 MB, images 854 KB, fonts 496 KB. Sections 2 and 3 take it apart. |
| Fully loaded | 26.7 s browser's "load" event at 4.2 s | n/a | Misleading | Not a visitor problem. One request to Hypertune's own logging server (loggregator) was still open when the 26.7-second test ended, so GTmetrix waited for it. Fix is small; see section 2. Until fixed, ignore this number. GTmetrix also reports "Time to Interactive" at 13.2 s; the hanging request may contribute, but the cause is not established and the profile in step 0 should say. |
| Real visitors, median page load | 1.7 s | under 1.2 s our target | Fair | From Hypertune's own tracker, 92,704 page views. Half of real visits finished loading in under 1.7 s. The 1.2 s bar is ours, not a standard. |
| Real visitors, mean page load | 2.3 s | under 2.0 s our target | Fair | The average is pulled up by slow visits, mostly from distant countries and slow connections. |
Plain version. The page appears quickly, then for about a second it is too busy to respond. A visitor who clicks "Boost my performance" in that second waits until the browser catches up, and that is what people mean when they say the site feels slow.
Two caveats. Three desktop runs (19 and 20 Sep) gave performance 61, 62 and 63 and TBT 897, 1,000 and 1,100 ms, so single runs move by up to about 25% and fixes should be judged on three runs each time. All tests were desktop, which is the right test here: Hypertune is a Windows application, so its buyers arrive on desktop.
JavaScript is code that runs inside the visitor's browser. The site cannot show its buttons, pricing card or login without some of it. But every kilobyte has to be downloaded, unpacked and run before the page responds, and this page ships a lot. Sizes are given two ways: compressed (what travels over the network) and uncompressed (what the visitor's computer actually has to process). The second is the one that costs blocking time.
Source for this section: sizes measured from the live site on 19 Sep (compressed and uncompressed); file counts and the third-party blocking figure from the GTmetrix waterfall of 20 Sep, which shows about 490 KB compressed for the same 27 first-party files.
| # | What | Compressed | Uncompressed | Fix | Target |
|---|---|---|---|---|---|
| 1 | Hypertune's own site code: 27 files loaded on the homepage | 530 KB | 1.72 MB | Largest single item. Run a bundle analysis (a bundle is the packaged set of code files a site ships; the analysis is a report of what is inside) to find code the homepage does not need. Ship only homepage code on the homepage; load the rest when it is needed. New 21 Sep: the Lighthouse per-file table names one file, 17ergwwkwjtuu.js (64 KB), as 12.3 of the 19.5 seconds of script execution in that run, about 63%. Start the analysis with that file. | Under 300 KB compressed (our target) |
| 2 | Google tag (GA4, analytics) | 176 KB | 527 KB | Keep. Load it 2 to 3 seconds after the page is usable, or on the first scroll or tap. | Off the critical path (the chain of work the browser must finish before the page responds) |
| 3 | Facebook pixel, two files | 110 KB + 81 KB | 422 KB + not measured | Keep. Same deferred load. | Off the critical path |
| 4 | Clerk (login and accounts) | 365 KB six files plus two calls to Clerk's servers | not measured | More than first thought: the full report shows six Clerk files load on the homepage, not two. Keep. See the note below; this fix is an engineering question, not a one-liner. | Not loaded for first-time visitors |
| 5 | X pixel, Reddit pixel | small | 62 KB · 21 KB | Keep. Same deferred load. | Off the critical path |
| 6 | Clarity (heatmaps) | small | small | Keep. Already loads late. | No change |
| # | What | Evidence | Fix | Owner |
|---|---|---|---|---|
| 7 | Code downloaded but not used | 513 KB of the code downloaded was not run during the measured page load (GTmetrix "unused JavaScript"; counts first- and third-party scripts together, and some may be used later on scroll or click) | Part of the bundle analysis in item 1. An upper bound on what the split can remove. | Kevin |
| 8 | Long tasks | 20 stretches where the browser was busy for over 50 ms without pause | Same fix as item 1; the profile in step 0 says which code | Kevin |
| 9 | Fonts | Four Inter Display files, 496 KB in total (134, 111, 111 and 139 KB) | Subset the fonts to the Latin characters the site uses; typical result is 25 to 35 KB per file. Consider loading only Regular and Bold at first. | Kevin |
| 10 | Page size | 1,550 elements on the page | Moderate. Sections hidden until clicked (carousels, FAQs) could be rendered on demand. Low priority. | Kevin |
| 11 | Double redirect | www.hypertune.gg redirects to hypertune.gg (301), which redirects again (308) before the page loads: 200 ms before anything happens | Make it one hop, and decide which address is the official one. Check that Google and the ad accounts point at the official one. | Kevin |
| 12 | Rejected tracking call | In the 20 Sep test the browser sent a "conversion" event to the site during homepage load and the server refused it (HTTP 422). Nobody sees this; it is wasted work and may mean an event is being lost. Check whether it happens on every load. | Find out what sends it and either fix or remove it | Kevin |
| 13 | Logging request that did not complete | A "POST events" to loggregator.hypertune.gg stays open for the whole 25-second test | Have the server reply immediately, or send the event in a way that does not wait for a reply. Small fix; also makes the GTmetrix "fully loaded" figure honest. | Kevin |
| 14 | Pre-loading of other pages | The homepage fetches the Technology, Tutorial, Expert Tuning, Sign In, Onboarding and Sign Up pages in the background, several of them twice: about 20 extra requests | Standard behaviour of the site framework (Next.js). Change navigation links to pre-load on hover rather than on page load. | Kevin |
| 15 | Short cache lifetimes | 202 KB of files are re-downloaded on return visits that could be kept | Tell the browser to keep static files longer (a setting on the server, called cache headers). Low. | Kevin |
| 16 | Animations on the main thread | 10 animated elements run on the main thread rather than the graphics processor (GTmetrix "non-composited animations") | Candidate cause for the 3.0 s Speed Index alongside the hero video. Check in the step 0 profile; usually a small CSS change. | Kevin |
A pixel is a small piece of code from an ad platform (Facebook, Google, X, Reddit) that records that someone visited, and later that they bought. Ad platforms use it to measure campaigns and build audiences for retargeting. Everyone running ads has them. Nobody is suggesting removing them.
Facebook and Google together are 950 KB of code the visitor's computer has to run. GTmetrix measured all third-party scripts together at 512 ms of blocking out of about 1.0 s, so they are roughly half the blocking; the rest comes from hypertune.gg addresses, mostly Hypertune's own code. The fix is to load them a couple of seconds after the page is usable instead of at the very start, which is how most well-built sites do it.
Purchase tracking should be unaffected: the buy event fires on the checkout pages, long after any delay. Kevin should confirm that the checkout pages load the tags themselves and that campaign parameters carry through. Page-view counts will drop by the share of visitors who leave in the first 2 to 3 seconds, and retargeting audiences shrink by the same share. That share can be measured in Hypertune's own analytics before deciding. Ads can still run on day one.
Clerk is the login and account system behind Log In, sign-up and the customer portal. Essential on those pages. The homepage loads it for everyone so the header can show "Log In" or the account menu. Loading it only when needed means the header has to decide logged-in state another way (a cookie). That is a real engineering task and Kevin should size it; it may be the right fix or it may not be worth it.
Microsoft Clarity is a free tool that records where people click, how far they scroll, and replays of real visits. It is already installed. It is the activity map for section 5. Access has been requested.
Source: live-site inspection 19 Sep; GTmetrix 20 Sep audits put the image savings at 322 KB from right-sizing and 101 KB from modern formats, on a normal screen. Targets marked "our target" are ours.
| Asset | Now | Issue | Fix | Target |
|---|---|---|---|---|
| Hero video (the animation behind the headline) | 1.75 MB, plays automatically, no still image | Starts downloading the moment the page opens, competing for bandwidth with the code above in the first seconds. Biggest single file on the page. | Add a poster (a still image shown instantly, under 60 KB). Start the video after the page is usable. Re-encode smaller. | Under 800 KB (our target) |
| Nine game logos | On a normal screen 63 KB each, 570 KB total. On a high-resolution screen (most gaming laptops and 4K monitors) 138 KB each, 1.2 MB total. Load as you scroll. | Built correctly, but the quality setting is 95 out of 100, far more than a small logo needs. Source files are 1,023 x 1,537 px PNGs at 1.77 MB each. | Re-export sources at 528 x 792 px, WebP format, quality 75 to 80. | Under 40 KB each · under 360 KB total on any screen |
| Two "before and after" clips further down | 1.34 MB · 252 KB | None. Correctly set to load only when reached. | No change | As is |
| Two FPS comparison images (LowFPS.png, HighFPS.png) | 183 KB · 164 KB, 347 KB together | New finding. These two bypass the site's image optimiser, which every other image goes through, so they arrive as raw PNGs at full size. | Route them through the optimiser like the rest, or export as WebP. | Under 40 KB each |
| Small CTA video | 120 KB | None | No change | As is |
| The page itself (HTML) | 56 KB compressed (20 Sep run) | None | No change | As is |
Estimates are ours and need Kevin's confirmation. Expected results are directional until step 0 gives us a profile.
All of this can ship before 29 September, independent of the purchase-completion event. It should ship before any layout test in section 5 starts, so the two do not confuse each other's results. Real-visitor load time already exists in Kevin's database (analytics_pageviews.load_time_ms); once Kevin confirms which browser event it records, it should be a dashboard tile.
The homepage has one job: turn a visitor into a subscriber. Every button that leads toward the checkout is a "call to action", CTA for short. Here is where they are today, from the page's code.
| Position on page | Button text | Where it goes (corrected 21 Sep, traced hop by hop) |
|---|---|---|
| Header (top bar, always visible) | Log In · Discord | No purchase button |
| Hero (first screen) | Boost my performance | /onboarding, which redirects to /get-started: a three-step page (Select a plan, Sign up, Checkout) with no plan chosen |
| Mid page, after features | Boost my performance · Unlock Performance | Same: /onboarding, then /get-started |
| Pricing card (mid page) | Boost my performance | /onboarding?plan=year, which redirects straight to the sign-up form (/sign-up) with the annual plan carried in the address, skipping plan selection |
| Floating widget, bottom right | Claim now · "50% OFF, limited time" | Same as the pricing card: straight to the sign-up form |
| Footer | Try for free (small text link) | /onboarding?trial, which redirects to /get-started with an empty trial marker |
| Bottom of page | Nothing | Page ends on Join Discord, Join the team, footer |
Two things the trace showed. Campaign parameters (utm, gclid) and the plan survive the redirect into the sign-up address; whether they survive account creation into the Stripe record is not yet confirmed and is now Kevin's first data item. And the hero and the plan buttons land on different screens, so "one label everywhere" (recommendation 2) should come with one destination.
Six purchase buttons in total, counting the floating card's "Claim now", with four different labels and three different destinations. Corrected 20 Sep: an earlier version said seven; the seventh tracked button is the Discord link on the pricing card, which is not a purchase button.
These are reach figures: how many people got to each page, not which button took them there. Every button already reports a click event with its own label (cta_click), so Kevin's database can say exactly which buttons get clicked. That per-button count is the first thing to pull, and it belongs in this report before any layout is moved.
Sequence. Items 1, 2, 3(a) and 6 are standard practice and low risk, and Austin agreed in principle on 19 Sep that they can ship without a test, subject to his check with the devs on timing. They do change the page, so the per-button click counts should be pulled before they ship, so we can see the before and after. Items 4 and 5 change how the page reads and should be tested against the current layout once the purchase-completion event is live and the Clarity click and scroll maps have been captured, so we know where people actually stop before we move anything.
Both pages are small, and both are reached mainly by clicking the top navigation from the homepage.
| Page | Share of all sessions | Arrive here first | Who sends them |
|---|---|---|---|
| /technology | 3.3% | 13% of its views | No referrer 135 · VideoCardz 131 (their article linked to this page) · Google 34 · ChatGPT 10 |
| /expert-tuning | 6.3% | 28% of its views | No referrer 733 · checkout.compready.gg 85 · Brave 83 · Google 75 |
"No referrer" means the browser did not say where the visitor came from: a typed address, a bookmark, or a link from an app such as Discord or a chat. Two things worth knowing: VideoCardz linked to /technology rather than the homepage. And 85 people a month arrive at /expert-tuning from a link on checkout.compready.gg, the old Comp Ready checkout, which confirms that page is still live and pointing people here. Neither page is worth optimisation time now; the homepage is 88% of search entries and 72% of all sessions.
cta_click events, last 30 days.load_time_ms in the analytics table.A second team ran a checklist review of the site on 21 Sep (mobile Lighthouse 13.5, axe accessibility scan, a cold walk from the hero button to the sign-up form). Most of what it found is already in this report. The items below were not. Each carries one of three flags.
| # | Finding | Evidence | Why it matters | Owner | Flag |
|---|---|---|---|---|---|
| N1 | The FAQ promises a trial the main buttons do not offer | Live page, FAQ: "We offer a 7-day free trial so you can see the results for yourself before ever being charged." The trial was taken out of the default checkout on 5 Aug and kept, by design, behind the footer "Try for free" link and /try4free. Every other purchase button charges immediately. | A visitor reads "free trial", clicks Boost my performance, and meets a checkout with no trial. Confusing today; a complaint once ads bring in strangers. | Austin, then Kamil (copy) | Austin decides qualify the FAQ line ("via the Try for free link"), or make the trial visible in the main flow |
| N2 | Parameters may not survive to billing | Traced 21 Sep: plan, utm_source and gclid reach the sign-up address. Nobody has confirmed they reach the Stripe customer record after account creation. | If they do not, no button test can be read and paid campaigns cannot be attributed to purchases. Must be settled before ads start. | Kevin | No approval needed Kevin verifies, fixes if broken |
| N3 | One code file carries most of the script time | Lighthouse per-file table (21 Sep run): 17ergwwkwjtuu.js, 64 KB, 12.3 of 19.5 s of script execution (63%). | Gives Kevin's step 0 a named starting point; the bundle work may be much smaller than two days. | Kevin | No approval needed |
| N4 | "How it works" step 1 says "Download Hypertune" | Live page. The button that step describes leads to plan selection and account creation, not a download. | Visitor expects an installer, gets a sign-up form. A specific reason to leave. | Kamil | Austin decides the replacement wording (one line) |
| N5 | Price unit text fails contrast | axe and Lighthouse: "/month" and "/year" at 30% white on dark; feature descriptions at 50%. Nine contrast failures in total. | The text that tells a buyer which price is which is the hardest to read on the card. | Kamil | No approval needed |
| N6 | Heading order and button labels | One heading level skipped (game titles); three buttons whose spoken label differs from their visible text (Claim now, the two plan toggles). | Small. Affects screen readers and keyboard users. | Kamil | No approval needed |
| N7 | Typo | "processess" in the features list. | Paid landing pages get judged on details. | Kamil | No approval needed |
| N8 | Sign-up form asks for too much at once | Cold walk: email, password, Discord and Google offered together, title "Sign Up". | Four choices before anyone has seen value. Discord-first with password off step 1 is the usual pattern for this audience. | Kamil (Clerk settings) | Discuss with Austin which sign-in options to lead with, and the form title |
| N9 | No events between click and purchase | Only cta_click exists before the purchase event. Nothing records sign-up viewed, started, failed, completed. | Without them we cannot see where the drop between click and purchase happens. | Kevin | No approval needed |
| N10 | Mobile speed | Lighthouse mobile run, 4x CPU throttle: performance 34, LCP 18.4 s. Excluded from this report because the product is Windows-only. | Answered 21 Sep from the dashboard's traffic page: phones are 9% of visits over 90 days (desktop 90%, tablet 1%). Too small to justify the work while the product is Windows-only. | Vinson | Discuss with Austin proposal is to leave mobile out; revisit if paid social sends phone traffic |
| N11 | Ad-to-page message match | Not a page finding; a rule for the campaigns about to start. | Each ad's promise should be repeated by the headline and first button it lands on, or paid clicks bounce. | Vinson, Austin | Discuss with Austin when campaigns are planned |
Three claims from the second team need a browser check before they become tasks: duplicate pricing and "How it works" blocks (the page code holds each twice, back to back, which usually means desktop and mobile variants rather than two visible sections), a countdown on the 50% widget (not present when we looked), and a blank first paint on the sign-up page. Kevin's brief has them as a ten-minute check.
Already covered before 21 Sep and therefore not listed above: Clerk on the homepage, deferring the pixels, blocking time, unused code, one label, the widget's urgency and comparison price, the hero button test, Clarity before moving layout, GA4 events, redirects, third-party cookies, and the proof and trust claims (with Austin, and parked to Wednesday).
Everything below is with Austin. Each item says what it blocks. Kamil's brief is ready to forward; Kevin's brief has been reissued with the 20 and 21 Sep findings and is also ready.