Đoàn Lê Minh Anh
A slow-loading website can drive customers away before they view a product, submit a form, or complete an order. WebPageTest helps businesses evaluate website performance under specific simulated conditions, from location and device to network speed.
In this guide, you’ll learn how to run a WebPageTest, read waterfall charts and filmstrips, and understand which metrics to prioritize. Rather than relying on a single overall score, you can use the data to identify problems and choose the right way to improve performance.
What is WebPageTest, and how can it help?
WebPageTest is a website performance analysis tool that records how a browser loads a page and provides several ways to assess its speed. Results typically include performance metrics, screenshots captured at different points in time, waterfall charts, and details about downloaded resources such as images, JavaScript files, CSS, and fonts.
The tool is useful for more than simply telling you whether a page is fast or slow. You can see which elements take the most time, which resources load too late, which requests are blocked, and when the main content appears. This data helps turn a general impression like “the website feels sluggish” into a specific issue you can investigate, prioritize, and address.
Test results are most meaningful when they closely reflect the experience of your actual customers. A page may load quickly on a desktop computer in the office but slowly for people using phones, mobile networks, or connections from other regions. Choose test settings that match your audience instead of assuming that a single test represents every scenario.
How to run a WebPageTest
Before you begin, prepare the specific URL you want to test. Prioritize pages that directly affect business performance, such as the homepage, product pages, service pages, or checkout. If your website has several different page templates, test a few representative URLs rather than measuring only the homepage.
- Enter the URL: Paste the address of the page you want to analyze into the test field. Use the full URL and make sure the page is publicly accessible; it should not require a login unless you have configured the test accordingly.
- Choose a test location: Select a simulated test location close to your target market. Businesses serving customers in Vietnam should prioritize a suitable location in the region if available, while keeping in mind that the test location can affect network latency.
- Choose a device and network: Test on both desktop and mobile if both audiences matter. Simulated network settings help you evaluate the page under less favorable conditions than a high-speed office connection.
- Set the number of test runs: If the option is available, run the test multiple times to reduce the impact of network or server fluctuations. Use the same settings when comparing results before and after optimization.
- Start the test: Run the test and wait for the tool to record the loading process. Keep a note of the settings and test time, especially when you’re tracking the impact of a website change.
A good test should be designed as a controlled measurement. Avoid changing the location, device, and network settings all at once when comparing two results; if too many factors change, it becomes difficult to tell what caused the difference. For pages with dynamic content, such as product listings or ads, run the test several times and look for trends instead of drawing conclusions from an unusual run.
Read the key metrics
WebPageTest provides many metrics, but not all of them need to be addressed first. Focus on the user experience: when the page starts to appear, how the main content displays, whether interactions respond quickly, and when the page becomes stable. Metric names may appear in English in the interface, so understanding what they mean matters more than memorizing their names.
- Time to First Byte (TTFB): The time from when the browser sends a request to when it receives the first byte of data. A high TTFB may be related to the server, application, database, caching, or network distance. Treat it as a clue to investigate, not a definitive diagnosis.
- First Contentful Paint (FCP): The point when the browser displays the first content, such as text or an image. FCP helps show how long users wait before the page begins to respond visually.
- Largest Contentful Paint (LCP): The time when the largest content element in the initial viewport appears. This is often a large image or the main text block. If LCP is slow, check the resources that make up that element, the server response time, and resources that block rendering.
- Cumulative Layout Shift (CLS): Measures how much the layout shifts unexpectedly while the page loads. Ads, images without declared dimensions, or fonts that load late can make content jump, disrupting reading and interactions.
- Speed Index: Estimates how quickly the visible parts of a page become complete within the viewport. It’s useful for comparing visual loading experiences, but should be considered alongside the filmstrip and other metrics.
- Load time and number of requests: Total time, data transferred, and the number of requests indicate how many resources the browser needs to process. Many small requests or a few very large files can both increase delays.
Don’t try to optimize every number at once. Prioritize metrics that relate to your business goals and the user experience on your most important pages. For example, if customers have to wait a long time to see service information, check when the main content appears. If the layout frequently jumps, address CLS and the elements causing the shifts first.
Analyze the waterfall to find bottlenecks
A waterfall chart shows each network request along a timeline. Each row typically represents a resource or request; the bar length shows how long it takes, while the order helps you see which resources are requested earlier or later. Colors and phase breakdowns can vary by interface, but the principle is the same: look for requests that take a long time, start late, or make other resources wait.
Start with requests that appear early, especially the main HTML document and resources needed to render the top of the page. If the HTML response is delayed, investigate TTFB, the server, or application-side processing. If the HTML arrives promptly but the main image, CSS, or critical JavaScript starts loading late, check resource priorities, how resources are referenced, and dependencies in the page code.
Next, look for long bars or clusters of large requests. Large images may need to be compressed, resized, or converted to a more suitable format. Heavy JavaScript may be split into smaller files, deferred, or removed if it isn’t needed. Third-party requests, such as advertising, analytics, or chat tools, also deserve attention because they can add connections, load more code, and affect when the page is ready.
It’s also important to distinguish slow loading from blocked loading. A resource may wait before it starts because the browser prioritizes another request, it depends on another file, or there are connection limits. Reviewing the waterfall alongside the request list and phase details can help identify whether the issue is file size, server latency, or loading order. Don’t remove a component just because its bar is long; confirm its role with the technical team and the page’s goals.
Use the filmstrip to understand the visual experience
A filmstrip is a sequence of screenshots captured at different points while a page loads. Instead of looking at just one number, you can observe what users see at each moment: a prolonged blank screen, a content frame that appears but is incomplete, or a page that renders quickly and then shifts. It’s a useful way to connect technical data to the real-world experience.
Compare the filmstrip with the waterfall and metrics. If the filmstrip shows that the main content appears late, find the related request in the waterfall, then check the file size, when loading begins, and any resources blocking rendering. If content appears and then shifts position, check for images without fixed dimensions, ads inserted later, or fonts that load slowly. The filmstrip points you toward what to investigate, while request data helps uncover the technical cause.
When LilyTech helps businesses review website performance, combining metrics, waterfall charts, and filmstrips enables the delivery team to prioritize solutions by impact instead of relying on guesswork. This approach also helps evaluate the results of changes to hosting, images, code, or third-party marketing tools.
Optimization workflow and conclusion
Once you’ve identified bottlenecks, make a list of issues using three criteria: their impact on users, their relevance to business goals, and how difficult they are to fix. Common areas to review include reducing image file sizes, declaring image dimensions, improving caching, checking render-blocking resources, and reassessing third-party scripts. Avoid making changes across the board without checking functionality, display, and test results afterward.
A practical workflow might include recording the initial results, choosing one priority issue, implementing a change, rerunning the test with comparable settings, and comparing the metrics and filmstrip experience. If the results don’t improve, or one metric gets better while the page experience changes, revisit your hypothesis and test across multiple devices, URLs, or runs. Keeping records helps marketing, technical, and management teams track progress together.
WebPageTest is most valuable as a diagnostic tool, not a scorecard for chasing a single number. Combining metrics, waterfall charts, and filmstrips helps you understand where a website is slow, how users are affected, and what to address first. If you need a comprehensive assessment or a performance improvement plan aligned with your business goals, contact LilyTech for advice on your website and suitable technology solutions.
