Một trưởng phòng thu mua có thể vào website nhà máy chỉ để làm ba việc: kiểm tra năng lực, mở bảng thông số kỹ thuật và tải catalog về chuyển cho bộ phận kỹ thuật. Nếu trang sản phẩm tải chậm, nút “Tải catalog” phản hồi trễ hoặc file PDF nặng đến mức mở mãi chưa xong, trải nghiệm bị đứt ngay trước thời điểm họ có thể gửi RFQ.
Với EnterDizi, tối ưu Core Web Vitals website nhà máy không dừng ở việc đẩy điểm PageSpeed lên màu xanh. Cần nhìn toàn bộ hành trình từ lúc đối tác mở trang, đọc thông số, bấm tải tài liệu cho tới khi PDF có thể xem hoặc lưu ổn định trên thiết bị và mạng thực tế.
Core Web Vitals không đo trực tiếp tốc độ tải file PDF
Đây là điểm cần làm rõ trước khi tối ưu. Core Web Vitals đo trải nghiệm của trang web thông qua ba nhóm chính: tốc độ hiển thị nội dung lớn nhất, khả năng phản hồi khi người dùng tương tác và mức ổn định của bố cục.
Để một trang được xem là có trải nghiệm tốt, ba ngưỡng hiện tại là LCP không quá 2,5 giây, INP không quá 200 mili giây và CLS không quá 0,1 tại phân vị thứ 75 của lượt truy cập.
Đây là các ngưỡng được Google công bố trong tài liệu Core Web Vitals; chúng dùng để đánh giá trang tải và phản hồi ra sao, chứ không phải số giây cần để tải xong một catalog PDF 20 MB.
Vì vậy, một website có thể đạt Core Web Vitals tốt nhưng file catalog vẫn tải chậm nếu file quá nặng, máy chủ phục vụ tệp kém hoặc đường truyền của người dùng yếu. Ngược lại, một file PDF nhẹ vẫn không cứu được trải nghiệm nếu trang sản phẩm bị chặn bởi JavaScript nặng, ảnh hero quá lớn hoặc nút tải dịch chuyển khi người dùng sắp bấm.
Muốn tối ưu đúng, cần tách hai lớp: hiệu suất của trang chứa nút tải và hiệu suất phân phối chính file PDF.
Ba chỉ số Core Web Vitals cần nhìn theo hành trình procurement
LCP: đối tác phải thấy nhanh thứ họ cần trước khi nghĩ tới tải catalog
Với website nhà máy B2B, phần tử LCP thường có thể là ảnh hero, ảnh sản phẩm lớn, banner năng lực hoặc một khối nội dung chính ở đầu trang. Nếu phần này tải chậm, người mua chưa kịp đánh giá nhà máy đã phải chờ.
Muốn LCP tốt, tài nguyên chính cần được trình duyệt phát hiện sớm, ưu tiên đúng và không bị kéo chậm bởi phản hồi máy chủ. Đây cũng là trọng tâm trong hướng dẫn tối ưu LCP của web.dev; với trang sản phẩm hoặc trang năng lực nhà máy, điều đó thường dẫn tới ba việc thực tế.
Thứ nhất, không dùng ảnh hero nặng hơn mức cần thiết. Ảnh nên được nén, dùng kích thước phù hợp với viewport và tránh tải một file ảnh desktop rất lớn cho màn hình mobile.
Thứ hai, nội dung quan trọng không nên bị giữ lại chỉ vì một slider, animation hoặc đoạn script chưa chạy xong. Người mua cần nhìn thấy tên sản phẩm, nhóm vật liệu, năng lực chính và đường dẫn tới tài liệu kỹ thuật càng sớm càng tốt.
Thứ ba, đừng đặt một trình xem PDF nặng ngay trên vùng đầu trang. Việc nhúng PDF bằng iframe hoặc viewer nhiều script có thể khiến trang phải xử lý thêm tài nguyên trước khi người dùng thật sự cần mở catalog.
INP: nút tải tài liệu phải phản hồi ngay khi procurement bấm
INP đo mức độ phản hồi của trang đối với thao tác như click, tap hoặc bàn phím. Với website nhà máy, đây là chỉ số rất gần với trải nghiệm của các nút “Tải catalog”, “Xem datasheet”, tab thông số, bộ lọc model và form RFQ.
Nếu người dùng bấm nút tải nhưng trang đứng một nhịp dài vì main thread đang xử lý script, họ có thể bấm thêm lần nữa hoặc nghĩ nút bị lỗi. Cảm giác “website bị nghẽn” đôi khi đến từ phản hồi tương tác chậm chứ không phải từ băng thông tải PDF.
Cách xử lý nên bắt đầu bằng việc giảm JavaScript không cần thiết trên trang sản phẩm. Widget chat, animation, tracking cũ, popup, carousel và các plugin marketing đều có thể cạnh tranh tài nguyên với thao tác chính của người dùng.
Nút tải catalog cũng nên là một liên kết thật tới tài nguyên PDF, không phụ thuộc hoàn toàn vào một chuỗi JavaScript phức tạp mới tạo URL sau khi click. Nếu cần đo sự kiện analytics, việc đo lường không nên làm chậm hành động tải xuống.
CLS: đừng để nút “Tải catalog” chạy khỏi vị trí khi trang đang tải
CLS phản ánh mức dịch chuyển bố cục ngoài dự kiến. Trên một trang sản phẩm B2B, vấn đề này thường xuất hiện khi ảnh chưa có kích thước cố định, font tải muộn, banner chen vào đầu trang hoặc khối thông tin kỹ thuật mở rộng sau khi render.
Nếu nút tải datasheet nằm ngay dưới ảnh sản phẩm, một ảnh chưa khai báo width và height có thể đẩy nút xuống đúng lúc người dùng chuẩn bị bấm. Trên mobile, điều này vừa khó chịu vừa làm tăng nguy cơ thao tác nhầm.
Nên dành sẵn kích thước cho ảnh, video, bảng thông số và các block tải động. Các banner cookie hoặc khuyến mãi cũng không nên chèn thêm không gian phía trên nội dung sau khi trang đã hiển thị.
Với phần tài liệu kỹ thuật, nếu cần hiển thị tên file, dung lượng và phiên bản sau khi gọi API, hãy giữ sẵn một vùng có kích thước ổn định. Đừng để toàn bộ cụm CTA nhảy xuống khi dữ liệu vừa trả về.
Đừng dùng PDF để thay thế toàn bộ thông tin quan trọng trên trang sản phẩm
Một lỗi phổ biến ở website nhà máy là trang sản phẩm rất ngắn, còn gần như mọi thông tin về vật liệu, kích thước, dung sai, chứng chỉ, MOQ và năng lực lại nằm trong một file PDF.
Cách này làm người mua phải tải tài liệu chỉ để trả lời những câu hỏi cơ bản. Nó cũng khiến phần HTML trên website nghèo thông tin và khó tạo một hành trình rõ từ tìm kiếm đến RFQ.
Thông tin cốt lõi nên xuất hiện trực tiếp trên trang: sản phẩm là gì, dùng cho ngành nào, vật liệu nào, dải kích thước hoặc thông số chính, tiêu chuẩn nào có thể đáp ứng và nhà máy nhận yêu cầu theo model hay theo bản vẽ.
PDF nên là lớp tài liệu sâu hơn để procurement hoặc kỹ sư tải về: bản catalog đầy đủ, datasheet, drawing, certificate, bảng dung sai, hướng dẫn đóng gói hoặc tài liệu phục vụ phê duyệt nhà cung cấp.
Khi HTML và PDF chia vai trò đúng, người mua có thể đánh giá nhanh trên web rồi tải tài liệu khi thật sự cần. Đây cũng là cách giảm tình trạng mọi lượt truy cập đều phải tải một file lớn ngay từ đầu.
Tối ưu PDF và hạ tầng phân phối phải đi cùng nhau
Tối ưu file PDF trước khi đổ lỗi cho hosting
Một catalog 80 trang chứa ảnh độ phân giải cao, font nhúng dư thừa và nhiều lớp thiết kế có thể nặng hơn rất nhiều so với nhu cầu đọc trên web. Nếu file nguồn đã quá lớn, chuyển sang CDN chỉ giải quyết một phần.
Với catalog dài, nên giảm kích thước PDF và bật Fast Web View để nội dung có thể bắt đầu hiển thị trước khi toàn bộ tệp được tải xong. Đây cũng là cách Adobe hướng dẫn khi chuẩn bị PDF cho web, đặc biệt hữu ích khi đối tác mở tài liệu trên kết nối chậm.
Ảnh trong PDF nên được nén theo nhu cầu xem, không giữ nguyên file ảnh dùng cho in ấn nếu bản web không cần độ phân giải đó. Font cũng nên được subset khi phù hợp, đồng thời loại bỏ metadata, object hoặc dữ liệu nhúng không cần thiết.
Một nhà máy có thể duy trì hai phiên bản: bản in chất lượng cao dành cho sales gửi khi cần và bản web tối ưu để tải nhanh. Không nên bắt mọi khách truy cập phải tải bản in nặng chỉ vì đội thiết kế xuất một file duy nhất.
Fast Web View giúp PDF mở sớm hơn, nhưng không thay thế việc giảm dung lượng
Fast Web View, hay linearization, sắp xếp PDF để trình đọc có thể bắt đầu hiển thị các phần đầu của tài liệu trước khi toàn bộ file được truyền xong. Adobe mô tả đây là cách hỗ trợ xem tài liệu lớn dần theo quá trình tải, đặc biệt hữu ích trên kết nối băng thông thấp.
Tuy nhiên, linearization không biến một file 100 MB thành file nhẹ. Nếu catalog chứa quá nhiều ảnh, đồ họa hoặc trang không cần thiết, tổng lượng dữ liệu vẫn phải được truyền khi người dùng xem hết hoặc tải toàn bộ.
Vì vậy, thứ tự hợp lý là giảm dung lượng trước, sau đó mới kiểm tra Fast Web View. Đây là cách tránh cảm giác “đã bật tối ưu web nhưng file vẫn chậm”.
Máy chủ phải hỗ trợ tải từng phần nếu muốn tài liệu lớn hoạt động ổn định hơn
Với file lớn, khả năng phục vụ từng phần của tài nguyên giúp trình duyệt hoặc trình đọc lấy phần cần thiết thay vì luôn yêu cầu lại toàn bộ file. Cơ chế này dùng header Range và phản hồi 206 Partial Content; tài liệu HTTP Range Requests của MDN mô tả cách client yêu cầu đúng phần dữ liệu cần lấy.
Doanh nghiệp không cần tự viết chức năng tải từng byte. Điều cần kiểm tra là web server, CDN hoặc object storage có hỗ trợ Range Requests cho PDF và có trả đúng header khi client yêu cầu hay không.
Điểm này đặc biệt hữu ích khi người dùng mở tài liệu dài, tua tới trang khác hoặc cần tiếp tục một lượt tải bị gián đoạn. Nhưng nó chỉ phát huy tác dụng khi file được phục vụ trực tiếp và hạ tầng không chặn cơ chế partial content.
Đội kỹ thuật có thể kiểm tra nhanh trong DevTools Network hoặc bằng request có Range header. Nếu server luôn trả toàn bộ file với 200 OK dù client yêu cầu một range cụ thể, cấu hình phân phối tệp cần được xem lại.
CDN nên phục vụ tài liệu gần người mua hơn, nhưng đừng tạo thêm chuỗi redirect
Nếu khách hàng mục tiêu nằm ở Mỹ, EU, Nhật Bản hoặc nhiều thị trường, catalog không nên chỉ được phục vụ từ một máy chủ có vị trí xa tất cả người dùng. CDN hoặc object storage có mạng phân phối toàn cầu có thể giảm độ trễ và tránh dồn toàn bộ tải file về web server chính.
Tuy nhiên, đường tải tài liệu càng nhiều lớp redirect thì trải nghiệm càng dễ chậm. Một click đi từ trang sản phẩm sang URL tracking, rồi sang storage trung gian, rồi mới tới file thật sẽ tạo thêm request và thêm điểm có thể lỗi.
Nên ưu tiên URL ổn định, HTTPS, ít redirect và có cache phù hợp. Khi cập nhật catalog, dùng version hoặc tên file rõ ràng thay vì thay file âm thầm mà vẫn giữ dữ liệu cache cũ trong thời gian dài.
Nếu dùng signed URL vì lý do quyền truy cập, thời gian hết hạn phải đủ cho hành trình thực tế. Một link hết hạn quá nhanh có thể khiến procurement chuyển tiếp email nội bộ rồi đồng nghiệp mở lại thì gặp lỗi.
Không preload catalog PDF chỉ vì muốn “nhanh”
Preload là kỹ thuật mạnh khi dùng đúng tài nguyên. Nhưng preload một file catalog lớn ngay từ lúc trang mở có thể làm điều ngược lại: tranh băng thông với ảnh LCP, CSS, font và các tài nguyên cần thiết để render trang.
Nếu phần lớn khách chỉ xem thông số mà không tải catalog, việc tự động tải trước hàng chục MB là lãng phí. Trên mobile hoặc mạng doanh nghiệp hạn chế băng thông, nó còn có thể kéo chậm chính trang sản phẩm.
Tài liệu PDF nên được tải khi người dùng thể hiện ý định rõ, chẳng hạn click “Xem catalog” hoặc “Tải datasheet”. Nếu muốn làm preview, hãy tải preview nhẹ hoặc thumbnail trước, không nhúng nguyên tài liệu nặng vào mọi lượt truy cập.
Thiết kế trải nghiệm tải tài liệu theo cách procurement thực sự sử dụng
Tách “Xem online” và “Tải xuống” để người mua chủ động
Procurement có hai hành vi khác nhau. Có người chỉ muốn kiểm tra nhanh một bảng thông số; người khác cần tải file để gửi nội bộ, lưu hồ sơ hoặc đính kèm vào quy trình phê duyệt nhà cung cấp.
Website nên tách hai hành động nếu tài liệu lớn: “Xem catalog” mở bản web/preview tối ưu, còn “Tải PDF” tải file đầy đủ. Cách này giúp người dùng biết điều gì sẽ xảy ra trước khi bấm.
Ngay cạnh nút nên hiển thị tên tài liệu, ngôn ngữ, phiên bản, ngày cập nhật và dung lượng file. Một dòng “Catalog CNC Machining 2026 — EN — PDF 4.8 MB” hữu ích hơn nút “Download” không có ngữ cảnh.
Nếu có nhiều thị trường, nên cho người dùng chọn đúng ngôn ngữ và phiên bản sản phẩm. Đừng để họ tải ba file chỉ để tìm xem đâu là catalog tiếng Anh mới nhất.
Đừng làm một “download center” khiến procurement phải tìm lại từ đầu
Một lỗi khác là trang sản phẩm có nút “Tài liệu” nhưng link đưa người dùng tới thư viện chung chứa hàng trăm file. Khi đó doanh nghiệp đã giảm tải kỹ thuật cho trang sản phẩm nhưng lại tăng tải nhận thức cho người mua.
Tài liệu liên quan nên xuất hiện ngay tại trang sản phẩm, trang ngành hàng hoặc trang năng lực tương ứng. Download center chỉ nên là lớp tra cứu bổ sung cho người dùng đã biết mã tài liệu hoặc model.
Nếu catalog áp dụng cho nhiều sản phẩm, có thể gắn cùng một file ở nhiều trang nhưng quản lý nguồn file tập trung. Điều này giúp cập nhật một phiên bản mới mà không phải thay link thủ công ở hàng chục URL.
Cấu trúc file cũng cần tính tới SEO và vận hành
Tên file kiểu final-final-2026-new-v7.pdf vừa khó quản lý vừa thiếu ngữ cảnh. Nên dùng cấu trúc có thể đọc được, chẳng hạn cnc-machining-catalog-2026-en.pdf hoặc injection-molding-technical-datasheet-model-x.pdf.
Nếu cập nhật thường xuyên, cần quy ước version. Procurement có thể đã tải bản cũ về máy, nên tài liệu mới cần thể hiện ngày hoặc mã phiên bản ngay trong PDF chứ không chỉ ở URL.
Tài liệu cũng nên có text có thể chọn và tìm kiếm thay vì toàn bộ là ảnh scan. Điều này giúp người mua tìm nhanh model, vật liệu hoặc tiêu chuẩn trong file, đồng thời hỗ trợ khả năng truy cập tốt hơn.
Nếu PDF chứa thông tin mật, đừng đưa nó lên public web chỉ vì muốn thuận tiện tải. Tài liệu cần NDA hoặc phân quyền nên đi qua luồng xác thực riêng, tách khỏi catalog công khai.
Đo đúng để biết điểm nghẽn nằm ở trang hay ở PDF
Đo riêng trang web và file PDF để biết nghẽn nằm ở đâu
Nếu chỉ nhìn điểm PageSpeed rồi kết luận “catalog tải chậm vì Core Web Vitals”, đội kỹ thuật rất dễ tối ưu sai chỗ. Việc tối ưu Core Web Vitals website nhà máy cần được đo tách khỏi hiệu suất phân phối chính file PDF.
Trang web nên được đo bằng dữ liệu thực địa khi có đủ traffic, kết hợp PageSpeed Insights, Chrome UX Report hoặc dữ liệu RUM. Core Web Vitals cần được đọc ở phân vị thứ 75, không chỉ một lần chạy Lighthouse trong điều kiện mô phỏng.
File PDF nên được kiểm tra như một tài nguyên mạng: kích thước file, thời gian phản hồi đầu tiên, tốc độ truyền, cache, redirect, content type, Range Requests và hành vi khi mở trên mobile.
Một bài test thực tế có thể dùng ba bối cảnh: mạng văn phòng ổn định, 4G mobile và kết nối quốc tế từ thị trường mục tiêu. Nếu PDF chỉ chậm ở thị trường xa, bài toán có thể nằm ở phân phối CDN; nếu chậm ở mọi nơi, file hoặc origin server cần được tối ưu trước.
Đừng dùng một con số “tải dưới X giây” làm KPI cứng cho mọi catalog
Thời gian tải phụ thuộc vào dung lượng file, vị trí người dùng, mạng, thiết bị, cache và cách họ mở tài liệu. Vì vậy, đặt mục tiêu “mọi PDF phải tải dưới 1,5 giây” nghe đẹp nhưng rất khó bảo đảm trong thực tế.
KPI nên tách theo yếu tố kiểm soát được: dung lượng tối đa theo loại tài liệu, tỷ lệ hit CDN, thời gian phản hồi server, số redirect, hỗ trợ Range Requests và tỷ lệ lỗi tải file.
Với Core Web Vitals, giữ mục tiêu theo ngưỡng chính thức của Google. Với PDF, doanh nghiệp nên định nghĩa chuẩn vận hành riêng dựa trên thị trường, kích thước tài liệu và hạ tầng thực tế.
Một trang catalog tốt phải dẫn được người mua sang bước RFQ mà không ép họ
Tốc độ chỉ có giá trị kinh doanh khi nó giúp người mua hoàn thành một tác vụ. Sau khi xem datasheet, họ có thể cần hỏi MOQ, lead time, vật liệu thay thế, năng lực xuất khẩu hoặc khả năng sản xuất theo bản vẽ.
Một cấu trúc SEO website nhà máy B2B tốt nên để những bước đó nối tiếp tự nhiên. Ngay dưới tài liệu có thể đặt CTA “Gửi bản vẽ để nhận đánh giá khả năng gia công” hoặc “Yêu cầu bảng thông số/quotation theo model”, tùy mục tiêu của trang.
Không nên bật popup RFQ ngay khi người dùng vừa bấm tải PDF. Họ có thể chỉ đang thu thập tài liệu cho vòng shortlist; ép form quá sớm dễ làm gián đoạn hành trình mà website vừa tối ưu.
Khi người mua đã xem thông số, tải catalog và đọc được năng lực chính, CTA lúc đó mới có đủ ngữ cảnh để trở thành bước tiếp theo thay vì quảng cáo chen ngang.
Quy trình 9 bước tối ưu trang sản phẩm có catalog và datasheet
Bước 1: Xác định tài liệu nào thật sự cần tải
Không phải thông tin nào cũng cần một PDF. Thông số cơ bản nên có trên HTML; catalog, datasheet chi tiết, drawing và chứng chỉ mới cần file tải riêng.
Bước 2: Đo Core Web Vitals của trang trước khi sửa PDF
Kiểm tra LCP, INP và CLS để biết trang sản phẩm có đang chậm từ chính giao diện hay không. Nếu LCP kém vì ảnh hero, giảm PDF sẽ không giải quyết được điểm nghẽn đầu tiên.
Bước 3: Kiểm tra kích thước và cấu trúc PDF
Xem dung lượng, số trang, ảnh có bị quá lớn không, font có nhúng dư không và tài liệu có chứa object không cần thiết hay không. Với catalog dùng trên web, nên có chuẩn dung lượng riêng thay vì lấy file in ấn làm mặc định.
Bước 4: Bật Fast Web View khi phù hợp
Sau khi giảm dung lượng, kiểm tra file đã được linearize để có thể bắt đầu hiển thị sớm hơn khi mở qua web. Không coi đây là thay thế cho compression.
Bước 5: Kiểm tra cách server phục vụ PDF
Xác nhận Content-Type đúng, URL ổn định, HTTPS, ít redirect và hỗ trợ Range Requests khi cần. Nếu file đi qua CDN, kiểm tra cache và hành vi 206 Partial Content.
Bước 6: Không nhúng viewer nặng ngay từ lần tải đầu
Nếu người mua chưa bấm xem catalog, trang không nên tải cả viewer và PDF. Preview nên được kích hoạt theo nhu cầu.
Bước 7: Gắn metadata người mua cần thấy
Hiển thị tên tài liệu, ngôn ngữ, version, ngày cập nhật và dung lượng. Đối tác biết trước mình sắp tải gì và có đang dùng bản mới nhất hay không.
Bước 8: Đo lại trên mobile và từ thị trường mục tiêu
Đừng chỉ test bằng máy dev trong văn phòng. Dùng thiết bị mobile và ít nhất một vị trí gần thị trường xuất khẩu chính nếu có thể.
Bước 9: Kiểm tra hành trình sau khi tải
Xem người dùng có tìm được CTA RFQ, contact kỹ thuật hoặc trang năng lực liên quan hay không. Mục tiêu không phải chỉ để download thành công mà là giúp procurement tiến thêm một bước trong quyết định nhà cung cấp.
Những điểm nhà máy thường làm sai khi tối ưu Core Web Vitals và tài liệu PDF
Core Web Vitals tốt có đồng nghĩa catalog sẽ tải nhanh không?
Không. Core Web Vitals đánh giá trải nghiệm của trang web, còn tốc độ tải PDF chịu ảnh hưởng thêm bởi dung lượng file, máy chủ, CDN, cache và mạng của người dùng. Hai lớp liên quan nhưng không phải cùng một chỉ số.
Có nên nhúng toàn bộ catalog vào trang sản phẩm bằng iframe?
Chỉ khi có lý do rõ và đã kiểm tra tác động. Với file lớn, nhúng ngay từ đầu có thể làm trang nặng hơn và tải tài nguyên mà nhiều người không dùng. Preview theo yêu cầu thường dễ kiểm soát hơn.
Có nên nén PDF càng nhỏ càng tốt?
Không nên đánh đổi khả năng đọc thông số kỹ thuật. Mục tiêu là giảm dữ liệu dư thừa trong khi chữ, bản vẽ, bảng và ảnh sản phẩm vẫn đủ rõ để procurement và kỹ sư sử dụng.
Có cần CDN nếu khách hàng chủ yếu ở nước ngoài?
Không phải website nào cũng bắt buộc dùng CDN, nhưng doanh nghiệp có người mua ở nhiều khu vực nên đo độ trễ thực tế. Nếu file lớn chậm rõ ở thị trường xa origin, CDN là một phương án đáng kiểm tra.
Có nên đổi URL catalog mỗi lần cập nhật?
Nếu cần kiểm soát version và cache, URL có version rõ ràng thường dễ quản lý hơn. Tuy nhiên, các trang sản phẩm phải luôn trỏ tới bản hiện hành và tránh tạo hàng loạt link cũ không còn sử dụng.
Có nên yêu cầu email trước khi cho tải mọi datasheet?
Không nên mặc định. Một số tài liệu kỹ thuật cơ bản là thứ procurement cần để shortlist nhà cung cấp. Nếu tất cả đều bị khóa sau form, trải nghiệm có thể bị ngắt quá sớm; chỉ nên gated khi tài liệu thật sự có giá trị hoặc yêu cầu kiểm soát truy cập.
Core Web Vitals với website nhà máy nên được hiểu như một phần của trải nghiệm mua hàng B2B, không phải bảng điểm kỹ thuật đứng riêng. Trang phải hiển thị nhanh, phản hồi ngay, không nhảy bố cục; còn catalog và datasheet phải nhẹ, dễ mở, được phân phối ổn định và có phiên bản rõ ràng.
Khi hai lớp này được tối ưu cùng nhau, procurement không phải chờ trang, đoán nút, tải lại file hay hỏi sales đâu là bản catalog mới nhất. Website lúc đó làm đúng vai trò của một điểm chạm kỹ thuật trước RFQ: giúp người mua kiểm tra năng lực nhanh, lấy đúng tài liệu và chuyển sang bước trao đổi thương mại khi đã đủ thông tin.