A page feeling fast on my laptop does not tell me how it feels on a phone with a slower connection. My browser may already have the files cached, and my development setup can hide a heavy first visit.
I want to test when the page becomes useful, not only how it looks after everything loads.
This follows the constraints I discussed in building digital products for Nigerian users. Data weight, mobile use and unclear waiting states affect the experience.
Begin without the cached advantage
I open the Network panel, disable the cache for the test and use a slower network setting. I also check a fresh session where stored app data would change the journey.
I note when I can read the main content and use the main action. A blank screen followed by a perfect layout is still a long wait.
Find the heavy requests
I sort requests by size and inspect large images, fonts, videos and scripts. For each one, I ask whether this page needs it and whether it needs to arrive immediately.
I serve images at sensible dimensions and compression for their display size. Media lower down the page can often wait. I avoid delaying the main visible image just because lazy loading is available.
Watch movement and response
I look for layout shifts while media loads. Reserved dimensions or an appropriate aspect ratio can keep content from moving under someone's finger.
I also try buttons before the page feels completely settled. If JavaScript keeps the browser busy, a tap can appear to do nothing. I investigate unnecessary work and large dependencies rather than adding another loading animation.
Follow the complete journey
I test the useful pages and actions, not only the homepage. On a slow form request, can the person tell their tap was received? Does the typed information survive a failure? Is a retry safe?
A timeout can leave an operation's result uncertain. The interface should not make a false promise or encourage a duplicate action.
Use a real phone where possible
A phone helps me notice small tap targets, oversized modals and a keyboard covering the next step. I test more than one viewport and do not treat desktop emulation as proof of every device's behavior.
Keep a simple budget
I record useful limits for the project's initial transfer size and required JavaScript. The exact numbers depend on the product; what matters is noticing when a new image or widget changes the cost.
After an improvement, I repeat the same journey under comparable conditions and check the deployed version. I record the conditions with the result so I am not comparing a cached visit with a fresh one.
Performance needs attention as the page grows. I want each addition to earn the waiting time and data it asks from the visitor.
A repeatable test instead of a fast-looking page
This article describes a testing method. It does not contain measured before-and-after performance results for CozonDW or my other projects. Here is how a reader can produce those results without mixing up a cached visit and a first visit.
- Choose one deployed page and one task, such as opening an artist profile and finding its streaming link. Record the URL, browser version, viewport, and date.
- Run a Lighthouse check for a broad starting assessment. Use Network inspection to investigate requests rather than assuming every delay is caused by file size.
- In Chrome DevTools, open Network, enable Disable cache, and choose a throttling preset. Record the preset and keep DevTools open during the test.
- Reload and watch when the important text appears and when the task can actually be completed. Keep these observations separate from the browser load event.
- Inspect the largest transferred resources and failed requests. Change one relevant thing, such as the hero image dimensions, before repeating the same task under the same conditions.
- Repeat each version several times. Record the individual runs and compare the middle result rather than choosing only the fastest run.
What I put in the test record
| Record | Why it matters |
|---|---|
| Page and main task | A fast homepage cannot prove a slow profile editor is usable. |
| Browser, device and viewport | Desktop emulation and a real phone have different limits. |
| Network preset and cache state | These must match when comparing versions. |
| Transferred bytes and largest requests | Shows which resources are actually adding download cost. |
| Time to readable content and usable action | Connects the measurement to what the visitor needs. |
| Change made and repeat-run results | Separates an observed improvement from a guess. |
For a Blogger post, an image uploaded at a large resolution may be displayed through a smaller served image URL. Inspect the transferred file before blaming the upload size. Lazy loading is already available in Blogger settings, but the image a reader sees first still needs deliberate treatment. Keep dimensions on images to reserve their space.
A slower network preset does not fully reproduce a low-powered phone. CPU work, memory, browser extensions, and service workers can change the result. If a service worker serves cached responses, note that separately. Do not clear a real user’s saved application data merely to obtain a clean test.
My next useful evidence for a project would be a recorded baseline, one specific change, and comparable reruns. Until those numbers exist, I can explain the procedure but cannot honestly claim that I made the website a particular percentage faster.
Reference: Chrome DevTools: inspecting network activity.