Điểm:0

Làm cách nào để tối ưu hóa việc phân phối javascript trên wordpress/apache/AWS?

lá cờ cv

Tôi đang gặp khó khăn trong việc tối ưu hóa tốc độ trang web. Tôi có một trang web đang nhận được điểm kém từ tất cả các điểm đáng ngờ thông thường (cụ thể là Số liệu PageSpeed ​​và GT; có vẻ ổn trên các công cụ Pingdom).

Thiết lập của tôi là một máy chủ T3-Medium duy nhất chạy Apache và Wordpress, phía sau AWS ELB, với việc triển khai lên CloudFront dưới dạng CDN.

Những nỗ lực đầu tiên của tôi để cải thiện hiệu suất bao gồm

  • được nâng cấp lên Trung bình (máy chủ chạy khoảng 1/2 tá trang web, nhưng chúng rất nhỏ — lưu lượng truy cập tập thể trên tất cả chúng chỉ vài nghìn lượt truy cập mỗi ngày― tuy nhiên, phiên bản "Nhỏ" cũng vậy chậm chạp dù chỉ một lần nhấn, do hạn chế về bộ nhớ),
  • đã cài đặt plugin WP Super Cache (Tôi đã chạy phía sau CloudFront, nhưng đã cài đặt plugin để thực sự tự lưu trữ các trang)
  • Đã thêm các tiêu đề kiểm soát bộ đệm vào hành vi CloudFront
  • Đã xóa các chuỗi truy vấn khỏi khóa bộ đệm (đây không phải là trang web thương mại điện tử truyền thống và quảng cáo twitter đã thêm một chuỗi duy nhất cho mỗi người dùng, điều này về cơ bản khiến mọi lượt xem trang bị lỗi bộ đệm)

Tuy nhiên, ngay cả với điều đó, hiệu suất mặc định là không thể chấp nhận được. Thủ phạm dường như là do việc phân phối (và thực thi) javascript. Dưới đây là một số kết quả từ GT Metrics, dựa trên mức độ can thiệp thủ công mà tôi thực hiện:

            Cache-Miss Cache-Hit Cache-Miss Cache-Hit Cache-Miss Cache-Hit
            Mặc định Mặc định Búa YouTube Búa tạ Youtube Búa tạ Búa tạ
TTFB 1.100 91 75 66 75 72 | 74 74 122 74 54 75 | 76 86 104 86 63 45
FCP 2,200 1,100 4,200 494 519 383 | 1,100 2,700 1,400 710 415 622 | 1.200 1.200 1.200 388 338 256
LCP 3.300 2.000 6.300 1.900 1.700 1.800 | 1,800 3,500 2,000 2,700 881 1,600 | 1.900 2.000 2.500 684 617 490
Đang tải 4,600 3,200 7,600 2,300 3,000 2,700 | 2,900 4,900 2,700 3,100 1,500 2,500 | 2.000 2.000 2.400 766 824 489
TTI 4,700 3,300 7,600 2,500 2,900 3,200 | 3,000 8,000 2,800 3,400 1,700 3,000 | 8.000 6.800 1.200 6.700 6.700 6.400

Như bạn có thể thấy, nếu tôi không làm bất cứ điều gì (hai bảng phụ đầu tiên, "mặc định"), thì trang web sẽ mất gần 3 giây để tải với một lần truy cập bộ nhớ cache và thường ở phía bắc 4 khi bỏ lỡ bộ nhớ cache.

Đây thực sự là gốc rễ của câu hỏi. Tôi nên làm gì từ đây? Tôi sẽ mô tả những gì tôi đang làm dưới đây, nhưng tôi không tin những gì tôi sắp mô tả là thông lệ tiêu chuẩn trên Internet và rõ ràng Internet nói chung không phải chịu loại hiệu suất này .

Sử dụng búa tạ

Tôi không chắc chỉ số nào trong số đó quan trọng nhất từ ​​góc độ trải nghiệm người dùng, nhưng tôi nghi ngờ trong trường hợp của mình đó là LCP và tải (tôi có thể hình dung đối với một số trang web, đó là TTI, nhưng trong trường hợp của tôi thì không có gì phải làm trong màn hình đầu tiên, do đó, số liệu Thời gian chờ CPU đầu tiên cũ sẽ rất tuyệt, nếu Lighthouse vẫn báo cáo nó).

Những gì tôi đang làm bây giờ là những gì tôi có trong phần "Búa tạ" của bảng. Tôi đã viết một tập lệnh loại bỏ tất cả các thẻ src javascript không cần thiết và chỉ đặt chúng trở lại sau 5 giây hoặc lần tương tác đầu tiên của người dùng. Bạn có thể xem kết quả. Ngay cả khi lỗi bộ nhớ cache, trang web sẽ tải trong khoảng 2 giây và trên một lần truy cập bộ nhớ cache, tốc độ này chưa đến 1 giây (chúng ta có thể bỏ qua số TTI, vì đó là độ trễ 5 giây của tôi và không ảnh hưởng đến- lần xuất hiện hoặc tương tác).

OK, trang web đang "hoạt động", nhưng thực sự, không chỉ có vẻ như một người không cần phải làm điều này trong phần tóm tắt, mà còn có một số javascript mà tôi thực sự muốn làm việc ngay từ đầu.

Tìm hiểu sâu hơn, tất cả các vấn đề dường như là do JavaScript của bên thứ ba (nghĩa là nội dung không/không thể có trên CDN của tôi). Một số vấn đề này chỉ là nghiêm trọng và tôi có thể giải quyết nội bộ (ví dụ: tôi có thể nói với những người tiếp thị, "Chỉ sử dụng HotJar khi bạn thực sự cần, sau đó tắt nó đi — nó kéo dài thêm một giây để tải trang thời gian"). Nhưng một số trong số đó chỉ là "tiêu chuẩn Internet" â Stripe và Google analytics đều cộng thêm ~500 mili giây giữa thời gian tải và thời gian chạy.

Tôi có thể tiếp tục tinh chỉnh chiếc búa tạ của mình, như Tim đã đề xuất trong các nhận xét, nhưng điều này vẫn không ổn. Phải có điều gì đó mà tôi đang thiếu về thiết lập này và JavaScript (đặc biệt là bên thứ ba).

Tim avatar
lá cờ gp
Tim
Đọc bản cập nhật của bạn, toàn bộ điều chậm trễ 5 giây thực sự không bình thường. Bạn có thể tải xuống js được lưu trữ ở bất kỳ đâu và đặt nó trên máy chủ/CDN của bạn nếu bạn muốn. Đề nghị bạn thử ý tưởng của tôi, vì bạn chưa cung cấp cho chúng tôi đủ thông tin để thực sự giúp bạn.Nếu bạn thực sự muốn trợ giúp đăng URL.
philolegein avatar
lá cờ cv
@Tim, tôi không thể tìm thấy bài đăng mà tôi có ý tưởng ban đầu về sự chậm trễ, nhưng tôi nghĩ ý tưởng là "Đợi lâu để bắt đầu tải, nhưng hãy thực hiện sớm hơn nếu người dùng cuộn/nhấp chuột/v.v.. “. Tuy nhiên, tôi đã tiếp thu đề xuất của bạn và giảm độ trễ xuống còn 650 mili giây, dựa trên dữ liệu tôi đưa vào bản sửa đổi. Bạn có thể xem trang được đề cập tại đây: [link](https://www.chrisrichardson.info/lp/prague-b/)
Tim avatar
lá cờ gp
Tim
Lần tải đầu tiên mất vài giây đối với tôi ở New Zealand, lần tải thứ hai và sau đó rất, rất nhanh nên CDN đang hoạt động. Kiểm tra trang web nói rằng nó ổn. https://www.webpagetest.org/result/220531_BiDcPJ_7TB/ . GTMetrix tải lần đầu hơi chậm https://gtmetrix.com/reports/www.chrisrichardson.info/8JdbxgoE/ nhưng một khi nó được lưu vào bộ đệm trên nút CDN gần trang web thử nghiệm thì nó cực nhanh https://gtmetrix.com/reports/ www.chrisrichardson.info/4jXER8rm/ . Vì vậy, tôi nghĩ tải đầu tiên là vấn đề của bạn. Tôi không nghĩ rằng đây là một vấn đề cơ sở hạ tầng. Sự thay đổi có thể là do địa lý. Tôi sẽ mất hoàn toàn sự chậm trễ
Tim avatar
lá cờ gp
Tim
Tôi sẽ loại bỏ độ trễ tải JS năm giây và đảm bảo các tiêu đề bộ đệm cho tài nguyên tĩnh (js / jpg / v.v.) được đặt để CloudFront có thể lưu chúng vào bộ đệm.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.