What should a platform evaluation measure?
Dealers experience the finished website, not an isolated platform. The same platform can behave differently depending on inventory, customizations and third-party integrations.
What evidence should a platform claim rest on?
A platform evaluation should identify the page set, test date, available field data and installed technology. No vendor is labeled slow from one page or one test, and no platform is described here beyond what a dealership can check on its own site.
Why does this site publish no platform ranking?
A platform ranking would be the most shareable thing on this website and it would also be misleading. The reasons are set out in why a platform ranking would mislead. What a shopper receives is the platform plus custom code plus inventory plus media plus every third-party tool the dealership installed, and the last item varies more between rooftops than platforms vary between each other.
We have seen no evidence base that isolates the platform's contribution well enough to rank vendors honestly. When that evidence exists, it will be published with its method attached so anyone can check it.
How do you evaluate a dealer website platform?
- 01
Use live rooftops, not demos
A demo site carries none of the third-party weight a real dealership runs. It tells you almost nothing about what you would experience.
- 02
Use several rooftops on that platform
One site is one dealership's tool stack. Several start to show what the platform itself contributes.
- 03
Test the pages shoppers land on
Homepage, inventory search results, vehicle detail pages and at least one lead-driving page, not just the homepage.
- 04
Record everything installed
Platform, template, dealer customizations and every third-party tool present. Without this, you cannot separate the platform from what was installed on top of it, which is the entire question.
- 05
Compare like with like
Same device profile, same metric, same window. Field data where it exists.
- 06
Report the evidence separately, and name the limit
Repeatable lab findings, available field data and product-controlled observations belong in separate sections. State the specific dealer implementation tested. Never generalize it to every customer of that platform.
What should I ask my platform vendor?
| Ask this | Why it matters |
|---|---|
| What performance tooling do you provide, and does it show third-party impact? | Tooling that reports only the platform's own code cannot show you where the time actually goes |
| Which parts of the page are yours, and which are ours to control? | Nobody can act on a finding until it is clear whose layer it sits in |
| What is your position on tag sequencing and deferred loading? | A platform that forbids it rules out the change that does not require replatforming |
| Do you publish field data across your customer base? | Data from many rooftops describes the platform; one demonstration describes one site |
| What happens to performance when we add a vendor you do not control? | Dealership pages carry vendors the platform did not install, so this is the normal case rather than the exception |
Why is the platform usually the wrong thing to blame?
Because two dealerships on the same platform routinely produce very different field data, which is only possible if most of the variance comes from something other than the platform. The platform is not what differs. What differs is the accumulated layer on top: which tools each rooftop added, how many tags survived which agency changes, how the media is configured, and how much custom code sits between the platform and the shopper.
This matters commercially because replatforming is the most expensive available response to a speed problem and one of the least reliable. A full replatform costs months. The risk hits the inventory feed and the URL structure. Replatforming frequently reproduces the same result too, because the new site gets the same tool stack installed on it within a quarter.
It also matters analytically. If the dealership does not know which layer is responsible, it cannot know whether a migration would help, and the honest first step is measurement, not a vendor argument.
Where the accumulated layer is the cause, the lower-risk response is to change when that work runs instead of changing the platform underneath it, which is what a speed layer does.
How should a dealership evaluate its own platform?
Test the finished website, because that is what shoppers get. Record the page templates separately, repeat each test enough times to see the spread, and note the complete third-party inventory present on each page: the same discipline set out in how to test dealer website speed.
Then ask what would actually change. If the same tools would be installed on the new platform, the useful comparison is not platform against platform; it is the current site against the current site with its loading order changed. That is a much cheaper experiment and it can be run without putting a single URL at risk.
Sources and further reading
External sources support the general technical guidance on this page. They do not represent a DealerSpeed Engine performance result.