Diagnose Website Performance Issues

Use Chrome DevTools to identify why websites load slowly and report findings.

Introduction

30 Second Summary

When a customer reports "your website is slow," most support managers can only pass along the complaint without any data. What if you could pinpoint exactly what's slow and tell engineering precisely where to look?

In this project, you will use Chrome DevTools to diagnose website performance issues, read network waterfall charts, and produce a professional escalation report that engineering teams can act on immediately.

What You'll Build

A professional performance diagnosis workflow using Chrome DevTools that transforms vague "it's slow" complaints into precise, data-backed escalation reports.

By the end of this project, you'll have:

A completed Network waterfall analysis identifying the top 3 slowest requests on a real website.
A Lighthouse performance audit report with scores and prioritized recommendations.
A filled-in performance escalation template ready to use with your engineering team.
Secret Mission: Analyze your own company's website and present findings to your engineering team.

Are there any prerequisites?

None. You only need Google Chrome installed on your computer. This project includes setup for everything else. No coding or command-line experience is required.

Before We Start

Before We Start...

Set Up Chrome DevTools

When someone says a website is "slow," that could mean a hundred different things. The server might be lagging, images might be too large, or third-party scripts might be blocking the page from rendering.

To pinpoint the real cause, you need a diagnostic tool. Chrome DevTools is a free set of diagnostic panels built directly into Google Chrome. In this step, you will open DevTools and locate the three panels you will use throughout this project.

In this step, get ready to:

Open Google Chrome browser.
Open Chrome DevTools.
Locate the Network, Lighthouse, and Performance tabs.

Open Google Chrome

Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Google Chrome and press Enter to open it.
Navigate to any website (e.g., google.com) so you have a page loaded.

Don't have Chrome yet?

Download it for free at google.com/chrome. Install it and come back here once it is open.

Open Chrome DevTools

DevTools is Chrome's built-in inspection panel. It lets you see exactly what happens behind the scenes when a webpage loads.

Press F12 (Windows/Linux) or Cmd+Option+I (macOS) to open DevTools.
A panel should appear on the right side or bottom of your browser window.

Alternative way to open DevTools

You can also right-click any element on the page and choose Inspect. This opens DevTools and jumps straight to that element in the code.

DevTools not opening?

On macOS, try Fn+F12 if the regular F12 key controls brightness or volume. On Windows, you can also try Ctrl+Shift+I as an alternative shortcut.

help me open Chrome DevTools on my computer

Locate the Network, Lighthouse, and Performance tabs

DevTools has many panels, but you only need three for this project. Each one answers a different question about website performance.

Look at the top toolbar of the DevTools panel. You will see tab labels like Elements, Console, Sources, Network, and more.
Click the Network tab. This panel shows every file request the browser makes when loading a page.
Click the Performance tab. This panel records detailed load timing.
Click the Lighthouse tab. This panel runs automated audits and gives you a performance score.

Don't see all the tabs?

If your DevTools panel is narrow, some tabs may be hidden behind a >> overflow menu at the end of the toolbar. Click it to reveal the hidden tabs.

What is Lighthouse?

Lighthouse is Google's automated auditing tool. It simulates a mobile device on a slow connection and scores your page from 0 to 100.

It requires no installation because it is built directly into Chrome DevTools. You will use it in Step 4 to generate a full performance report.

Click back to the Network tab to finish. This is where you will start your first analysis in the next step.

Your diagnostic toolkit is ready. Next up, you will use the Network panel to analyze a real website and read your first waterfall chart.

Analyze a Website with the Network Panel

Your Chrome DevTools are open and ready to go. Now it's time to put them to work on a real website.

When someone reports that a page is slow, your first job is figuring out which specific requests are causing the delay. The Network panel records every file the browser downloads, showing you exactly where the time goes.

In this step, get ready to:

Capture all network requests from a real website.
Identify the 3 slowest requests using the waterfall chart.
Break down where each slow request spends its time.

Navigate to a website and open the Network tab

The Network panel only records requests that happen while it is open. You need to have the tab active before you load a page, or you will miss everything that already happened.

Click the Network tab in the DevTools toolbar at the top of the panel.
In Chrome's address bar, type cnn.com or bbc.com and press Enter.

You should see rows appearing in the Network panel as the page loads. Each row represents one file the browser downloaded.

Why open the Network tab first?

DevTools only logs network activity while the Network panel is open. If you navigate to a page and then open the panel, all the requests that already completed are gone. Opening the tab first ensures you capture everything from the very first request.

Not seeing any requests?

Make sure the Network tab was active before you pressed Enter. If you opened it after the page loaded, click the reload button (circular arrow) in Chrome's toolbar to reload the page with the panel open.

Check that recording is active. DevTools records all network requests by default, but if recording was stopped, you will see an empty panel. Press Cmd+E (macOS) or Ctrl+E (Windows) to toggle recording back on.

Help me figure out why my Network panel is empty.

Disable the browser cache and reload

When you visit a site normally, your browser saves copies of files locally. This is called caching. To see what a first-time visitor actually experiences, you need to disable this cache.

Check the Disable cache checkbox in the Network panel toolbar (near the top of the panel, below the tab row).
Reload the page by pressing Cmd+R (macOS) or Ctrl+R (Windows).

After reloading, you should see the waterfall chart fill up with all the requests. At the bottom of the Network panel, a status bar shows the total number of requests, total data transferred, and total load time.

What does Disable cache do?

Your browser normally stores files it has already downloaded so it does not have to fetch them again on repeat visits. This makes the page appear faster for returning visitors, but it hides the true load time from you.

Checking Disable cache forces the browser to download everything fresh. This simulates what a brand new visitor would experience, which is exactly the scenario you need to diagnose.

Still seeing cached results?

The Disable cache checkbox only works while DevTools is open. Make sure DevTools stays open during the reload.

If you are unsure whether cache was truly disabled, right-click the reload button in Chrome's toolbar and choose Empty Cache and Hard Reload to force-clear everything for this page.

Help me confirm my browser cache is actually disabled.

Identify the slowest requests using the waterfall

Your waterfall chart is now full of data. The next step is finding which requests took the longest and understanding why.

Click the Time column header in the Network panel to sort requests by duration (longest at the top).
Note the top 3 requests. Look at the Name column to see which files they are (images, scripts, fonts, or API calls).
Hover over each of those 3 requests' entries in the Waterfall column to see the timing breakdown popup.

What do the timing phases mean?

DNS Lookup: The time spent finding the server's address on the internet. Think of it like looking up a phone number before you can make a call.
Waiting (TTFB): Time to First Byte. This is the time between sending the request and receiving the first bit of data back. It reveals how fast the server responds.
Content Download: The time spent downloading the actual file. Large files like oversized images or heavy JavaScript bundles show up here.

Look at the timing breakdown for your 3 slowest requests. Each one tells a different story about where the bottleneck lives.

Spot the patterns

If multiple requests have a long Waiting (TTFB) phase, the server might be overloaded or slow to respond. If multiple requests have a long Content Download phase, the site is likely serving oversized files.

These patterns become key evidence in the escalation report you will build later.

Not sure which column is Time?

The default columns in the Network panel include Name, Status, Type, Initiator, Size, Time, and Waterfall. If you do not see a Time column, right-click any column header and check Time to make it visible.

Help me find and sort by the Time column in the Network panel.

You have identified exactly which requests are dragging the page down and where each one spends its time. Next up, you will simulate what happens when a user has a slow internet connection.

Simulate Slow Network Conditions

You just identified the slowest requests on a website under ideal network conditions. That's a great start, but most of your users aren't sitting in an office with a fast wired connection.

In this step, you'll simulate what your users actually experience on a mobile network. Chrome DevTools has built-in network throttling that slows down your connection to mimic real-world conditions. This reveals bottlenecks that are invisible on a fast connection but crippling on a slow one.

In this step, get ready to:

Enable Slow 4G network throttling and reload the page.
Compare load times between normal and throttled conditions.
Identify which requests become critical bottlenecks on slow connections.

Enable Slow 4G throttling

Before you switch to a slow connection, take a quick note of the current stats displayed in the bottom status bar of the Network panel. You'll want these numbers for comparison in a moment.

Look at the status bar at the bottom of the Network panel. Note the total number of requests, data transferred, and total load time (e.g., "85 requests, 4.2 MB transferred, Finish: 2.1 s").
Write these numbers down somewhere you can reference them. A sticky note or a blank document works fine.
Locate the Throttling dropdown in the Network panel toolbar. It currently says No throttling.
Click the Throttling dropdown and select Slow 4G from the list.
Reload the page by pressing Cmd+R (macOS) or Ctrl+R (Windows). Watch as the waterfall populates much more slowly this time.

What does Slow 4G throttling do?

Chrome artificially limits your download and upload speeds to simulate a mobile connection. This means every request takes longer to complete, just like it would for a user on their phone during a commute.

The page itself hasn't changed. You're just seeing what it feels like for users with slower connections.

Page loaded just as fast as before?

Make sure the Disable cache checkbox is still enabled. If the browser serves cached resources, throttling won't affect those requests. Also confirm the dropdown actually shows Slow 4G and not No throttling.

help me figure out why my network throttling isn't slowing down the page load

Compare load times between normal and throttled conditions

Now that the throttled page has finished loading, you can see exactly how much slower the experience is for mobile users. The status bar at the bottom of the Network panel tells the full story.

Look at the status bar at the bottom of the Network panel again. Note the new total load time, number of requests, and data transferred.
Compare the new numbers against what you wrote down earlier. Focus on three things: total load time, total requests, and total data transferred.
Write down the difference. For example: "Normal: 2.1s load, 85 requests. Slow 4G: 14.3s load, 82 requests."

Why might the number of requests change?

Some websites load additional resources dynamically based on user interactions or timers. On a throttled connection, the page may time out before all these secondary requests fire. You might see fewer requests under throttled conditions because the page never fully finishes loading.

Identify critical bottlenecks under slow connections

Some requests that seemed fine under normal conditions become serious problems on a slow network. A 500 KB image that loaded in 200ms on your fast connection might now take 4+ seconds.

Click the Time column header to sort requests by load time, with the slowest at the top.
Look at the top 5 slowest requests. For each one, note the Type column (is it an image, script, document, or font?).
Hover over each slow request's waterfall bar to see the timing breakdown. Look for long green bars (TTFB/waiting for server response) and long blue bars (content download).
Check the Size column for the slowest requests. Large files (500 KB+) on slow connections are usually the biggest bottlenecks.

What are the common bottleneck types?

There are three main categories of bottlenecks you'll typically find. Large images are files that could be compressed or served in modern formats. Third-party scripts are analytics, ads, or chat widgets loaded from external domains. Slow server responses are requests where the green (TTFB) bar is disproportionately long.

Write down which category each of your slowest requests falls into. This classification will be essential for your escalation report later.

Look at the domain column

Requests from domains other than the website you're testing (e.g., ad networks, analytics services) are third-party scripts. These are often outside your engineering team's direct control, but identifying them helps explain why a page is slow.

You now know exactly what your mobile users experience and which requests are causing the most pain. Next up, you'll run a Lighthouse audit to get an automated performance score and specific recommendations for fixing these bottlenecks.

Run a Lighthouse Performance Audit

You have identified the slowest requests and seen how throttled connections expose bottlenecks. Now you will use an automated tool to score the page and get specific, prioritized recommendations.

Lighthouse is a performance auditing tool built directly into Chrome DevTools. It simulates a mid-tier mobile device, loads the page from scratch, and produces a scored report with actionable fixes.

In this step, get ready to:

Run a Lighthouse performance audit on your content-heavy website.
Read Core Web Vitals scores and the overall Performance score.
Review Lighthouse recommendations in the Opportunities and Diagnostics sections.

Switch to the Lighthouse tab and run the audit

Lighthouse runs a full page load simulation and grades the result. You need to configure it to focus on performance and simulate a mobile device before starting the audit.

In DevTools, click the Lighthouse tab in the top toolbar.
Under Categories, make sure only Performance is selected. Deselect any other categories (Accessibility, Best Practices, SEO) if they are checked.
Under Device, select Mobile.
Click Analyze page load.

The audit takes 30 to 60 seconds. You will see the page reload and a progress bar as Lighthouse collects data.

What does Lighthouse simulate?

Lighthouse applies its own simulated throttling that models a mid-tier mobile device on a slow 4G connection. This means your earlier Network panel throttling setting does not affect the Lighthouse audit.

The simulation gives you a realistic picture of how mobile users experience the page, even if you are running the audit on a powerful desktop.

Audit not starting?

Make sure you do not have any browser extensions active. Extensions can interfere with Lighthouse results. Try running the audit in an Incognito window with extensions disabled.

Help me troubleshoot my Lighthouse audit

Read the Performance score and Core Web Vitals

Once the audit finishes, Lighthouse displays a report starting with a color-coded Performance score from 0 to 100. Below that score, you will find the Core Web Vitals metrics that Google uses to measure real-world user experience.

Note your overall Performance score at the top of the report. Green (90-100) is good, orange (50-89) needs improvement, and red (0-49) is poor.
Find the Largest Contentful Paint (LCP) metric. This measures how long it takes for the largest visible element to load. A good score is under 2.5 seconds.
Find the Cumulative Layout Shift (CLS) metric. This measures how much the page content shifts around as it loads. A good score is under 0.1.
Find the Interaction to Next Paint (INP) metric if it appears. This measures responsiveness when a user interacts with the page. A good score is under 200 milliseconds.

Why do these thresholds matter?

Google uses LCP, CLS, and INP as ranking signals for search results. Pages that fail these thresholds deliver a poor experience for users and may rank lower in search.

When you include these numbers in your escalation report, engineering teams immediately understand the severity because these thresholds are industry standards.

Review the Opportunities and Diagnostics sections

The scores tell you how the page performs. The sections below them tell you exactly what to fix.

Scroll down to the Opportunities section and click it to expand.
Review each recommendation. Common ones include Serve images in next-gen formats and Reduce unused JavaScript.
Note the estimated time savings shown next to each opportunity. Lighthouse ranks these by potential impact, so the top items matter most.
Scroll down further and expand the Diagnostics section.
Review the diagnostic items. These provide additional context such as which specific resources are causing delays.

What is the difference between Opportunities and Diagnostics?

Opportunities are specific actions with estimated time savings (e.g., compress this image to save 1.2 seconds). Diagnostics provide broader context about the page structure (e.g., excessive DOM size or too many network requests).

For your escalation report, Opportunities are the most useful. They give engineering teams a clear action and a measurable benefit.

Write down the top 3 recommendations

Open a note or text document and write down the top 3 items from the Opportunities section, including their estimated time savings. You will use these directly in your escalation report in the next step.

You now have hard data: a Performance score, Core Web Vitals measurements, and a prioritized list of fixes. Next up, you will combine your Network waterfall findings and Lighthouse results into a professional escalation report that engineering teams can act on immediately.

Build Your Performance Escalation Report

You now have two powerful data sources: a Network waterfall showing exactly which requests are slowest, and a Lighthouse report scoring your page's overall performance. The missing piece is communicating these findings to people who can fix them.

In this step, you will create a professional performance escalation report. This transforms your raw DevTools data into a structured document that engineering teams can act on immediately.

In this step, get ready to:

Fill in a structured escalation template with your findings.
Take screenshots of your Network waterfall and Lighthouse report as evidence.
Write an impact statement connecting performance data to user experience.

Create your escalation report document

The escalation template is what separates a vague "it's slow" complaint from a professional report that engineers can immediately act on. Each section serves a specific purpose in helping the engineering team reproduce and fix the issue.

Open Google Docs, Notion, or any text editor you prefer.
Create a new document and title it Performance Escalation Report.
Add the following section headings to your document, each on its own line:

Issue Summary - Write 1-2 sentences describing the problem (e.g., "Homepage loads slowly on mobile connections, causing poor user experience").
Environment - Record the browser (Chrome), device type (Desktop simulating Mobile via Lighthouse), and network condition (Slow 4G) you tested with.
Evidence - Leave this section blank for now. You will attach screenshots in the next substep.
Top 3 Bottlenecks - List the 3 slowest requests you identified from the Network waterfall. Include the request name, its type (image, script, font), and the total load time from the Time column.
Recommended Actions - Copy 2-3 specific recommendations from the Opportunities section of your Lighthouse report (e.g., "Serve images in next-gen formats", "Reduce unused JavaScript").

Why use a template instead of a free-form message?

Engineers receive dozens of bug reports daily. A structured template makes your report instantly scannable. The Environment section lets them reproduce the issue, the Evidence section proves the issue exists, and the Recommended Actions section gives them a starting point for fixes.

This structure mirrors how engineering teams file internal performance tickets. Speaking their language builds credibility.

Take screenshots of your evidence

A performance report without visual evidence is just opinion. Screenshots of your Network waterfall and Lighthouse scores turn your findings into undeniable data.

Switch to the Network tab in DevTools.
Make sure your waterfall chart is visible with the requests sorted by the Time column (slowest at the top).
Take a screenshot by pressing Cmd+Shift+4 (macOS) or Windows+Shift+S (Windows) and selecting the Network panel area.
Switch to the Lighthouse tab in DevTools.
Take a second screenshot capturing the Performance score and the Core Web Vitals metrics (LCP, CLS) at the top of the report.
Paste or attach both screenshots into the Evidence section of your escalation report document.

Annotate your screenshots

If your screenshot tool supports it, draw a circle or arrow pointing to the slowest request in the waterfall and the Performance score number. This helps the reader's eye jump straight to the problem.

Write your impact statement

The impact statement is the most important part of your report. Engineers prioritize fixes based on user impact, not just raw numbers.

Add a final section heading to your document called Impact.
Look at your Lighthouse report's LCP score. Note the number of seconds it takes.
Write a statement that connects the timing data to the user experience threshold. For example: "Page takes 8.2s to load on mobile, which is 3x slower than the 2.5s LCP threshold recommended by Google."
Replace the example numbers with the actual LCP value from your Lighthouse report.
If your CLS score is above 0.1, add a second sentence noting the layout shift impact (e.g., "Users experience visible layout shifts during loading, scoring 0.25 CLS against the recommended 0.1 threshold").

What makes a strong impact statement?

A strong impact statement does three things: states the measured value, names the recommended threshold, and describes what this means for users. The thresholds come from Google's Core Web Vitals guidelines: LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1.

Framing it as a multiple ("3x slower than recommended") makes the severity immediately obvious to anyone reading the report.

Not sure what numbers to use?

If your Lighthouse report shows an LCP that is already under 2.5 seconds, your tested site may be performing well. In that case, focus your impact statement on whichever metric scored lowest (CLS or total load time under throttled conditions from Step 3).

Help me write an impact statement based on my Lighthouse scores.

Your performance escalation report is complete. You now have a professional document that transforms raw DevTools data into actionable findings. Next up, you will put these skills to the ultimate test in the Secret Mission.

Secret mission

Analyze Your Own Company's Website

You have the skills to diagnose any website now. What if you turned those skills on your own company's product and presented real findings to your engineering team?

Clean Up Your Resources

This project runs entirely in your browser using Chrome DevTools, so there are no ongoing costs or background processes to worry about.

Decide whether to keep your resources as they are, tidy up your browser, or delete the files you created.

Resources you used:

Google Chrome browser (already installed, no action needed).
Performance escalation report document (Google Docs, Notion, or local text file).
Screenshots of your Network waterfall and Lighthouse report.

Keep everything running

No action needed. Choose this if you plan to continue practicing performance diagnosis or want to reference your escalation report later.

Your escalation report document stays wherever you saved it (Google Docs, Notion, or your local machine).
Your screenshots remain in your Downloads folder or wherever you saved them.
Chrome DevTools is built into Chrome. It does not use storage or run in the background when closed.

Pause - I'll come back to this later

Close your DevTools tabs to free up browser memory. Your saved files stay available for next time.

Close any browser tabs you opened for performance testing.
Your escalation report and screenshots remain saved wherever you put them.

Delete - I don't want to use this again

Remove the files you created during this project.

Delete your performance escalation report document. If it is in Google Docs or Notion, open the document, then select the option to move it to trash. If it is a local file, delete it from your file system.
Delete any screenshots you saved from the Network waterfall or Lighthouse report. Check your Downloads folder or Desktop for these files.
Chrome DevTools is a built-in feature of Chrome. There is nothing to uninstall.

Nice Work!

You now have a superpower that most support managers don't have: the ability to turn "it's slow" into actionable, data-backed performance reports. You've built a complete diagnosis workflow using tools that are free, built into Chrome, and trusted by engineering teams worldwide.

Here's what you learned:

Read Network waterfall charts to pinpoint exactly which requests are slow and why, using timing breakdowns like DNS lookup and TTFB.
Used network throttling to simulate real-world mobile conditions and identify which requests become critical bottlenecks on slow connections.
Ran Lighthouse performance audits, interpreted Core Web Vitals scores, and built a professional performance escalation template that engineering teams can act on immediately.
Analyzed your own company's website and prepared a real escalation report with findings ready to share with your engineering team.

Ready to quiz yourself?