Sử dụng WebPageTest để kiểm tra Front-End Web Application – Part 2

Bài trước mình có giới thiệu về cách cài đặt WPT ở local machine (bạn nào chưa xem có thể xem lại ở link). Bài này mình sẽ nói về cách sử dụng WPT cũng như làm sao để xem và phân tích kết quả trả về từ WPT.

01-en

Nói sơ qua 1 chút về mục đích của WPT cho mọi người được rõ, do hồi đó mình cũng tìm hiểu cách để benchmark/performance/monitoring FE lúc đó bị lẫn lộn giữa RUM (Real User Monitoring) và Synthetic. Vì thế bảng so sánh dưới đây sẽ cho các bạn hiểu 2 cái thằng đó khác nhau như thế nào:

WPT_23.png

 

Một vài tính năng chính của WPT

Simple Test

WPT_1

Đúng như tên gọi của nó, chỉ là nhập vào đường dẫn của trang mà bạn muốn kiểm tra, chọn thiết lập máy để run test cũng như browser dùng cho việc run test, sau đó chỉ việc click nút “Start Test”.

Advance Settings

WPT_2

Test settings: ở đây các bạn có thể thiết lập nhiều thứ như, giả lập bóp băng thông, số lần run của test, chế độ run test ở dạng page sau khi có đã được cache và không được cache trên browser.

WPT_3

Advanced: cho phép bạn thiết lập thêm những thông số khác như thời gian tối thiểu run của 1 test (hiện tại WPT bản C/C++ đang có bug cho option này), lưu thông tin về network

WPT_4

Chrome: đây là tab dành riêng cho chrome (theo mình thì hiện tại Chrome là browser hỗ trợ tốt nhất cho tester trong mọi thứ từ việc test functional cho tới performance), để sử dụng metric Interactive Time thì các bạn phải chọn option “Capture Dev Tools Timeline”, thường mình sẽ chọn bộ 3 “Capture Dev Tools Timeline”, “Capture Chrome Trace” và “Capture Network Log”, ngoài ra tab này cũng hỗ trợ việc sử dụng tính năng giả lập mobile device trên chrome.

WPT_5

Script: Đây là phần đỉnh của đỉnh ở WPT, ở tab này các bạn có thể viết những action nhỏ để dùng cho việc đo performance những component trên page, ví dụ mình muốn kiểm tra với facebook khi click switch giữa các tab trong trang profile thì nó sẽ load bao lâu. Lưu ý: vì mình đang làm chủ yếu về performance nên khi bạn viết script để giả lập user action cũng nên đắn đo cho kỹ vì có thể viết càng nhiều thì khi run có khả năng xảy ra lỗi càng cao, cũng như độ phức tạp của report cũng tăng lên, khi đó sẽ mất thêm thời gian để đọc và phân tích :)) đừng có cố gắng đem cái Functional Testing gộp chung với cái Performance Testing, hiện tại mình thấy nhiều ý tưởng về việc kết hợp 2 cái lại để tận dụng thời gian chạy test nhưng thường chỉ có hại chứ ko có lợi, còn vì sao có hại thì lý do là ở performance testing cho FE luôn cần 1 khoản thời gian nhất định để xác định khi nào page đó đã render xong (thường kết hợp rất nhiều yếu tố, CPU của browser, network activity, etc… và vì như vậy nên có khi run test cho 1 page bạn sẽ mất cỡ 5-10 phút, nên có ai muốn run 1 cái performance test kết hợp với E2E test để rồi sau đó 1 tuần hoặc 2 đến 3 ngày sau bạn mới có được kết quả không)

WPT_6

SPOF: mình gọi nó vui vui là lỗ đen vũ trụ, mục đích của option này là dùng cho việc bạn giả lập tình huống khi Web Application của bạn có sử dụng 1 thư viện thông qua CDN (Content Delivery Network), chuyện gì sẽ xảy ra nếu vô tình cái CDN đó bị sập hoặc nói vui mạng ở VN bị cá mập cắn =)), web của bạn có hướng khắc phục cho tình huống này không, nếu nó xảy ra thì web của bạn có render được không, nếu có thì sẽ render trong bao lâu =)) 10s hày 30s hay là 5 phút.

Test Result

Mình sẽ giới thiệu sơ sơ nó có những gì còn phần dưới mình sẽ đi sâu hơn về các tính năng thông qua việc hướng dẫn cách đọc report của WPT.

WPT_7

Summary: như tên gọi, tab này cho bạn các metrics cơ bản của kết quả run test.WPT_8

Details: tab này sẽ chứa nhiều thông tin hơn, và đa phần mình dùng tab này chủ yếu đê phân tích xem website mình bị bottleneck ở đâu trên FE

WPT_9 Performance Review: tab này là phần đánh giá điểm của WebPageTest  =)) mình gọi chỗ này là phần tự sướng (run test và nhận về kết quả toàn A thì cảm thấy sướng vãi)

Cách đọc kết quả của WPT

Theo mình (đây là ý kiến chủ quan của mình nhóe, vì đôi khi có bạn sẽ nói cái khó khăn là xác định scenario làm sao để nó giống với thực tế nhất hoặc làm sao để run test với số lượng VUs lớn) thì đa phần ở performance test cái khó khăn nhất là viết test script để run performance (tùy web application mà có thể công việc này dễ hay khó, web nào kỹ thì sử dụng nhiều cái hidden token để bảo mật như JWT, CSRF, middlewaretoken, etc.. thì việc develop script nó cũng hơi thốn thốn) và cái kế tiếp là làm sao để đọc cái report và báo cáo lại cho ở trên,  làm thế nào để giữa 1 rừng những metrics, những cái chart, những cái graph mà bạn chỉ cần tóm tắt lại trong vài câu cho sếp hoặc client đại loại như  ” xét theo cái mớ metrics hỗn độn mà kết quả run performance  test trả về thì web của ta đang bị bottleneck ở page A, sự cố xảy ra do DB chưa được tối ưu” hoặc ” nhìn hình ta có FE của web ta đang bị bottleneck ở Page B do phần execution script của file C quá lâu nó block mọi thứ render phía sau nó”. Thôi lang mang chém gió quá trời giờ vô phần trọng tâm, làm sao để đọc report của WPT.

YChallenge-Accepted-Meme

Navigation Timing

Thuở xa xưa khi mọi thứ còn giản đơn, page sẽ render xong khi sự kiện loadeventEnd được gọi ra và khi đó tính render time nó đơn gian như đang giỡn. Tuy nhiên ngày nay những metrics của Navigation Timing chỉ là 1 phần trong những thứ được dùng để tính toán kết quả performance của FE, dưới đây mình sẽ nói sơ qua về vài metrics chính của Navigation Timing.

Navigation Start: Sự kiện bạn bắt đầu navigate đến 1 page nào đó. Còn nếu như bạn đang ở blank page trên browser thì nó sẽ gọi cái này là sự kiện fetchStart (sự kiện mà browser bắt đầu fetch 1 cái request cho page mà người dùng muốn load)

Unload Events: Sự kiện khi mà bạn bắt đầu navigate đến trang khác (nhập vào 1 URL khác hoắc click vào back/forward trên navigation bar trên browser). Sự kiện này có 2 metrics gồm  PerformanceTiming.unloadEventStart  và PerformanceTiming.unloadEventEnd

Redirection: Sự kiện khi mà request của bạn được redirect, nó báo gồm 2 metrics PerformanceTiming.redirectStart PerformanceTiming.redirectEnd.

Domain Lookup: Sự kiện khi mà browser bắt đầu thực hiện việc tra cứu tên miền, nó được thể hiện qua 2 metrics  PerformanceTiming.domainLookupStart và PerformanceTiming.domainLookupEnd. Nếu như trước đó bạn đã có 1 connection và vẫn đang tồn tại(keep-alive) thì metric này sẽ lấy dựa vào PerformanceTiming.fetchStart.

Connection Times: như tên gọi của nó, sự kiện này sẽ chứ những thông tin bao gồm thời gian mà request bắt đầu mở 1 connection đến host ( PerformanceTiming.connectStart) và thời điểm khi mà connection thành công (PerformanceTiming.connectEnd). Với https thì có thêm metric PerformanceTiming.secureConnectionStart.

Request/Response Times: ở đây có các metrics cho việc thời gian send request và thời gian nhận được response, cái này khác hoàn toàn cái Connection Times nhóe, Connection Times chỉ là thời gian mà request đó mất bao lâu để mở được connection tới host.

DOM Events: có rất nhiều sự kiện khác nhau ở DOM nhưng ở đây mình chỉ nhấn mạnh vài sự kiện quan trong

  • domLoading: thời điểm mà browser bắt đầu thực hiện việc parsing thông tin từ HTML string được trả về từ request. ( nguyên câu tiếng anh This signifies the time that the browser is going to start parsing of the bytes of HTML that have been received.).
  • domInteractive: thời điểm mà browser đã hoàn thành việc parsing HTML string và xây xong cây DOM. Lúc này cây DOM đã có thể sử dụng được.
  • domContentLoadedEventStart và domContentLoadedEventEnd: thời điểm mà lúc này browser bắt đầu thực hiện việc render cho DOM tree. Dưới đây là hình mô tả quá trình này

WPT_10

  • domComplete: thời điểm mà mọi thứ đã xong, lúc này bạn sẽ thấy ký hiệu refresh button hiện ra trên navigation bar của browser.

Load Events: đây là sự kiện cuối cùng sau khi mọi thứ đã được browser xử lý xong. Ở traditional web site thì khi sự kiện này xuất hiện cũng đồng nghĩa với page đã render xong 😥 còn bây giờ thì khi sự kiện này xuất hiện thì nó chỉ đồng nghĩa với background page đã được dựng xong và lúc này thì việc kế tiếp là thằng đệ JavaScript sẽ thực thi để đập tiếp những cái chi tiết khác cho GUI.

Sử dụng Navigation Timing để xác định KPIs

Mượn tạm cái hình mô tả quá trình xảy ra ở Browser để cho các bạn dễ hình dung

WPT_11

  • Total First byte Time = responseStart – navigationStart
  • Latency = responseStart – fetchStart
  • DNS / Domain Lookup Time = domainLookupEnd – domainLookupStart
  • Server connect Time = connectEnd – connectStart
  • Server Response Time = responseStart – requestStart
  • Page Load time = loadEventStart – navigationStart
  • Transfer/Page Download Time = responseEnd – responseStart
  • DOM Interactive Time = domInteractive – navigationStart
  • DOM Content Load Time = domContentLoadedEventEnd – navigationStart
  • DOM Processing to Interactive =domInteractive – domLoading
  • DOM Interactive to Complete = domComplete – domInteractive
  • Onload = loadEventEnd – loadEventStart

User Timing

User timing là cách mà chúng ta có thể dùng để lấy thông số thời gian xử lý của những đoạn code JavaScript cụ thể. Các bạn có thể xem ví dụ ở link sau, mình sử dụng user timing để đo thời gian thực thi việc render table.

WPT_12

Đọc kết quả ở Summary tab

192.168.74.24-results.php-test=170921_YS_95d51d6d39bce229b9da7465923466ed

Việc đầu tiên là nhìn vào cái bảng metrics. Bảng này tổng hợp những thông tin có được ở lần chạy test, nó bao gồm những metrics quan trọng trong việc đánh giá ban đầu về web của chúng ta, bây giờ bắt đầu nhìn vào để phân tích, đọc từ trái qua phải ở bảng dưới đây:

WPT_13

  • LoadTime: hay còn được biết đến là “document complete time”. Thời gian này được xác định từ thời điểm page bắt đầu thực hiện request đầu tiên cho tới khi sự kiện onload xuất hiện. Nếu là traditional website thì có thể lấy metric này để xác định thời gian render page.
  • First Byte: Thời gian mà browser nhận được byte đầu tiên (theo mình tìm hiểu thì cái này là của request đầu tiên, mình ko chắc 100%)
  • Start Render: Thời gian mà browser vẽ layer đầu tiên trên GUI, thường có thể chỉ là vẽ cái nền background hoặc thâm chí nếu code FE thời điểm này bạn append 1 cái dấu chấm thì thì nó sẽ được tính là time start render cho chính dấu chấm đó không thôi.
  • User Time: Tổng hợp những metrics mà khi bạn sử dụng User Timing trong chế độ script
  • Speed index: đây là metric do chính WebPageTest khởi xướng (các bạn có thể tham khảo chi tiết ở link sau). Metric này sẽ cho bạn điểm số về khả năng hiển thị GUI của page với user, ví dụ page bạn render hoàn toàn xong trong 10s, ở thời điểm 2s mà bạn render được 90% page thì khi đó điểm số speed index sẽ là 200, tương tự như vậy nhưng nếu ở thời điểm 8s page bạn mới render được 90% GUI thì khi đó điểm speed index của bạn sẽ là 1000. Đây là metric cho bạn biết về trải nghiệm người dùng với page của mình, điểm số càng thấp thì sẽ cho trải nghiệm người dùng tốt hơn. Lưu ý là nó không dùng để cho biết page bạn render có nhanh hay không nhé. Còn chi tiết cách WebPageTest tính ra điểm số đó thì bạn cứ vào link mình đã nói ở phía trên.
  • First interactive(beta): đây là 1 metric đặc biệt và hiện tại nó chỉ có khi bạn run test với browser là Chrome và có chọn thêm option “Capture Chrome Timeline”. Metric này sẽ cho bạn biết sau khoảng thời gian bao lâu thì người dùng có thể tương tác được với Web Application của mình, đây là 1 metric cũng dùng để đo trải nghiệm người dùng. Theo mình biết thì nó là 1 metric mới được phát sinh ra sau này, và nó đi theo thuật ngữ “Progressive Web Applications”  nêu mình nhớ không lầm người khởi xướng nó là cái anh chàng developer đã làm ra cái tool LightHouse mà hiện tại Chrome Browser đang sử dụng nó như tool audit performance FE.

Đây là cách để tính toán ra con số này, các bạn chịu khó đọc tiếng Anh nhé :v mình cũng lười dịch ra quá, nó chia làm 2 dạng tính TTI khác nhau, 1 là Time to Consistently Interactive Calculation và 2 là Time to First Interactive Calculation, cả 2 khác nhau chủ yếu chỗ xác định thời điểm có còn tồn tại request ở network hay không.

How to calculate interactive time
Underlying Measurements(How to calculate interactive time)
TTI is built on top of a collection of other measurements, some of which are currently only available in Chrome:

Time to First Contentful Paint

  • The measurement is of the first paint of text or an image.
  • Chrome exposes this measurement as a “blink.user_timing” trace event with a name of “firstContentfulPaint”.

Interactive Window

  • The browser’s main thread is considered “interactive” when it is not blocked for more than 50ms by any single task so it will be able to respond to user input within 50ms. An interactive window is a period of at least 5 seconds where there are no main-thread tasks that take more than 50ms.

In-flight requests

  • At any point in time this is the number of outstanding requests.

Time to Consistently Interactive Calculation

  • Start looking for TTI at the first contentful paint
  • Look for the first interactive window where there is a contiguous period of 5 seconds fully contained within the interactive window with no more than 2 in-flight requests
  • TTI is the start of the interactive window from step 2 or the first contentful paint, whichever is later

Time to First Interactive Calculation

  • Start looking for TTI at the first contentful paint
  • Look for the first interactive window where there is a contiguous period of 5 seconds fully contained within the interactive window regardless of the number of in-flight requests
  • TTI is the start of the interactive window from step 2 or the first contentful paint, whichever is later
  • Document Complete Time: tương tự Load Time
  • Requests: tổng số request page đó đã thực hiện trước khi load event xuất hiện, nó không bao gồm request đầu tiên
  • Bytes In: tổng số bytes được tính cho trước khi event load xuất hiện.
  • Fully Loaded Time: đây là metric được tính từ thời điểm khi có request đầu tiên cho tới khi WPT xác định rằng đã hoàn toàn load xong, WPT sử dụng thêm 1 thông số là network activity, mặc định giá trị luôn là 2s, tức là WPT sẽ đợi thêm 2s sau khi xác định page đã render xong để kiểm tra liệu có xuất hiện thêm 1 function JavaScript nào đó send request để render tiếp GUI không (mình từng check 1 page để 2s thì page vẫn chưa render đủ nhưng tăng lên 10s thì lúc này bạn sẽ thu thập được đầy đủ thông tin nhất), các bạn có thể thay đổi thông số này ở chế độ script thông qua từ khóa setActivityTimeout.
  • Requests (trong fully loaded time): tổng số request đã thực hiện của lần run test này (có thể bao gồm cả những request được sinh ra do JavaScript thực thi Ajax để render GUI)
  • Bytes In (trong fully loaded time): tổng số bytes được tính ở lần run test.

Ở tab này thì các bạn cần lưu ý 2 điểm sau

  • Các thông số của First byte, start render, bytes in fully loaded và first interactive  là những con số càng bé càng tốt. Nó sẽ cho bạn biết rằng Web của bạn đang cho trải nghiệm người dùng tốt nhất, người dùng có thể tương tác với web lẹ nhất cũng như mọi thứ được render cũng nhanh nhất.
  • Với chế độ run kèm theo repeat view thì mọi thông số của nó nên bé hơn so với first view, nếu như kết quả cho lại tệ hơn first view thì có khả năng page của bạn chưa thực sự làm tốt việc caching

Đọc kết quả ở Details tab

Waterfall view

Waterfall chart luôn là thứ đầu tiên bạn nên nhìn khi mở sang tab details, nó sẽ cho bạn biết mọi thứ về page của bạn khi thực hiện việc render

WPT_14

Ở trang detail result  chúng ta có thêm 1 cái bảng về những metrics, bảng này cũng tương tự như bảng ở summary tab chỉ khác là có thêm metrics của “Visually Complete”, metric này sẽ cho bạn biết thời gian mà page bạn đã render xong. Lưu ý là nó có thể lớn hơn hoặc bé hơn cả metric trong Document Completed vì có thể page đó việc render GUI không nhiều nhưng việc thực thi code JavaScript khá nhiều dẫn tới sự khác biệt trên.

Giải thích về những metrics và thông tin của waterfall chart

Request phase:

WPT_15

Request phase information:

DNS lookup: thời gian cho việc phân tích địa chỉ host sang những con số IP, ví dụ khi bạn gõ toilatester.wordpress.com và nhấn enter thì browser sẽ làm cách nào đó để biết rằng với cái chuỗi string đó nó sẽ chuyển thành địa chỉ IP 192.0.78.12. Nó cũng giống như khi bạn chuẩn bị gọi điện thoại cho ai đó bạn phải nhìn vào danh bạ và tìm số điện thoại của người đó.

Initial connection: đây là thời gian mà browser thực hiện việc kết nối tới server, nếu như ở DNS lookup nó giống như việc  tìm số điện thoại trong danh bạ thì việc thực hiện initial connection giống như việc bạn nhập số điện thoại xong và nhấn nút gọi.

SSL negotiation: đây là thời gian mà browser cũng như server thống nhất việc thực hiện kết nối thông qua cổng an toàn, đối với những request http thì bước này sẽ không có.

Time to First Byte (TTFB): thời gian mà browser send request cho tới lúc nhận được Byte đầu tiên của response, dưới đây là ví dụ cho việc tính TTFB

Content download: thời gian mà server gởi toàn bộ thông tin của response tới browser. Thông số này phụ thuộc vào độ lớn của response body cũng như tốc độ đường truyền mạng.

Page Level event:

WPT_16

Start Render: thời gian mà browser hiển thị pixel đầu tiên của nội dung trên GUI. Đây là metric riêng của WPT và được tính bằng các thuật toán ở dưới (anh Patrick Meenan người đẻ ra cái WPT dùng mấy thuật toán về xử lý ảnh để tính toán thời điểm cũng như thời gian cho metric này). Về event này thì nó có đến 2 dạng 1 là do WPT xác định và cái thứ 2 là do chính browser quăng ra, cái đó được WPT chuyển thành RUM first paint.

RUM First Paint: thời gian mà browser thực hiện việc hiển thị nội dung trên GUI, đa phần giá trị này sẽ đúng nhưng cũng có trường hợp nó sẽ sai, ví dụ như khi browser không paint gì hết mà chỉ thực hiện việc đổ màu background. Bạn có thể nhìn ví dụ của facebook, RUM first paint có rất sớm nhưng chả gì ngoài cái màu trắng tinh khôi.

DOM Interactive: thời gian mà browser có thể tương tác được với DOM tree.

DOM Content Loaded: thời gian mà browser đã parsing xong DOM tree và lúc này thực hiện add những JavaScript function cho những element như button hay input.

On Load: thời gian mà mọi thứ ở DOM đã xong bao gồm cả việc gán function cho Web Element event.

Document Complete: thời gian mà khi browser xuất hiện event onload, đây có thể là thông số dễ gây nhầm lẫn vì có thể onload đã xong nhưng chưa chắc page đã render xong hoặc page đã hoàn toàn load xong, vì thế WPT mới thêm thông số fully loaded bằng cách kiểm tra network activity

Phân biệt ý nghĩa của màu sắc được highlight trên Waterfall chart:

WPT_17

Errors (red): màu đỏ cho những request có lỗi 404, 503, 502

Redirects (yellow): màu vàng cho những request được redirect

Nhận diện Waterfall View cho kết quả tốt và xấu

Ngoài những con số cũng như màu sắc thì nếu tinh tế bạn có thể nhìn thấy hình dạng của Waterfall View sẽ cho bạn cái nhìn về performance của trang web, hình dạng của Waterfall có thể rất đa dạng từ ngắn, dài, rộng hay hẹp(mình thích hẹp :”>). Vì thế việc bạn nhận biết được hình dạng của Waterfall View cũng là cách đầu tiền có cái nhìn tổng thể về performance của trang web. Dưới đây là vài ví dụ cho các bạn dễ hình dung:

WPT_18

WPT_19

Khi đọc vào 1 Waterfall View thì các bạn nên chú ý những điểm sau:

  • Orange bars (TCP connection)
  • Green bars (TTFB)
  • Bright green bars (TTFB pending)
  • Blue bars (content download)
  • Chiều dài của blue bars (content download size)

Mỗi đường màu sắc trên đại diện cho những hoạt động khác nhau của browser khi hiển thị Page cho user, và nó thường sẽ có ích cho bạn trong việc nhận diện những vấn đề mà web của bạn đang có.

Orange bars (TCP connection):

Nó hiển thị quá trình thực hiện three-way handshake, thường thì bạn không thể nào kiểm soát được tốc độ của việc thực hiện 3-way handshake nhưng bạn có thể thực hiện được việc kiểm soát nên có bao nhiều connection sẽ phải thực hiện quá trình này. Càng nhiều connection mở ra thì sẽ dẫn tới page của bạn load càng lâu. Thường lỗi này là do chúng ta không thực hiện việc keep-alive connection.

Green bars (TTFB):

Cho biết thời gian mà browser nhận được byte của response.

  • Nếu có quá nhiều Green bars: bạn đang có rất nhiều resource cần phải tải từ server trước khi nó có thể render được trên page, để tránh tình trạng này thì có rất nhiều cách cũng như kỹ thuật khác nhau như  hợp nhất những file resouce lại với nhau để giảm số lượng file mà browser cần phải tải, cấu hình browser cache để tránh việc phải request cùng 1 resource cho nhiều lần khác nhau
  • Đường green bars bị kéo dài: bạn đang có vấn đề với latency, bạn có thể sử dụng CDN để giảm thiểu latency lại (thường CDN sẽ luôn tìm kiếm những server gần user nhất và vì thế TTFB sẽ không quá lớn)

Blue bars (Content Download):

Cho biết thời gian mà resource đó được gởi thành công từ server tới browser.

  • Nếu có quá nhiều blue bars: page của bạn đang có quá nhiều resource cần tải, 1 kỹ thuật có thể dùng để tránh tình trạng này là auto-preloading.
  • Nếu đường blue bars bị kéo dài: file resource quá lớn, để tránh tình trạng này thì bạn có thể nén lại file resource trước khi thực hiện việc gởi cho browser (thường mình sẽ minify những file đó và cấu hình cho server thực hiện việc nén thêm lần nữa)

Mẹo nhỏ khi đọc Waterfall View

Các bạn có thể customize Waterfall View theo ý mình để hiển thị chi tiết những thông số bạn cần phân tích, để mở trang customize Waterfall View thì bạn click vào  ‘customize waterfall’  ở dưới cái Waterfall View chart:

WPT_20

Ở trang này các bạn có thể tùy chính thời gian hiển thị request cũng như chart-Y, hoặc chỉ định request số bao nhiêu sẽ hiển thị trên chart.

Vài điều lưu ý khi đọc Waterfall View:

  1. Đường kẻ dọc “Start Render” và đường ” Document Complete” nên xuất hiện ở mốc thời gian càng sớm càng tốt và khoảng cách giữa 2 đường này nên nhỏ nhất có thể
  2. Càng ít hàng trong Waterfall View càng tốt (càng ít requests càng tốt =)) )
  3. Càng ít request thực hiện việc open connection càng tốt
  4. TTFB càng ít càng tốt và nếu có thì càng ngắn càng tốt (ngắn cũng có lợi chứ ko hẳn dài là sướng =)) )
  5. Càng ít nội dung download càng tốt, phân phối cho đều chẳng hạn, ví dụ để vô Page B ta phải vô Page A mà ta biết Page A nó không có download gì nhiều resource trong khi page B có nhiều resource cần download thì ta có thể gởi ké cho thằng A vài cái để nó cache sẵn trên browser.

Connection view

WPT_21

Nhận diện “tốt” và “xấu”

Thường thì mình dùng connection view để xác định liệu server cũng như web của mình có thực hiện tốt việc re-use connection không, hay mỗi lần request lại phải khởi tạo lại 1 connection. Dưới đây là vài mẫu cho việc nhìn hình mà ta biết có issue =))

WPT_22

Tổng Kết

Thiệt ra là còn nhiều lắm mà mình lười viết nữa quá, nhiêu đây chắc cũng đủ để mọi người có cái nhìn tổng quát làm sao để sử dụng WPT cũng như cách phát hiện những vấn đề mà Web Application của mình đang có trên FE.

Nguồn Tham Khảo

Note: Thank cu Lộc Mai support trong việc thực hiện bài viết này =))

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s