AVADA · TS ELITE

Training nội bộ · CS & TS

Site Speed & Performance:
app Shopify ảnh hưởng thế nào?

Một trang Shopify được dựng ra sao — theme, app Avada, và app bên thứ ba được nạp thế nào. Từ đó biết cách check bằng số và trả lời đúng khi khách phàn nàn "app làm chậm site".

Cách trang load Core Web Vitals PageSpeed · DevTools Ai là thủ phạm thật

Vì sao buổi này quan trọng

Đừng "nhận sai tội" cho app Avada

Khách complain "app làm chậm store" là những case rất dễ bị đổ lỗi nhầm — mặc định nghĩ app Avada là thủ phạm.

Thực tế thủ phạm thường là theme hoặc app bên thứ ba, không phải Avada.
Sau buổi này, mỗi người có khả năng chứng minh được bằng số app có phải nguyên nhân không — thay vì cãi theo cảm tính.

Hiểu trang load ra sao

Theme, app, third-party — ai nạp cái gì, khi nào.

Đọc được Core Web Vitals

LCP / INP / CLS nghĩa là gì, ngưỡng nào là kém.

Check đúng tool, đúng thứ tự

PageSpeed → DevTools → Playwright. Ra verdict rõ ràng.

01

Phần 1

Một trang Shopify
load ra sao

Trước khi nói app có làm chậm không, phải hiểu trang được dựng thế nào — ai sở hữu cái gì, và code được nạp vào trang bằng đường nào.

Ai sở hữu cái gì

4 lớp cùng dựng nên 1 trang

Nền tảng

Shopify

Hosting, CDN, checkout
Phần này rất khó là nguyên nhân chậm

Chiếm 60–80%

Theme

Dựng phần lớn HTML/CSS/JS của trang
Ảnh hưởng performance lớn nhất
Ảnh, slider, font nặng đều nằm đây

Chiếm ~20%

Apps (gồm Avada)

Nạp thêm JS + CSS cho widget
Phần lớn app Avada load deferred
Impact thường nhỏ

Hay bị bỏ sót

Third-party

Analytics, chat, upsell, tracking…
Thường là thủ phạm thật
Nằm ngoài scope hỗ trợ của mình

Con số tham chiếu: theme chiếm 60–80% performance, apps chỉ ~20% phần còn lại. Nên khi khách nói "cài app Avada là chậm", việc đầu tiên là đo, không phải nhận lỗi.

Dòng thời gian trình duyệt

Từ lúc bấm link đến khi trang hiện

1

Tải HTML

Shopify trả HTML do theme dựng.

2

Đọc HTML

Trình duyệt parse từ trên xuống, gặp CSS/JS thì xử lý.

3

Nạp script

Theme + app + third-party. Script chặn (blocking) làm dừng cả trang.

4

Render

Vẽ nội dung chính (LCP), widget xuất hiện.

Mấu chốt: một syntax error trong theme, hoặc một script chặn ở bước 3, sẽ dừng mọi thứ phía dưới nó — kể cả code chả liên quan đến app Avada.

App được nhét vào trang bằng đường nào

Các "cửa" delivery của app

App Embed — sitewide

Bật trong Theme Editor, chạy trên mọi trang. Chưa bật = widget mất (lỗi phổ biến nhất).

App Block — theo section

Chèn vào 1 vị trí cụ thể (vd widget review ở trang product).

Scripttag — legacy

Tự inject, không cần theme. Deprecated Feb 2025, chỉ còn theme vintage.

i OS 2.0 (sections + JSON template) dùng App Embed / App Block. Vintage cũ chỉ có scripttag.
! Theme code edit = sửa thẳng theme, rủi ro cao — gỡ app xong code orphan ở lại.
Widget mất ≠ app chậm. Đa số là App Embed chưa bật hoặc sai theme (đang sửa theme chưa publish).

Script chạy kiểu gì quyết định impact

Parser-blocking → async → defer

Parser-blocking

Trình duyệt dừng dựng trang để tải + chạy script. Tệ nhất cho LCP.

async

Tải song song, chạy ngay khi xong — có thể chen ngang lúc dựng trang.

defer

Tải song song, chạy sau khi dựng xong trang. Tốt nhất cho phần lớn app.

dynamic import

Chỉ nạp khi cần (vd user bấm mở widget). Nhẹ nhất.

Vì sao mình tự tin nói "app Avada impact nhỏ": phần lớn widget load deferred và chỉ active khi user tương tác — không chặn phần render chính của trang.

02

Phần 2

Core Web Vitals
đọc con số cho đúng

3 chỉ số Google dùng để chấm trải nghiệm tốc độ. Hiểu chúng thì mới "dịch" được kết quả cho khách.

3 chỉ số Core Web Vitals

LCP · INP · CLS

LCP

Largest Contentful Paint

Tốt ≤ 2.5s

Bao lâu để phần nội dung lớn nhất (ảnh/heading) hiện ra. Script chặn làm chậm LCP.

Giống như đợi món chính được bưng ra bàn.

INP

Interaction to Next Paint

Tốt ≤ 200ms

Trang phản hồi thao tác nhanh không (đã thay FID). Event listener nặng chặn main thread (luồng xử lý chính của trình duyệt — nghẽn ở đây là trang khựng) → INP tệ.

Như bấm nút thang máy mà đèn không sáng ngay.

CLS

Cumulative Layout Shift

Tốt ≤ 0.1

Layout có bị nhảy không. Widget không chừa chỗ trước khi load → đẩy nội dung → CLS cao.

Nội dung nhảy lung tung lúc đang load, dễ bấm nhầm nút.

CWV chiếm khoảng 25–30% trọng số ranking của Google, đo ở ngưỡng 75th percentile — tức phải tốt với đa số người dùng thật, không chỉ 1 lần test.

Vì sao số hay "vênh" nhau

Lab data vs Real-user data

Lab data (Lighthouse)

Chạy 1 lần trên máy test

Điều kiện giả lập cố định

Tốt để debug, tái hiện lỗi

Chạy trên máy khác nhau → số khác nhau. Đừng lấy 1 lần chạy làm chân lý.

Real-user data (Field)

Dữ liệu người dùng thật TIN HƠN

Shopify Web Performance Dashboard

PageSpeed Insights field data

Đây mới là cái khách & Google thực sự thấy. Ưu tiên khi kết luận.

Khi khách gửi 1 screenshot Lighthouse điểm thấp: đừng hoảng — hỏi thêm field data, và kiểm tra lại bằng PageSpeed để có số nhất quán.

03

Phần 3

Quy trình check
đúng tool, đúng thứ tự

Cùng một câu hỏi "app có làm chậm không", nhưng dùng sai tool sẽ ra số lệch 2–3 lần so với khách. Đây là thứ tự ưu tiên chuẩn.

Thứ tự ưu tiên tool

PageSpeed → DevTools → Playwright

1 · PageSpeed Insights API

Ưu tiên cao nhất. Chính là tool Google tính CWV thật → khớp với cái khách thấy. Trả về LCP/CLS/TBT + breakdown từng third-party script. Không cần browser, không phụ thuộc máy test.

2 · Chrome DevTools MCP

Fallback khi cần đào sâu. Khi cần đào sâu hơn PageSpeed, agent tự dùng tool này để đo chính xác hơn (network waterfall (biểu đồ thứ tự tải từng file, xem cái nào chặn cái nào), thứ tự script). Đo qua CDP (giao thức Chrome dùng để đo chính xác hơn).

3 · Playwright

Thấp nhất cho performance. Throttle kém chính xác, LCP đo qua JS dễ miss. Chỉ dùng để screenshot / thao tác, không dùng đo CWV.

Với TS Elite: gõ thẳng /perf-check + domain — agent tự chạy PageSpeed rồi ra verdict app có phải thủ phạm không.

Cách đọc kết quả

Dịch số → xếp thủ phạm → chia scope

1 Dịch số ra nghĩa thực: "LCP 4.2s = Poor (ngưỡng >4.0s) — khách thấy trang load chậm rõ trên mobile."
2 Xếp thủ phạm theo impact: "Script X chặn 800ms, script Y chặn 200ms → X là vấn đề chính."
3 Chia in-scope vs out-scope: tách rõ phần nào của Avada, phần nào của third-party.

Ví dụ verdict thật:

Ngoài scope

rebuyengine.com tạo 8.7s critical path — app third-party khác, không phải Avada.

Trong scope

Chatty đóng góp 119ms — trong scope nhưng không phải thủ phạm chính.

Chứng minh nhân-quả, không đoán

Toggle test + chạy n=3 lần

Tắt widget

Disable app / gỡ block → chạy PSI 3 lần, ghi điểm.

Bật widget

Enable lại → chạy PSI 3 lần đúng trang đó.

Lấy trung bình

So average 2 trạng thái — đó mới là impact thật của app.

Đọc delta

Delta < 5–10 điểm = nhiễu, không phải bằng chứng app chậm.

Lighthouse dao động 5–10 điểm tự nhiên giữa các lần chạy. 1 lần chạy có-app điểm thấp không chứng minh được gì — phải có delta trung bình giữa tắt và bật thì mới quy được nhân-quả.

04

Phần 4

Trả lời khách
& escalate

Có số rồi thì nói thẳng, không vòng vo. Phân biệt rõ khi nào là Avada, khi nào không — và escalate dev cần mang theo gì.

2 kịch bản trả lời

Khi KHÔNG phải Avada · khi LÀ Avada

Không phải Avada

Chỉ ra script/third-party nào tạo critical path, bao nhiêu ms
Nói rõ phần đó ngoài scope hỗ trợ của mình
Khách cần tự liên hệ app đó / tối ưu theme nếu muốn cải thiện
Vẫn nêu rõ Avada đóng góp bao nhiêu % để minh bạch

Là Avada

Xác nhận phần Avada + impact thực tế (thường nhỏ, deferred)
Nếu impact đáng kể → escalate dev, không tự hứa fix
Giải thích widget load deferred / chỉ active khi tương tác
Đặt kỳ vọng đúng: cải thiện phần Avada không "cứu" cả site nếu theme nặng

Luôn nói bằng ngôn ngữ khách hiểu — dịch ms và điểm số thành trải nghiệm thật ("trang chậm rõ trên mobile"), không đọc số khô khan.

Escalate dev cần gì

Gói escalation "đủ đồ"

1

Store URL

Trang cụ thể bị chậm (product / collection / home).

2

PSI before/after

Điểm PageSpeed trước & sau khi cài/bật app.

3

Lighthouse diagnostics

Breakdown script nào chặn bao nhiêu ms.

Escalate có đủ 3 thứ này thì dev xử lý được ngay. Thiếu số → dev hỏi lại → mất thêm 1 vòng, khách chờ lâu hơn.

05

Phần 5

Case thật
từ ticket & báo dev

3 ca thật của Air Reviews & Joy — cùng cách khách complain, và cách mình dùng số để tìm đúng thủ phạm. Không lý thuyết.

Case thật · Air Reviews

Khách gửi kết quả PSI — đổ cho app

Khách gửi số đo

TL;DR: Air Reviews chỉ 82ms, không block main thread — không phải thủ phạm LCP 15.4s.

Screenshot PSI: Performance 52 · LCP 15.4s · FCP 6.3s · TBT ~750ms. Chỉ vào AR load 19 file script (194 KiB, 82ms) từ cdn-air-reviews và đổ cho app làm chậm.

TS soi lại waterfall

Thủ phạm LCP thật: uploadly-cdn.com (825ms) + Facebook Pixel, cộng ảnh sản phẩm theme set 3840px trên mobile. AR không block main thread — 82ms là không đáng kể.

Bài học: số to ≠ app mình

Khách thấy điểm 52 rồi chỉ tay vào app đầu tiên nhìn thấy. Mình đọc waterfall → thủ phạm là third-party (uploadly, FB Pixel) + ảnh theme, không phải AR (82ms). Không có số này thì rất dễ nhận oan.

Store 7tee00-q4 · Slack thread

Case thật · Joy Loyalty

Khách gửi hẳn file Lighthouse — audit nhầm version

Khách gửi

TL;DR: File Lighthouse khách gửi đo bản v3 cũ (219KB) — store thật đang chạy v4 nhẹ hơn nhiều, không phải Joy làm chậm.

Upload thẳng vào Crisp avada-lighthouse-report.json + Google Drive (report.html + trace). Chỉ ra Joy gọi Google Fonts (Instrument Serif) render-blocking + avada-joy bundle nạp tuần tự, đổ cho Joy làm chậm LCP mobile.

TS + dev soi trace

Trace cho thấy script widget v3 (219KB) — nhưng store thật đang chạy v4 (~40KB). Số trong file khách gửi là version cũ, không phản ánh live. Font là chủ ý (tránh FOUT FAB label).

Bài học: đọc file nhưng verify live

Khách gửi cả file .json + trace vẫn có thể sai — vì đo trên version/cache cũ. Luôn đối chiếu với store live.

Fix: font Joy → "Inherit from theme" → hết gọi Google Fonts riêng
Xác nhận version thật (v4 ~200KB, CTO: "siêu nhẹ")

disc-golf-deals-usa · JOY-260624

Case thật · Air Reviews

"Chỉ load JS ở product page" — app đã tự làm

Khách yêu cầu

TL;DR: App đã tự động không load JS ở trang không có block — chỉ cần gỡ block, không cần sửa code.

Air Reviews chỉ nên load JS trên product page, không load toàn site, để các trang khác nhẹ hơn.

Dev phản hồi

App đã có sẵn logic không load JS nếu trang không có block AR nào (review sidebar, popup…). Chỉ cần add block ở product page thì JS chỉ load ở đó. Không đổi code.

Bài học: delivery surface

Nối thẳng slide "các cửa delivery": App Block ở đâu → script load ở đó. Gỡ block ở trang không cần là widget + JS tự biến mất khỏi trang đó.

Store ai1j9h-22 · Slack thread

Case thật · Air Reviews · ticket-only

Khách gửi link PSI + đòi lazy-load — cách trả lời

Khách gửi & đòi

TL;DR: AR có đóng góp nhưng không phải thủ phạm chính — cần đưa test delta cụ thể, không chỉ nói "không phải app".

Link PSI product page, mobile 57 điểm. Chỉ vào utilities-FullScreen…js (~340KB) do air-reviews-main nạp. 3 yêu cầu: lazy-load script đó, thêm toggle tắt, giảm JS payload.

Ryan soi PSI

AR có đóng góp nhưng không phải thủ phạm chính — LCP/TBT chủ yếu từ theme + third-party. Chạy lại PSI điểm nhảy lên 67 (số dao động). AR bundle chung, không tách lazy-load được. Ticket-only, không báo dev.

Bài học: đừng chỉ "đá sang chỗ khác"

Trả lời kiểu "không phải lỗi app, dùng app SEO đi" → khách nổi cáu ("poorest response ever"). CSL coach lại:

Chạy test có-app vs không-app, đưa delta cụ thể
Số dao động → chạy nhiều lần, dùng field data
Thừa nhận phần AR đóng góp, đừng phủ nhận sạch

guiltandclass.com · AIR-260415

Case thật · Accessibility · in-scope

Khi thủ phạm ĐÚNG là app — và mình fix được

Triệu chứng

Merchant báo LCP kém đi sau khi bật widget accessibility. Lần này số đo trỏ đúng vào app: preloader + logo của widget là phần tử LCP nhưng không được preload (preload = báo trình duyệt tải sớm tài nguyên quan trọng) → hiện muộn.

Dev fix thật

TL;DR: Lần này đúng là app gây LCP kém — dev fix bằng preload logo, đã cải thiện.
Preload preloader logo + preload logo → phần tử LCP tải sớm → LCP cải thiện. Verify bằng PSI before/after đúng khung toggle test.

Bài học: không phải lúc nào cũng "không phải mình"

Các case trên đa số là đổ oan cho app — nhưng có ca app đúng là nguyên nhân. Cùng một quy trình đo bằng số: nếu delta chỉ vào Avada thì thừa nhận, escalate dev, và fix — chứ không phủ nhận sạch.

Đo bằng số → khớp thủ phạm là app → escalate, không chối
Fix = preload asset LCP, không phải viết lại widget

SB-13868 · commit c78c8adf / b5e693e8 · 2026-07

Thực hành

Practice — ai là thủ phạm?

Case 1

Khách: "Cài Air Reviews xong LCP lên 7s." → Chạy PSI, tách script Avada vs theme vs third-party. Verdict?

Case 2

Khách gửi Lighthouse 32 điểm mobile. → Field data nói gì? Thủ phạm top-3 là ai, có Avada không?

Case 3

Khách: "Widget nhảy layout." → CLS hay do widget không chừa chỗ? In-scope fix được không?

Mỗi nhóm chạy PageSpeed thật cho 1 case, trình bày verdict theo đúng khung: dịch số → xếp thủ phạm → chia scope → câu trả lời khách.