A slow browser session is easier to investigate when you can name the task consuming resources. A large total beside Chrome in the operating system does not tell you which document, video or extension was active. Start while the slowdown is actually happening.

Record the workload

Note the activity and approximate time: for example, scrolling a large online spreadsheet while a training video plays. Save the spreadsheet and other editable pages before experimenting. A diagnostic action should not destroy the work whose performance you are trying to understand.

Open Chrome’s menu, choose More tools, then Task manager. Sort the memory column and inspect the task names. Google also recommends checking background-page entries. Record a few relevant names and their readings without copying confidential document titles into a public support request.

A large reading is a clue, not a finding that the page is defective. A complex document may legitimately require more resources than a simple website. Observe whether the same task stays prominent after its activity has settled, and whether the slowdown coincides with that task’s work.

Change one part of the session

If a nonessential page responds, close it normally after saving anything needed. Repeat the original slow action in the remaining application. Record whether scrolling, typing or switching tabs improved; “less memory” alone is not the outcome the user needs.

For a task that will not respond, Chrome offers End process. Google warns that unsaved work in that task will be lost. Select the named task deliberately rather than terminating unfamiliar rows at random.

Reopen only the page needed for a comparison. If the slowdown returns with the same workload, provide that sequence and the task observation to support. If the whole computer remains slow after the browser workload is reduced, broaden the investigation instead of repeatedly killing Chrome processes.

Sources: Chrome documentation.