GOOGLE CHROME DEVELOPER TOOLS – By Abishek Manimaran

The Google Chrome web browser includes Developer Tools, a

feature that helps web developers debug issues with HTML, CSS,
and JavaScript:

 To access Developer Tools on Microsoft Windows or Linux,

press Ctrl+Shift+I.
 To access Developer Tools on Apple Mac OS X,
press Option+Command+I.

The following image shows Developer Tools open on the Google

home page:

On the Network tab of the Developer Tools pane, Chrome lists all
connections for the current page. To test a specific page, open
Developer Tools and navigate to the page you want to test.
Alternatively, if you want to test the current page, simply refresh the
page.
Chrome displays information for each page resource and its
request:
Name: The name or URL of the requested resource.
Method: The HTTP method (GET or POST).
Status: The HTTP status code returned by the server.
 Type: The MIME type of the resource.
Initiator: The referer sent to the server; this is usually the URL of
the page you are viewing.
Size: The size of the resource as received by the browser (if the
page was compressed by the server, this value is smaller than the
actual filesize).
Time: The total time to retrieve the resource, including DNS lookup
and download time.
Timeline: The timeline is a “waterfall” time-lapse view of each
request. If you hover your mouse pointer over a bar on the waterfall,
a tooltip appears with a detailed breakdown of the download time:

 Blocking: This includes time for the DNS lookup, SSL

handshake, and making a connection to the server.
 Sending: This includes time to send the request with all request
data to the server, and to receive confirmation from the server
that it has received the request.
 Waiting: This includes time for the server to render the content to
be served, and to start sending it to the browser.
 Receiving: This includes the time it takes to download the
content.

Sometimes the server starts sending content before it is done

generating it. For example, a PHP script can start sending HTML,
even though it is still dynamically generating page content. This
type of scenario can lead to incorrect wait time measurements.
The combination of waiting and receiving times is the most
important factor in determining site speed. However, internet
connection speed can also affect performance, so you should
always compare times from the same location when you are
establishing site performance benchmarks.
At the bottom of the Network tab is a summary of the page load
process. This summary includes the total number of requests, the
total size of the entire page including its resources, and a
breakdown of the time spent rendering the page in the browser.
 The first time value is the total time spent loading all of the content
on the page. This value includes content loaded by
JavaScript after the page has rendered; as a result, this number
can change if requests occur in the background.
The two time values Inside the parentheses are events important
for site optimization:

 load: This event is the time to load the page, including all of the
JavaScript, CSS, and image files that are in the original HTML
document. This event generally takes longer than
the DOMContentLoaded event.
 DOMContentLoaded: This event represents the perceived time
by a user to load the page. It is the time to render the page as
described in the original document before JavaScript requests
additional resources. This time is stored when the browser fires
the DOMContentLoaded event in JavaScript. (An example of a
resource that is requested outside of the DOM is Google
Analytics.)

Website Speed Performance Metrics#

Attention spans are getting shorter, not longer. Customers make snap judgments
about a company’s professionalism, so don’t let the first thing they see be a big,
slowly loading blurry logo. To fully understand user retention, we have to breakdown
the user experience piece-by-piece.

To retrieve the results of many of the metrics below for your particular site you can
run a speed test over at webpagetest.org. Note that not all metrics will be displayed
on the summary or performance review pages. To access more granular metrics you
will need to download the raw page data report as shown below.

The following site speed test results were are taken from a default WordPress test
site running on Nginx and KeyCDN with no special configurations.

1. Time To Title#
The amount of time between the instant a visitor requests your website and the
moment your site’s title shows up in their browser tab is called the time to title.
Seeing a title right away lets the user know that your website is legitimate, which
makes them more likely to wait for the page to finish loading. Time to title is
determined by the speed of delivery from your origin server to the user’s browser. As
shown in the results below, the time to title for our test site was 464ms.

2. Time To Start Render#

The time elapsed between a user’s request and the moment when content appears in
their browser is called time to start render. This is also a very important metric to
analyze as the sooner a visitor sees content appear, the more likely they will be to
stay for the rest of the page to load. The time to start render, in this case, was 1019ms.

3. Time To Interact#
The time between a request and the moment when a user can click on links, type in
text fields or scroll the page is called time to interact. Some elements such as scripts
and trackers may continue to load during this period.

4. DNS Lookup Time#

The amount of time it takes for your DNS provider to translate a domain name into
an IP address. Services such as Pingdom or WebPageTest can quickly calculate your
website’s DNS lookup times for each domain it must lookup.

Visit our article to learn more about how to reduce DNS lookups. Additionally, check
out our list of best free DNS providers for more information regarding what’s
available in terms of DNS services.

5. Connection Time#
The time between a request and when a connection is established between the user’s
browser and your origin server is called the connection time.

Identifying challenges to connection time can be difficult because it depends on

many factors. Too much server traffic, whether it be from users or bots, can
cause connection times to spike. Users in different geographic regions are likely to
experience longer connection times. Simply monitoring your website performance
metrics over time may not give you enough information to address problems; you
can experiment with load testing tools such as LoadStorm or JMeter to simulate
heavy server usage. To ensure better connection time, you may need to upgrade
your infrastructure. Alternatively, you could offload some assets onto a CDN or
caching server.

6. Time to First Byte#

The time it takes for the very first byte of information to reach a user’s browser after
a connection to the server has been established is called time to first byte or TTFB.
The order in which users receive information is important, and some slight alterations
in your code can boost this website performance metric.

Static content that appears the same to all users should be separated from dynamic
content that is specific to the individual visitor. This way, users will receive your
content right away while waiting for slower personalized content to load. Rigorous
metric monitoring and load testing can help developers identify time to first byte
issues. You can also use the KeyCDN performance test to view the TTFB of a domain,
or single asset, from 14 test locations.

7. Time to Last Byte#

When the user’s browser finally receives each and every byte of your website, the last
byte time is recorded. The quality of your code and database queries play a big role
in this metric. Other factors that may be affecting your TTLB include a misconfigured
webserver, or if the origin server has reached its capacity.

Content Complexity and Website Performance Metrics#

Keeping track of website performance metrics involving time isn’t very useful if you
don’t understand all of the other factors at play. Information about your website’s
content complexity can help you find ways to improve all of the previously discussed
metrics.

8. Overall Weight#
The total number of bytes the user receives is referred to as the overall weight of
your website. More important than the overall weight is the relationship between
each asset since one heavy asset can slow down everything else. Furthermore,
the growth of web page size has continued to expand year after year, therefore it’s
important to sometimes step back and see which assets are truly necessary.

By separating individual metrics such as JavaScript weight, CSS weight, image weight
and total asset weight, you can pick out which categories are too heavy, and then
you can perform a waterfall analysisto identify the asset that needs to be altered or
removed.
9. Overall Asset Count#
The number of assets you have obviously affects your website’s overall weight, but
it’s important to differentiate between asset count and weight. Every asset, no matter
how small or compressed, has the potential to add more time to the loading process.
Your overall asset count includes your total JavaScript, CSS and image counts.

See how we improved WordPress performance and went from a 532ms load time to
167ms by reducing the amount of HTTP requests made.

10. Third-Party Domains#

The majority of your website’s content is hosted on your domain, but many sites also
include third party content such as embedded videos or social media widgets.
Because these items originate from other domains, you have limited control over
their functionality. Therefore, the potential for problems rises with each domain that’s
in play. Only rely on other domains that can guarantee impeccable performance, or
else a third party could compromise your users’ experience.

User Behavior and Website Performance Metrics#

Now that we’ve covered the technical aspects of website performance, let’s discuss
what visitors actually do after clicking a link to your website.

11. Error Rate#

The first important non-speed-related metric to keep an eye on is your website’s
error rate. The average number of problem requests compared to total requests is
your error rate. This metric is likely affected by your number of concurrent users; test
your website’s performance under different loads to check.

For example, you may notice that your error rate starts to increase at a specific point
during a load test, such as when a certain number of concurrent users are attempting
the same action. If you’re expecting a sudden surge in traffic due to a special
promotion or event, this information can help you prepare. Some errors are
inevitable, but keeping an eye on the number of errors your website is encountering
can help minimize larger issues down the road.

If you’re using KeyCDN, you can use the Reporting section to see how many client
errors your Zone(s) have encountered over a specific period of time.

12. Bounce Rate#

If your bounce rate is high, that means something is making users turn away without
thoroughly exploring your site. Google calls such visits “single-page sessions,” and
too many of them can impact your SEO. Possible causes of high bounce rates might
include poorly targeted keywords, slow load times or unpleasant graphic design.
If you make changes and your bounce rate starts declining, then you’re doing
something right. Check out our detailed post about 21 ways to help reduce bounce
rate on your website.

13. Top Pages#

You can find out which of your pages draws the most traffic by simply checking
under the Behavior section of Google Analytics. Knowing where users focus their
attention can give you an idea of which content is helping you retain an audience.
Keep in mind that the number of views a page receives isn’t the only measure of its
relevancy; the number of shares a page receives via social media is also important.

14. Conversion Rate#

Perhaps the most important of all your performance metrics, the conversion rate is
the most intimately connected with your bottom line. When it comes to optimizing
user experience, your conversion rate is more important than your overall conversion
numbers because it lets you know if users are doing what you want them to do when
they visit your site. A Conversion rate is calculated by simply dividing your number of
unique visitors by your number of conversions. Google Analytics can track this
information over time, but defining a “conversion” is up to you.

The chart below shows the correlation between website load time and conversion
rates.

Source: Forbes

If your conversion rate is low, you may be attracting the wrong kind of traffic, should
improve upon your website speed metrics, or might have an inefficient call to action.

Perceived Performance vs. Performance Metrics#

Sometimes numbers don’t tell you everything you need to know, which is why it’s
important to understand how web users think. Perception is everything, and
sometimes there’s a difference between how long it takes for a page to load and
how long the user “feels like” it’s taking.

For example, implementing lazy loading can technically make your website faster, but
adding a progress indicator to individual assets as they load makes users more
conscious of the passing time, so they actually perceive the website as loading
slowly. If you’re going to use lazy loading, be sure to leave out the indicator.

FOUT, or flash of unstyled text, is another issue that impacts user perception. FOUT
occurs when fonts are loaded toward the end of the DOC load, so characters appear
as blurry blocks before turning into recognizable letters and numbers. FOUT doesn’t
affect your website’s actual speed, but it is visually jarring and makes users more
aware that they are waiting for the page to load.