You are on page 1of 5

Time to First Byte 

 
The following document provides definition and information around the KPI Time To First 
Byte(TTFB) including the definition as well as resources you can use to further investigate if 
this is a concern.  
 
Please review this document carefully.  
 
Definition of Time to First Byte 
Why It’s Important 

Next Steps 
Customer’s developer resource review to identify cause 
Review Reports & Dashboards 
Review Business Manager Pipeline Performance 
After research above, if Customer files a Support ticket they need to include the 
following: 

Definition of Time to First Byte  


Time to First Byte time is the time from when the user started navigating to the page until 
the first byte of the server response arrived.  The bulk of this time is usually referred to as 
"back-end time" and is the amount of time the server spent building the page for the user. 

Why It’s Important 


• Potentially highlights ineffectiveness that may lead to scalability issues on the site.  
• Could mean rendering time and document complete is being slowed.  
• If above .5 we recommend your internal development team or SI development partner 
research further. 
 
If you are running front end site speed tests and identify the KPI is trending high, the 
following outlines steps you can take to do further research to identify cause to address.  

Next Steps 

Have your developer resource research   


You should share this information with your internal development resource / or SI partner 
for those resources to do a deeper analysis. 

 
EXTERNAL VERSION: WSP: How to analyze outputs - Revised 1/11/19 Page 1 of 5 
 
SFCC Support wrote a Knowledge Article for troubleshooting TTFB - Issues  
https://support-demandware.force.com/customer/articles/Article/TTFB-Time-To-First-Byte-
Best-Practices 
 
Additional information and tools available to use include:   

Review Reports & Dashboards  


As a diagnostic tool it is good to identify timing - then can check into code version, past 
functional releases.  
● Log​ into R​ eports & Dashboards ​and go to​ Technical Dashboard. S ​ croll to bottom 
of page:  

 
● At bottom of page l​ ocate the specific pipeline ​called out during the engagement.  

● Drill into the specific pipeline (Home-Show, Search-Show, Product-Show).  


● The screenshot below is “Details for Search-Show” pipeline which represents a 
Category Grid p ​ age.  
● Note: Our recommendation is the a ​ verage response time <=400 ms​ and ​cache hit 
ratio above 70%  

 
EXTERNAL VERSION: WSP: How to analyze outputs - Revised 1/11/19 Page 2 of 5 
● This example shows the above KPI’s fall outside our recommendation.  

 
 
Continue fact finding using the ‘Compare Dates’ feature as an 
investigative tool to try to identify when this trend started.  
 
 
 
 
 
 
 
The screenshot below shows a month over month comparison. The ​orange​ trend line 
represents previous month where average response time (appears) to trend lower. This is 
only an example. But, R ​ eports & Dashboards Technical Reports​ is another tool assisting 
our customers.  
 
 
 
 
 
 
 

 
EXTERNAL VERSION: WSP: How to analyze outputs - Revised 1/11/19 Page 3 of 5 
Review Business Manager Pipeline Performance  
BM is good to dive deeper - this is more of the real investigation - where you can see 
controllers and scripts that are making longer calls, etc. From there developers should be 
able to identify the root cause (which part of the implementation is impacting the site 
performance).  
 
In Production Instance, go to: Administration > Operations > Pipeline Profiler  
● You can use to identify to see what is taking longer 
● Where you can see controllers and scripts that are making longer calls, etc.  
● You can see which files / requests are taking longer and so on. 
● Pull this up and sort by average open time, average total time,  
● Script Data link shows javascript functionality 

After research above, if you are still having issues or concerns, 


please a Support ticket - that needs to include the following:  
After completing the following steps, if you still have not identified a root cause OR need 
assistance, ​ log a support ticket.  
 
In the support ticket, the following information is needed.  
1. The specific location and times of the TTFB that is causing the concern. This is 
CRITICAL.  
2. Identify all the steps you have executed in their research. Attach files if necessary.  

 
EXTERNAL VERSION: WSP: How to analyze outputs - Revised 1/11/19 Page 4 of 5 
3. Start the pipeline profiler which is located in Administration > Operations > Pipeline 
Profiler. Let it run for 5-10 minutes. Then capture a screenshot of the report or 
make a copy in Excel, that contains the highlights about the specific slow pipeline. 
This gives all the dropdown information for the load. Provide this information in the 
case. 
4. Provide the .har file - it is captured using the browser developer tools or from online 
web page speed test assessment tools.  
 
 
 
 
 
 

 
EXTERNAL VERSION: WSP: How to analyze outputs - Revised 1/11/19 Page 5 of 5 

You might also like