Ecommerce website speed requires careful measurement and interpretation. Thirty-three pilot test attempts produced 11 usable laboratory observations of store homepages. The median Lighthouse score was 42/100, but the small sample and testing conditions limit the conclusions. These findings are a starting point for investigation, rather than an estimate of performance across the Greek market.
- Thirty-three attempts produced 11 usable laboratory observations of store homepages.
- The median Lighthouse score was 42/100 under the recorded testing conditions.
- Loading failures were excluded from conclusions about store speed.
- The sample cannot estimate performance across all Greek online stores or quantify lost sales
Ecommerce website speed cannot be assessed reliably through an unexplained score. We made 33 pilot test attempts against candidate store addresses serving the Greek market, then reviewed which results could be used. Here we present the aggregated observations without naming or ranking businesses, alongside the limitations you need to understand before drawing conclusions.
Key Takeaways
The pilot investigation revealed signs of slow loading and demonstrated why test results themselves need checking. Four observations frame the findings.
- Thirty-three attempts produced 11 usable laboratory observations of store homepages.
- The median Lighthouse score was 42/100 under the recorded testing conditions.
- Loading failures were excluded from conclusions about store speed.
- The sample cannot estimate performance across all Greek online stores or quantify lost sales.
How Did We Test Ecommerce Website Speed?
We used Lighthouse 13.5.0 to run laboratory tests of homepages with mobile simulation. Each address was tested once, without purchasing products, selecting a country, or accepting cookies.
Lighthouse is a website auditing tool that evaluates loading performance under defined conditions. A laboratory test simulates a visit and differs from measurements collected from actual users.
Data collection took place on October 7, 2026. Settings included a simulated mobile screen width of 412 pixels, simulated network latency of 150 milliseconds, and a CPU slowdown multiplier of four.
The Lighthouse tests ran sequentially. However, early tests overlapped with separate website validation on the same computer. That activity is a limitation and should be eliminated in repeat data collection.
The documentation on Lighthouse performance scoring explains how individual measurements contribute to the score and why scores can vary.
The investigation covered the first page a visitor reached. It did not measure the full shopping journey or establish how quickly product pages and checkout screens performed.
Why Did 33 Attempts Not Produce 33 Valid Measurements?
Fifteen of the 33 attempts returned numerical scores, while 18 encountered loading errors. Four scored pages were excluded because they did not represent normal store homepages.
The four exclusions consisted of two country-selection screens, a domain-for-sale page, and a page without a functioning store. Reviewing the recorded screenshots helped identify these cases.
| Review stage | Count | Treatment |
|---|---|---|
| Total test attempts | 33 | All recorded |
| Reports with numerical scores | 15 | Checked for relevant content |
| Loading errors | 18 | Not treated as evidence of slow stores |
| Unsuitable destination pages | 4 | Excluded from the analysis |
| Usable pilot observations | 11 | Included in the aggregated findings |
Widespread connection and certificate problems developed in the testing environment during collection. Those failures do not establish equivalent problems with the businesses.
The distinction matters. Assigning a zero score to every failed attempt would create a conclusion unsupported by the data.
A successful numerical report also needs scrutiny. A lightweight page containing little useful information can receive a high score without providing a meaningful shopping experience.
What Did the 11 Usable Observations Show?
Across the 11 homepages, the median Lighthouse score was 42/100 and median laboratory LCP was approximately 18.9 seconds. These values describe the recorded tests and require confirmation through repeated measurements.
The median is the middle value after observations are sorted. It was used so that a single unusually high or low result would not determine the summary by itself.
| Measurement | Pilot result | What it describes |
|---|---|---|
| Median Lighthouse score | 42/100 | Overall laboratory performance assessment |
| Median LCP | 18.9 seconds | Appearance of the largest content element |
| Median TBT | 588.5 milliseconds | Main-thread blocking during loading |
| Scores below 50 | 8 of 11 | Observations in the low score range |
| Scores from 50 to 89 | 3 of 11 | Observations in the middle range |
| Scores of at least 90 | 0 of 11 | Observations in the high range |
Laboratory LCP exceeded four seconds in nine observations. Laboratory CLS was at or below 0.1 in six.
These counts should not be converted into percentages describing the Greek market. The final small sample was limited to technology and fashion stores and does not represent a range of retail sectors.
The median LCP should also not be described as the typical waiting time experienced by customers. It is a result from this particular simulated testing setup.
Does This Mean the Stores Failed Core Web Vitals?
These tests cannot establish whether stores passed or failed Core Web Vitals for actual users. We did not collect CrUX data or INP measurements from real visits.
Core Web Vitals are user-experience measurements covering loading, responsiveness, and visual stability. LCP measures the appearance of the largest visible content element, while CLS measures unexpected layout shifts.
The official Core Web Vitals thresholds define good values as LCP of up to 2.5 seconds, INP of up to 200 milliseconds, and CLS of up to 0.1. Real-user assessment uses the 75th percentile of visits.
TBT is a laboratory measurement of blocking during loading. It is not the same as INP, which concerns responsiveness to interactions. The Total Blocking Time documentation explains that measurement.
The observations therefore provide indications for further investigation. They do not prove that actual customers wait for precisely the times recorded.
Laboratory and real-user data answer related but different questions. A useful assessment examines both where reliable data is available.
What Can You Learn for Your Own Store?
The pilot analysis supports checking loading, responsiveness, and stability separately. Your own store needs measurements of its relevant pages rather than assumptions based on this sample.
A homepage does not describe the whole store. Category pages, product pages, and checkout can load different components and encounter different problems.
For a business serving Greece, testing should cover the language and journey customers use. Country selection, pop-ups, and consent settings can change the content presented on a first visit.
Before deciding on improvements, ask for:
- Repeated tests using consistent settings.
- Checks of the homepage, category pages, and product pages.
- Review of available real-user data.
- Identification of the element affecting each measurement.
- Confirmation that changes preserve payments and shipping functionality.
Speed optimization requires diagnosis and retesting. A score indicates where to investigate, but it does not choose the appropriate fix by itself.
Record the conditions carefully. Comparing a first visit with a returning visit, or different consent states, can otherwise make the results difficult to interpret.
How Do You Plan a Useful Improvement?
Start by recording the existing condition, investigate the causes, and retest after making changes. Evaluate improvements through comparable measurements and functional checks.
- Choose important pages. Include products and categories your customers use.
- Record the conditions. Keep the date, tool, settings, and cookie state.
- Repeat the measurements. Check whether problems appear consistently or occasionally.
- Identify specific causes. Examine images, code, and external services without assuming they are all responsible.
- Test the changes. Confirm that search, the cart, and purchasing still work.
- Compare before and after. Use the same pages and comparable conditions.
If you are planning a new store, ecommerce development can include agreed performance checks from the beginning.
Speed and organic visibility need coordination. SEO services also examine content and technical access, without promising rankings from a single performance improvement.
Assign responsibility for the work. An audit is more useful when someone owns the agreed changes and the subsequent verification.
From Our Experience
The pilot process demonstrated why numerical scores need a review of the content measured. Otherwise, an unsuitable page can be included as though it were a normal store.
From our experience in this investigation, a page without a functioning store received a score of 100/100. Visual inspection allowed us to exclude it.
The practical lesson is to check what loaded, alongside the score. Having fewer elements can make a page lightweight without providing a useful shopping experience.
Keeping the report and screenshot together helps reviewers understand the result and identify cases that should not enter the final analysis.
What Should You Do Next?
Check ecommerce website speed on pages that matter to your business and ask for evidence-based priorities. Use this pilot analysis as a reason to investigate, without directly comparing your store against the sample.
Gather your important pages and available traffic information. Note where customers report delays.
Contact Wechevo to plan an assessment with a clear method and specific recommendations.
Frequently asked questions
Were 33 Online Stores Measured Successfully?
No. There were 33 attempts, of which 15 produced scores. Four reports were excluded because they concerned unsuitable destination pages, leaving 11 usable pilot observations. The other 18 attempts encountered loading errors and were not used to draw conclusions about the speed of the stores concerned.
Does the Median LCP Describe the Greek Market?
No. The 18.9-second figure describes only the 11 laboratory observations. The sample is small, non-random, and limited in sector coverage. Testing conditions and the lack of repeated runs also affect interpretation. The result cannot be used as the average loading time of Greek online stores or their customers.
Does a Low Score Prove Lost Sales?
A score alone does not prove lost sales. Business assessment requires reliable behavioral and purchasing data, alongside consideration of other factors. This investigation did not collect revenue, transactions, or abandonment rates. It therefore does not assign financial losses to the performance measurements or estimate how much an improvement would earn.
Why Are the Stores Not Named?
The presentation focuses on aggregated findings and methodology without ranking named businesses. A single laboratory homepage test, particularly under the recorded limitations, is insufficient for a stable comparison of businesses. Anonymity does not remove those limitations or turn the sample into a representative market study with broadly applicable conclusions.
Source: developer.chrome.com
Want a website that brings customers? Talk to the Wechevo team for a free initial assessment.
Athanasios Charatsaris is the founder of Wechevo. He designs and builds websites and e-shops for Greek businesses and leads the strategy that helps them appear on Google and in AI answers (SEO & AEO), as well as Google…
More about the author →
