Open your analytics and sort landing pages by sessions. On most stores that already sell, the homepage is not first, and often it is not close. Paid shopping traffic lands on product pages. Search lands on product and collection pages. Social and email land on whatever was linked, which is a product. The homepage collects brand searches, direct visits and the people who typed your name.
Now look at where the speed work goes. It goes to the homepage, because that is the page everyone in the business sees every day, the page the founder shows people, and the page the redesign was about.
That mismatch is the argument. Page speed is worth money at the point where a buyer is deciding, and that point is the product page. It is also the page most likely to be slow, because it is where every app, widget, gallery and review script gets installed. Fixing the homepage makes the team happy. Fixing the product template makes the orders happen.
Your entry points are not where you think they are
Before changing anything, get the actual list. In your analytics, pull landing pages for the last ninety days, split by device, and group them by template rather than by individual URL. You want to know what share of sessions start on a product page, a collection page, the homepage, a blog article and everything else.
Then add money to it. Sort the same list by revenue and by sessions from paid sources, because a page that receives paid traffic has a cost attached to every second of delay. A slow page you pay to send people to is worse than a slow page people find for free.
Most stores get a surprise here. The single busiest page is usually one collection or one hero product, and the top handful of product pages carry a large share of paid landings. That is a short, specific list, and it is a much better brief than make the site faster.
Do the same for your ad landing pages. If your shopping campaigns send people to product pages, then product page speed is part of your cost per acquisition, not part of your web project.
Optimising the homepage means optimising the page your buyers are least likely to see.
The homepage is the page your team sees and your buyers skip
There is a simple reason homepages get the attention. Everyone internal starts there. The designer built it, the founder opens it, the agency screenshots it, and every conversation about the site begins with someone loading the front page on a laptop with a fast connection.
Buyers behave differently. Someone searching for a specific product does not want your brand story, they want the product, and the search engine or the ad takes them straight there. Someone clicking an email link goes to the item in the email. Someone on social goes to the thing in the video.
The homepage still has jobs. It carries brand traffic, it orients people who are browsing rather than buying, and it is often the page that gets shared. Those are real, and none of them are the same as being the main entry point.
So the honest position is not that the homepage does not matter. It is that homepage speed should be prioritised according to how many people land on it and what they do next, exactly like every other template. Ranked that way, it usually sits behind the product page and often behind the top collection.
Product pages are heavy because that is where everything gets installed
Product templates accumulate. Over a couple of years, a page that started as photos, price and a button ends up carrying an image gallery with zoom, a review widget, a size guide, a stock-scarcity notice, a bundle app, a recently-viewed carousel, a live chat launcher, a currency switcher, an upsell block and two or three tracking scripts.
Each was added for a reason and each was measured on its own, if at all. Nothing measures the combined weight, and the combined weight is what the buyer experiences. Third-party scripts are the usual culprits, because they load code you do not control, from servers you do not control, often before your own content can finish rendering.
Images are the other half. A product page is by nature image-heavy, and it is easy to ship a gallery where all eight photos load at full resolution on a phone that will show one.
So the audit is concrete. List every script and app on the product template. For each, ask who uses it, what it earns, and whether anything would break if it were removed. Most stores find at least one app that is still loading for a feature nobody has used since it was installed.
Fix the product template in this order
The order matters, because the first two items usually account for most of the delay.
Start with the main product image. It is almost always the largest element the visitor waits for, so it should be served in a modern format, sized for the device, and loaded eagerly. Every other image in the gallery should be loaded lazily, because the visitor will not see them until they swipe.
Second, deal with third-party scripts. Remove what is unused, defer what is not needed for the first view, and load anything that only matters after interaction on interaction. Review widgets and chat launchers are the two that most often block the initial render for no benefit.
Third, reserve space for anything that loads late, so the page does not shift under the buyer's thumb as they reach for the add-to-cart button. Layout shift on a product page is not just an annoyance, it causes mis-taps into the wrong variant.
Fourth, look at fonts. Custom fonts loaded without a fallback delay every word on the page.
Only then look at theme code, because that is the expensive part and it usually moves the number least.
Speed is a conversion number and a traffic number at once
The conversion side is the obvious half. A page that takes too long to become useful loses people who came to buy, and it loses them at the highest-intent point in the journey. On a phone, on mobile data, in a shop aisle or on a bus, patience is short.
The traffic side is quieter. Google uses Core Web Vitals as part of its page experience signals, which means the same product pages you want ranking are being measured on how quickly the main content appears, how quickly the page responds to a tap, and how much it moves while loading. Speed is not a ranking shortcut, and it will not outrank a better answer, but it sits on the same page as everything else you are doing for search.
There is a third effect worth naming. Slow product pages raise the cost of every visit you buy, because a share of the clicks you paid for never see the page. That waste does not appear as a line item anywhere. It appears as a cost per acquisition that is higher than it should be, which then gets blamed on the campaign.
Measure on the phone your buyer is holding
Speed tests run on fast connections from a data centre tell you almost nothing about your customers. Two habits fix that.
First, use field data rather than lab data where you can. Your analytics and the vitals reporting available for your site show what real visitors experienced, on their own devices and networks. Read it at the slower end rather than the average, because the average is carried by people on good connections and modern phones.
Second, test by template and by device class. Pick your top product page, your top collection page and the homepage, and test each on a mid-range phone on mobile data. Do it after every theme or app change, because that is when regressions arrive.
Then keep a simple log: date, what changed, and the numbers before and after. Speed work is a series of small removals, and without a log nobody can tell which removal helped.
If you only do one thing after reading this, open your landing page report, find the busiest product page, and load it on your own phone away from the office wifi. That single test usually decides where the next month of work goes.