Notes from this course on Udemy
Introduction to the Elements Panel
You can view code in Chrome, by right-clicking on a webpage and clicking “view page source”
You can see the code of the page, but you can’t do much with it.
Instead, you can right click and choose “developer tools”
The elements panel is normally the default panel that you see:
As you hover over items in the Elements tab, it will highlight the relevant part of the webpage too.
You can right-click and choose “Inspect Element” and the Dev Tools window will open up, with the relevant piece of HTML code highlighted.
For example, if you click the main header of a page, and choose “Inspect Element”, there’s a good chance you’ll be taken to the elements tab and have a “<h1>” highlighted.
You can change the text if you like, and the style – by typing and editing it in the styles panel on the right:
You can click the “+” symbol to add a new style (I couldn’t be arsed putting this screen snippet into Paint to used proper type-text):
- You can right click > Inspect an element and click the delete key to get rid of a style
- Click on the colour picker to get a eye-dropped tool and other colour-picker options to change colours used on the webpage:
Chrome Developer Tools
Click the mobile icon – to see a website previewed on a mobile phone – you can change the phone model with the drop down menu
Console Tab
You can type console.log javascript code. This allows you to see the output of JavaScript code.
Web developers log messages for 2 general reasons:
- Making sure that code is executing in the right order.
- Inspecting the values of variables at a certain moment in time.
- https://developer.chrome.com/docs/devtools/console/
Sources Tab
Files and folders that have been loaded by the webpage, can be found in the Sources tab – e.g. type Jquery to see if a page is using jquery
It’s often used for debugging JavaScript:
“Top” – The top-level, such as top on the screenshot above, represents an HTML frame. You’ll find top on every page that you visit. top represents the main document frame. (more info here)
The second-level, such as developers.google.com on the screenshot above, represents an origin.
The third-level, fourth-level, and so on, represent directories and resources that were loaded from that origin. For example, on the screenshot above, the full path to the resource devsite-googler-button is developers.google.com/_static/19aa27122b/css/devsite-googler-button.
- You can click individual files to view them in the preview pane in the middle:
- Edit CSS and JavaScript
You can edit code and see the changes immediately on the webpage
Image from Developer.chrome.com
CSS changes take effect immediately, no save needed. For JavaScript changes to take effect, press Command+S (Mac) or Control+S (Windows, Linux). DevTools doesn’t re-run a script, so the only JavaScript changes that take effect are those that you make inside of functions.
- You can save snippets of code and run them on any page
Application Tab
See local storage – Open the local storage section – you can see, well the local storage:
I have no fucking idea what any of this stuff means at the time of writing. I think the {“url” etc is some type of JSON
Screenshot from Mozilla
- Cookies
You can also see what cookies are loaded:
Network Tab
Shows a timeline of all the assets that are loaded
Security Tab
You can view security info, like info about the secure certificate/server/https thing
Audits Tab – This doesn’t exist anymore – use Lighthouse/Performance Insights Tab
SEO Checks Using Chrome Dev Tools
Notes from SearchEngineJournal article
1. Check If You Content Is Accessible
The DOM – can be seen in the Elements Tab of Inspect-Element, allows you to:
- Review various content elements includng meta title
- Verify if Google can crawl it
- A key thing to look for here is the differences between source-code and the contents of the elements tab.
Fucking JavaScript
When auditing websites that have heavy JavaScript usage, content – such as page headers – sometimes appears fine in the HTML source code. But if injected via JavaScript, it may just show as a JS block in the Elements tab.
This can potentially be an issue, later verified through performing a site:example.com/page “content you’re looking for” advanced search and checking the cached version of the page.
The blog heading here, appears to be fine and stuff:
2. Check on mobile devices
Use the mobile icon on the top menu-bar, next to the “elements | Console” tab options, to see the page in different mobile devices
3. Site Speed
This can really be useful if you’ve blocked your staging website and 3rd party tools can’t access your URL
From the three-dot burger menu in the top right of the screen, you can access Network Conditions (found under More Tools).
you can throttle the network to slow 3G etc
Disable broswer cache
You can also select from a number of user agents ranging from Googlebot Smartphone through to various Microsoft Edge UAs, and Opera.
Once you have setup the setting for the network – go to the NetWork Tab, and see the page load
4. Render Blocking Resources
As mentioned previously, from the Network tab you can identify which JavaScript and CSS resources are being loaded before the DOM.
While this isn’t necessarily an issue on all websites, having resources load ahead of the DOM can potentially lead to it being blocked, which is one of the more common and resolvable site speed issues.
These can be identified by filtering for JS and CSS in the Network tab:
- You can also see which elements, JS, CSS etc have a 200 status code, and which 404 or are blocked
Notes from another SearchEngineJournal Article
Switch Your User-Agent
In order to switch your user-agent in Chrome, use the Network Conditions tab in the console drawer.
Sometimes security measures on a website might stop Googlebot from crawling
Using the User-Ageny tool in dev tools, it’s possible to see if bots are getting blocked
Diagnosing Core Web Vitals in DevTools
Within the timings section, users can see flags for things like FCP (First Contentful Paint), and LCP (Largest Contentful Paint), one of our Core Web Vitals.
In hovering over the flag for LCP, we can actually see the piece of content flagged to be the largest contentful paint during the page load.
In order to help detect layout shift, use the Rendering tab in the console drawer:
Check the option for Layout Shift Regions, which will highlight areas of the page that undergo a layout shift as content is loaded. (when you go back to the performance tab and refresh)
Layout shifts will then be highlighted in blue as you interact with the page.
3. Double-Check Your HTTP Headers & Review Unused Code
it’s helpful to see the HTTP response codes for every page and resource.
Go to Network Tab
After selecting a resource, the Headers sub-menu in the Network tab allows us to see a host of information regarding the selected file. (headers appears when you click and choose a file)
This includes all HTTP header information, like the Request URL, the Request Method, the Status Code, content-encoding, last-modified date, server, and so much more.
You can lean on this info to:
- Verify GZip compression is enabled.
- Double-check that cache-control is working as expected.
- Verify we’re sending Googlebot and other user-agents the appropriate status code.
Review Unused Code
Use the console tab
Refresh the page
Click “Issues” section, next to the filter:
SearchEngineLand notes
- View the DOM in the Elements panel, to make sure Google can see it
Use this to review the content of any of the page’s elements (such as the title, meta description or page text) to verify that the desired relevant information is shown in each case, to make sure it’s accessible to Google.
When identifying these differences between the content shown in both, you can then take the appropriate steps to verify it’s being indexed correctly: reviewing the page cached version in Google, verifying if the text is being shown in Google’s results when searching for it, using the “Fetch as Googlebot” in Google Search Console and so on.
3. Find Unused JavaScript & CSS
To look for unused JavaScript & CSS open the Chrome Web Devtools, go to elements and press ctrl+shift+P and type coverage; and then select [Show Coverage]
After selecting show coverage you will see the below screen, now you have to click on reload button as you can see in the screenshot and that will finally lead you to the coverage report that will show you the JS & CSS files.
Chrome DevTools for SEO: 8 Brilliant Ways to Audit a Webpage
How to use Lighthouse in Google Chrome Dev Tools
Using Dev Tools Console Panel to Run JavaScript
Notes from Udemy course you can find here.
You can do a few nifty things, that seem a bit pointless at this point, like for example, calling and seeing how many paragraph <p> tags are on a page:
There are 5 paragraph tags, in the example shown above^
You can change the background colour of elements, like paragraphs:
Put the elements in a variable, and then change them with a loop^
Here i’ve changed the background colour of the paragraphs on vanilla-js.com:
Sources Tab & Basic Debugging
Right click on an element and select “inspect”
Go to the sources tab
You can click on lines of code to create a “breakpoint” so the code stops on that particular line of code
Breakpoints – pauses the code at a specific point
More info on setting up breakpoint to pause code in the Google documentation here
Line-of-code breakpoints
Use a line-of-code breakpoint when you know the exact region of code that you need to investigate. DevTools always pauses before this line of code is executed.
To set a line-of-code breakpoint in DevTools:
- Click the Sources tab.
- Open the file containing the line of code you want to break on.
- Go to the line of code.
- To the left of the line of code is the line number column. Click on it. A blue icon appears on top of the line number column.
You can view the local and global scope of the code
The “Filesystem” panel, tells you all the files that make up the current page:
Official Google Documentation for Chrome Dev Tools
Google has their own info and tutorial stuff on dev tools here.
Some Tips from Reddit
document.body.innerHTML = [...document.getElementsByTagName("a")].map(el => el.href).join("<br>");
Note from video^
- Elements tab – we can see HTML representation of DOM – check page elements are in the DOM
- Network tab – see what happens between the server and our browser.
Reload page – and see each request from the server and the response
You can see where time is spent. We can see each element/request – we can see how long it took including the time the server and download took.
We can also see http/response headers – make sure there’s no X-robots tags if you want it indexed
You can click on an element/request, then click on “initiator” and see what requested it:
Network tab can also be used to disable the cache, set network speed and the user agent.
Please note that Googlebot might not always work as expected, real Googlebot will respect robots.txt and some sites might do IP lookups to see if a request is really from a data centre.
Some SEO Checks using Developer Tools:
Dev Tools Checks
Inspect main elements – are they visible in the inspect window? e.g. right click and inspect the Headings – check <head> has meta title and desc
Check on mobile devices
Check all the elements result in a 200 – view the Network tab
Network Tab – Check with Googlebot
Console tab – refresh page – what issues are flagged?
Unused JS in the elements tab – coverage
Check for client rendered links using the code above , using the console tab