What does F12 mean? Slow down the webpage loading and click it to clearly see exactly where the freeze occurs

my little broken site hanging on a cloud server, publishing articles in the background and occasionally circling around. A few days ago, it took another ten seconds to spin. I didn't rush to refresh and tried my luck, so I pressed F12 first—just that one click, and you can clearly see exactly which second it stuck: a red line in the request list, the backend template pulling a font file from a public CDN, and it stumbled for two and a half seconds before clocking out. Block that line and refresh it, and the page will pop up instantly. This article breaks down the method clearly, making it even more user-friendly than command-line tools, since it's a graphical interface.
first clarify: what exactly is the F-12, and will it break down
F12 is the browser's built-in developer tool, including Chrome, Edge, and Firefox, all available. You press the F12 key on the top row of the keyboard. Note laptop users: Many machines have volume and brightness taken over by default from F1 to F12. You need to hold Fn and then press F12, or right-click on a blank page and select "Check," or press Ctrl+Shift+I. All three entries are on the same door.
not bad. It just looks at it, at most making temporary style changes locally. All changes are restored to original form as soon as you refresh, and the website side remains completely unharmed. The first time I pressed it, I was nervous too, but later I realized it's the same as the remote's settings menu: once inside, if you don't press randomly to confirm, nothing happens.
After
inside, there's a row of English tabs, which is normal for your eyes. For daily troubleshooting, I only recognize one thing: Network, and the Chinese interface is called '网络网'. Elements modify styles, Console detects errors, Sources translates code, but none of these are needed this time. Just click Network, and it will prompt you to refresh the page.
Catch once, load: The red line is the suspect
press F5 to refresh, and dozens of lines of the list flood in in one go—all the work the browser does in the background when this page opens is here. Each line is a request: a diagram, a script, an interface, a font—clearly listed who comes first and who comes last.
What should you scan first? Sweep the red color. The red line either has status codes starting with 4 or simply labels 'failed'—the most eye-catching. That time, I had a red text request line, the Status column said failed, and the Time column was 2.5 seconds. Picking the red one among dozens of requests on a page is like picking the wrong question on a test paper—much faster than guessing one by one.
don't complain that dozens of lines are too many. Nowadays, it's normal for a single page to run dozens of requests on the back. My 68KB small site homepage has about forty lines per round, and hundreds of lines on e-commerce pages are normal. The browser only opens six channels for the same domain name at the same time; requests from the sixth to the next must be queued. This is where the queueing segment in Timing comes from. What you need to do is not look at each line, but to pick out anomalies.
At the bottom of the
list, there is also a summary, similar to "47 requests · 1.2 MB · 3.5 s · "finished"—how many requests were sent, how much data was pulled, how long it took—a quick glance gives you a clear idea. For the same page, 1.2MB today is 4MB tomorrow, and the extra 2.8MB is the target for the new search. The two checkboxes on the panel are familiar: Disable cache and Preserve log. I'll explain separately later, both are valuable items.
five columns in the ledger, each column reporting one matter
list defaults to a few columns, which translates into a ledger in plain language:
| column name | what it records | what kind of value should be |
| Name | filename or interface name | The domain name is different from the homepage; it's an external site resource. It's slow and you can't control it |
| Status | the status code | 200 done; 404 doesn't have this file; 502 is down on the other side; Failed: Doesn't connect to |
| Type | type | document documents, script scripts, img images, font fonts, xhr interface |
| Size | transmitted how many bytes | from cache files without going through the network; A few MB of images drag you down |
| Time | this request always takes time | others take only a fraction of a second, but it takes one or two seconds, and that's it |
What do the codes starting with 4 and 5 mean in the status code? I previously wrote a dedicated article about this. Just check the table: What exactly do 404 and 502 mean
the far right is a Waterfall map, which is displayed there by default. I think it's the most valuable. It not only shows how long each request takes, but also shows the exact hour, minute, and second it started—a horizontal bar, the longer it gets, the slower it gets, and a staggered start point means it's waiting in the queue ahead. From a pile of short horizontal bars, a long one was poked out and dragged to the far right, and the whole page was dragged along by it. Hovering the mouse over the horizontal bar will also reveal a small card. This request costs a little per segment, so you don't need to click to get a general idea.
there's also a Protocol column hidden by default. Right-click the header and check it out, and you can see whether each request goes h2 or h3. I used it in the previous post about HTTP/3 to see if your own site uses QUIC: What do HTTP/3 and QUIC mean.
click on a request, Timing is its current record
click any row in the list, the details panel will pop up on the right, then switch to the Timing tab. A request is broken down into several segments from birth to launch, stacked up for you to see, like a supermarket receipt.
to figure out what each segment corresponds to, I ran a run with myself. curl's -w argument can be timed in segments, matching the Timing panel. After four rounds of testing: DNS resolution 0.015 to 0.077 seconds, TCP connection 0.20 to 0.76 seconds, TLS handshake 0.35 to 0.41 seconds, waiting for the server to eject a byte in 0.78 to 1.66 seconds, and content download in 0.16 to 1.50 seconds. A 68KB page takes 1.5 to 4 seconds to open completely, with a destination every second.
compared the segments in Timing, and the blame was clearly separated:
| segments | what is it doing | this long paragraph is |
| Queueing | the browser limits concurrency by itself, and the queued requests are waiting here | frontend approach, a pile of documents crowds into one car |
| DNS Lookup | translating the domain into a IP | DNS for a flash, switching to the 223.5.5.5 setup |
| Initial connection | TCP handshake to build pipelines | long or |
| SSL/TLS | Encrypted Handshake with Authentication Certificate | Certificate Configuration or Link Issues |
| Waiting (TTFB) | request is sent, wait until the other side thinks it through before replying | server's fault. No matter how fast your network is, it's useless |
| Content Download | to transmit the body message | Files are too large or bandwidth is insufficient |
This is the same idea as the three-paragraph positioning I wrote about ping before: separate accounting for things inside the house, on the road, and across the street: what does ping mean For my 2.5-second run that time, waiting accounted for the majority—it was my site's backend waiting for the CDN to return, which had nothing to do with my home network. Restarting the router at home alone wouldn't fix it.
three of the most valuable little switches
first, Disable cache. Check it and refresh again. The browser pretends it has no cache and re-downloads all files. Troubleshooting 'Why doesn't the website change after modifying' depends entirely on it—otherwise, if you refresh for a long time, all you'll see is old cache, which is the same as forcing a Ctrl+F5 refresh: F5 and Ctrl+F5 are not the same . Remember to uncheck the box after checking, otherwise browsing usually wastes more data.
second, Preserve log. By default, the list will be cleared when redirected to a new page. Check the box to keep records across pages. Check for 'white screen after logging in' or other page breakage issues—without it, you can't catch anything.
third, Block request URL. Right-click any row in the list to find it. Block it and refresh it; when the page is good, it's the one; if not, block the next—just move one variable at a time. This is the most experimental feature in F12. That day, my font file was condemned like this: blocked, instantly opened, solid proof. After testing, remember to unblock in the same menu layer, otherwise the block will keep remembering. Next time you open this website, the font is still missing, and you might think the site is broken.
What if
phone doesn't have an F12? Safari on iOS needs to be integrated with a Mac, while Chrome on Android can be remotely debugged via USB to a computer, but both are quite complicated. The trick is to press Ctrl+Shift+M on the computer to switch to the phone's analog view. First, get a rough idea—80% of web issues can be reproduced in the computer browser.
Conclusion: List Which Symptoms You Should See
| symptoms | first check which | most likely points to |
| the whole page is white and spinning | red line plus the longest waterfall bar | a script or font hangs and drags the whole page |
| some images are cracked | Type screening IMG to see the red line | the image bed is stuck or the anti-wired link |
| can be opened but is slow to | The waiting section in Timing is | server slow. It's not that your |
| changes to the site don't take effect | so you check Disable Cache and refresh | cache is causing trouble __ After HTML210__ |
| login redirect, the white screen | check Preserve log to capture the interface error on the destination page | the jump |
order is given as follows: F12, click Network, refresh, first scan the red line, then find the longest waterfall, open it to see which segment Timing is stuck. If you can locate something in one minute, don't guess for half an hour, and don't restart the router right away.
one more nagging, the F12 ledger is a combination of "the website across the street" and "your own network." It says the waiting is long, so you can confidently go find the site owner; It says download is slow, so first check your own broadband. The ledger doesn't lie, but I fear you won't read it. As for those sites where large images of several MB often drag down entire pages, the webmaster should follow this method to self-check: what does CDN mean
