Sepertinya Lighthouse 6 memperkenalkan beberapa metrik baru dan menghapus beberapa metrik lainnya dari v5 sehingga kemungkinan terjadi perubahan skor. Artikel ini menjelaskan apa yang telah berubah:

https://web.dev/lighthouse-whats-new-6.0/

Ada juga tautan di bagian akhir ke kalkulator skor yang sangat berguna untuk memecah skor dan memahami faktor apa yang paling berkontribusi.

https://googlechrome.github.io/lighthouse/scorecalc

Saya mendapat kesan bahwa ada lebih banyak fokus pada interaktivitas utas utama di v6 jadi jika situs Anda menyertakan bundel JS besar, itu mungkin faktor yang signifikan.

Ya @shanekenney , saya tahu, tapi tidak begitu tahu cara menguranginya selain menghapus bagian situs untuk melihat bagian mana yang memprovokasi ini

Apakah Anda juga melihat dampaknya pada gaysbyjs dan situs tema-ui? Saya ingin tahu / ingin tahu pengoptimalan apa yang mungkin mereka pikirkan di situs mereka, atau apakah mereka telah melihat beberapa penyebab tertentu

Masalah ini bagus sehingga kami dapat mendiskusikan skor wawasan Lighthouse / PageSpeed ​​secara keseluruhan dan kemungkinan regresi yang kami lihat dengan v6.

@kuworking satu hal yang perlu diperhatikan adalah bahwa lighthouse-metrics.com tampaknya menggunakan _ "Emulated Nexus 5X" _ untuk 5.6 dan _ "Emulated Moto G4" _ untuk 6.0 yang juga dapat menambahkan beberapa noise pada perbandingan.

Tolok ukur lebih dari 922 situs ini mengklaim di v5 skor Kinerja rata-rata untuk situs Gatsby adalah 75 . Saya akan mencoba melakukan tampilan cepat menggunakan solusi yang dihosting untuk mencegah jaringan lokal saya menjadi faktor variabilitas lainnya.

Saat ini (dengan Lighthouse v5.6 / PageSpeed ​​Insights)

PSI menggunakan Moto G4 dengan "Fast 3G". Sumber

Situs "bendera" tertentu yang dibuat menggunakan Gatsby tidak benar-benar berkinerja bagus di PageSpeed ​​Insights (yang saya asumsikan masih menggunakan Lighthouse v5.6 - tunduk pada variabilitas standar pada setiap proses, mungkin berjalan 3x atau 5x dan rata-rata akan membebani metrik yang lebih andal ) .

• gatsbyjs.org (Seluler 72/100, TTI 9s) Sumber
• reactjs.org (Seluler 62/100, TTI 9.5s) Sumber
• gatsbyjs.com (Seluler 77/100, TTI 6.6s) Sumber

Namun beberapa situs lain (dan sebagian besar pemula) berkinerja sangat baik di PageSpeed ​​Insights:

• store.gatsbyjs.org (Seluler 99/100, TTI 2.5s) Sumber
• thirdandgrove.com (Seluler 91/100, TTI 4.0s) Sumber

TTI rata-rata terlihat - dan sementara v6 mengubah bobot keseluruhan TTI dari 33% menjadi 15% dan menurunkan First CPU Idle, ia menambahkan TBT dengan bobot 25% yang mungkin dapat menjelaskan regresi skor secara umum hanya karena penguraian dan eksekusi JS secara keseluruhan.

Lighthouse v6 (dengan WebPageTest.org )

• Ini menjalankan WPT di _Moto G (gen 4), Moto G4 - Chrome_ dengan koneksi _3G Fast (1.6mbps / 768kbps 150ms RTT) _. Ini tampaknya sedekat mungkin dengan perangkat / jaringan yang kami bisa dapatkan sebelum PSI memperbarui versi mercusuar yang mendasarinya.
• Pastikan untuk memeriksa _Capture Lighthouse Report_ di bawah _Chromium_. Saya telah menonaktifkan tampilan berulang untuk mempertahankan cakupan pada pengunjung pertama kali, pemuatan halaman pertama.

Berikut hasilnya, Anda bisa melihat laporan Lighthouse dengan mengklik nomornya. Saya mengekstrak nilai dari laporan itu.

• gatsbyjs.org (72 -> 67/100, TTI 7.5s, TBT 2150ms) Sumber
• reactjs.org (62 -> 66/100, TTI 7.8s, TBT 3520ms) Sumber
• gatsbyjs.com (77 -> 66/100, TTI 8.4s, TBT 2440ms) Sumber

Namun, perhatikan regresi di dua situs berikut:

• store.gatsbyjs.org ( 99 -> 54/100 , TTI 6.8s, TBT 1300ms) Sumber
• thirdandgrove.com ( 91 -> 63/100 , TTI 14s !, TBT 1330ms) Sumber

Beberapa pertanyaan terbuka yang saya miliki.

1. Apakah keseluruhan TTI (dan TBT) dijelaskan oleh penguraian JS + yang dijalankan, atau adakah faktor lain yang mengganggu interaktivitas?
2. Jika demikian, dapatkah kita lebih agresif (baik di Gatsby secara default seperti perubahan terbaru seperti mengaktifkan potongan granular , atau di bawah beberapa tanda eksperimental) saat membuat potongan untuk _only_ mengirim apa yang dibutuhkan pemuatan pertama (yaitu, cegah app- [hash] .js dari memiliki kelebihan)? Bisa juga hanya mendokumentasikan cara bermain dengan memperluas konfigurasi webpack dengan lebih banyak panduan.
3. Bisakah pola seperti Module / nomodule membantu mengurangi potongan? Merekomendasikan / mendokumentasikan penggunaan @ loadable / components? Rehidrasi parsial ?
4. Ini mungkin langkah kedua untuk mendorong skor tinggi, tetapi karena FMP tidak lagi menjadi faktor, apakah LQIP pada gatsby-image membantu atau merugikan dalam hal LCP? LCP store.gatsby.org yang dijalankan di atas adalah 4.7s!

(Saya menggunakan tautan di atas hanya sebagai contoh - jika ada yang ingin tautan tertentu dihapus, saya dengan senang hati dapat mengedit pesannya)

Situs saya (https://matthewmiller.dev/) tampaknya menjadi lebih baik (~ 92 hingga ~ 95), tetapi beberapa pengujian baru mengungkapkan beberapa hal yang mungkin dapat ditingkatkan.

Tes JavaScript yang tidak perlu misalnya,
(Kolom pertama adalah ukuran, kolom kedua adalah jumlah yang tidak diperlukan)

Saya berasumsi ini karena item yang diperlukan untuk halaman lain yang disertakan di sini, jadi menggunakan sesuatu seperti komponen yang dapat dimuat dapat sedikit membantu.

Bagi saya, saya mengalami kesulitan besar dalam memahami Largest Contentful Paint , dalam arti bahwa saya mendapatkan nilai yang sangat besar tanpa mengetahui alasannya, dan melihat perbedaan antara nilai dalam laporan (misalnya 7,4 s, dan LCP label yang muncul di tab Performance - ViewTrace (~ 800 ms)

Saya dapat melihat bahwa sesuatu yang serupa sepertinya terjadi di https://parmsang.github.io/gatsby-starter-ecommerce/ pemula

Sebagai pembaruan - tampaknya PageSpeed ​​Insights telah meluncurkan pembaruan untuk menjalankan Lighthouse v6 (mungkin belum ada di semua wilayah).

Tautan untuk menguji https://gatsbyjs.org/ . Saat ini mendapatkan hasil yang bervariasi dari rendah 60-an hingga pertengahan 80-an, terutama tergantung pada nilai TBT dan TTI.

@kuworking mungkin ada masalah dengan Lighthouse v6 yang mengenali gatsby-image.

Menurut webdev

Untuk elemen gambar yang telah diubah ukurannya dari ukuran intrinsiknya, ukuran yang dilaporkan adalah ukuran terlihat atau ukuran intrinsik, mana saja yang lebih kecil.

Dalam kasus saya, saya pikir Lighthouse tidak menghargai ukuran tampilan.

Dan inilah gambar yang dimaksud

Ini mungkin memperhitungkan ukuran intrinsik yang 3000 piksel maka LCP 13s untuk saya.

@ daydream05 Saya memiliki teori dan temuan serupa juga jadi saya menguji halaman saya tanpa gambar dan masih memiliki LCP yang sangat panjang (10-12sec). Saya memiliki banyak hal yang terjadi dalam proyek saya sehingga bisa menjadi variabel lain juga, tetapi saya ingin tahu apakah Anda telah menguji halaman dengan konten teks dan belum ada gambar.

Turun dari 100 menjadi 79 ~ https://dougsilkstone.com/ baru-baru ini. Melonjak hingga 90 saat Google Tag Manager (dan Google Analytics) dihapus.

Akan melaporkan kembali lebih banyak temuan saat saya menguji berbagai hal.

Sunting: Hit 100 saat menghapus font yang dimuat typekit dari gatsby-plugin-web-font-loader (juga menggunakan cache preload-font).

GTM secara keseluruhan mempengaruhi proyek saya sedikit tetapi tidak perubahan drastis ketika saya menghapusnya (5-10 poin berada di puncak skor sub 50 setelah LH6). Saya masih perlu melakukan lebih banyak pengujian tetapi hanya ingin membuangnya di sana.

@Jimmydalecleveland menarik! Saya juga memiliki situs lain di mana layar saya hanya teks dan menyalahkan teks pahlawan sebagai penyebab utama LCP. Dan LCP hanya memperhitungkan apa pun yang dilihat, yang tidak masuk akal. Bagaimana bisa sebuah teks menjadi masalah besar.

@dougwithseismic Saya juga menggunakan typekit dan itu pasti salah satu penyebab utama untuk skor mercusuar yang lebih rendah. Saya berharap ada cara untuk memperbaiki typekit karena mereka tidak mendukung tampilan font

Saya pikir Lighthouse v6 sangat tangguh pada kerangka kerja JS karena bagaimana mereka mengubah bobot skor. (Lebih fokus pada waktu pemblokiran) Dan situs Gatsby secara historis memiliki evaluasi skrip / skor utas yang rendah karena rehidrasi dan hal-hal lain.

@dougwithseismic bagaimana Anda menghubungkan font typekit tanpa menggunakan stylesheet?

Saya mengalami pengalaman serupa, dengan mercusuar 5.7.1 skor kinerja saya sekitar 91, namun mercusuar 6 secara dramatis menurunkan skor kinerja saya menjadi sekitar 60.

Turun dari 100 menjadi 79 ~ https://dougsilkstone.com/ baru-baru ini. Melonjak hingga 90 saat Google Tag Manager (dan Google Analytics) dihapus.

Akan melaporkan kembali lebih banyak temuan saat saya menguji berbagai hal.

Sunting: Hit 100 saat menghapus font yang dimuat typekit dari gatsby-plugin-web-font-loader (juga menggunakan cache preload-font).

Saya bahkan belum memasang plugin ini, tetapi skor seluler saya turun dari 90+ ​​menjadi 60 ~ 70+

Sama disini. Penurunan besar-besaran dari 90ish menjadi 60ish di banyak situs.

+1 tetes sekitar 30+ poin

Apakah ada yang membahas ini? Sepertinya tidak ada gunanya menggunakan Gatsby daripada Next jika tidak memberikan skor yang lebih baik di luar kotak.

Apakah ada yang membahas ini? Sepertinya tidak ada gunanya menggunakan Gatsby daripada Next jika tidak memberikan skor yang lebih baik di luar kotak.

Apakah Anda memiliki nomor dari Next?

Saya bertanya-tanya apakah skor ini adalah normal baru untuk web cepat (yang tidak statis, bebas JS, dan kemungkinan juga bebas gambar)

Apakah Anda memiliki nomor dari Next?

https://nextjs.org/ memiliki skor 85, dengan Largest Contentful Paint (3.8) dan First Contentful Paint (2.8) menjadi pelanggar utama. Ini juga memiliki banyak "JS yang tidak digunakan". Itu turun dari ~ 95 di Lighthouse 5.7.1. Ini "hanya" penurunan sekitar 10 poin, sedangkan situs gatsby tampaknya kehilangan poin dua kali lebih banyak.

Saya cukup baru di dunia ini, tetapi saya mengikuti masalah ini setelah situs gatsby saya kehilangan sekitar 25 poin saat diuji dengan mercusuar 6.0.0 dari npm. Menariknya, jika saya menggunakan wawasan kecepatan halaman daripada mercusuar npm, situs saya kembali ke sekitar ~ 99. Sedangkan gatsbyjs.org mendapat ~ 70 di wawasan kecepatan halaman, tetapi ~ 84 dengan mercusuar npm. Sesuatu mungkin sedang diubah di suatu tempat, saya kira? Semua dari mereka mendapatkan peringatan 'JS yang tidak digunakan'

Apakah ada yang membahas ini? Sepertinya tidak ada gunanya menggunakan Gatsby daripada Next jika tidak memberikan skor yang lebih baik di luar kotak.

Apakah Anda memiliki nomor dari Next?
Saya bertanya-tanya apakah skor ini adalah normal baru untuk web cepat (yang tidak statis, bebas JS, dan kemungkinan juga bebas gambar)

Situs web Next.js -> https://masteringnextjs.com/ 77 skor seluler. Banyak "JS yang tidak terpakai".

Saya melihat skor yang lebih baik dengan metrik mercusuar https://lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7

Tapi saya juga tidak melihat gambar di sana, dan menurut pengalaman saya, gambar tampaknya memiliki dampak yang tinggi (dan IMO sah)

Namun, gatsbyjs.org tidak memiliki gambar dan skornya (relatif) buruk https://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff (dibandingkan dengan contoh @cbdp )

Mari kita lihat apa pendapat gatsby devs tentang ini

Dengan beberapa penyesuaian, situs kembali ke skor teratas.

Bagi saya, sepertinya kasus Google memindahkan tiang gawang menjadi lebih
ketat tentang kinerja- terutama FCP.

Situs kami tidak lambat dengan cara apa pun, lebih dari itu hanya dinilai dengan berbeda
kriteria. Saya akan membantu yang ini ✌️

Pada Tue, 9 Jun 2020, 18:48 kuworking, [email protected] menulis:

Apakah ada yang membahas ini? Sepertinya tidak ada gunanya menggunakan Gatsby
Selanjutnya jika tidak memberikan skor yang lebih baik di luar kotak.

Apakah Anda memiliki nomor dari Next?
Saya bertanya-tanya apakah skor ini adalah normal baru untuk web cepat (itu
tidak statis, bebas JS dan kemungkinan juga bebas gambar)

Situs web Next.js -> https://masteringnextjs.com/ 77 skor seluler. Banyak
dari "JS yang tidak digunakan".

Saya melihat skor yang lebih baik dengan metrik mercusuar
https://lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7

Tapi saya juga tidak melihat gambar di sana, dan dalam pengalaman saya gambar sepertinya
memiliki dampak yang tinggi (dan IMO sah)

Namun, gatsbyjs.org tidak memiliki gambar dan skornya (relatif) buruk
https://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff
(dibandingkan dengan @cbdp https://github.com/cbdp contoh)

Mari kita lihat apa pendapat gatsby devs tentang ini

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-641433463 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ALSIKRH4G74CRN2FNCUO4NDRVZRVNANCNFSM4NHP7XCA
.

Hanya ingin melepaskan kalkulator berguna ini untuk membandingkan hasil dari v6 dengan v5: https://googlechrome.github.io/lighthouse/scorecalc/

Skor Lighthouse biasanya sangat bervariasi, bahkan saat menggunakannya melalui Wawasan PageSpeed. Misalnya, untuk https://www.gatsbyjs.org/ saya menerima segalanya dari 64 hingga 88 kinerja seluler setelah 5 kali berjalan. Oleh karena itu, untuk melacak masalah ini, kalkulator mungkin berguna untuk melihat konsekuensi dari bobot yang berbeda dalam proses yang sama (catatan: karena metrik sedikit berbeda, beberapa nilai seperti FMP harus diasumsikan menggunakan pengukuran sebelumnya).

PS: Di sini saya memiliki perbandingan dua proses dari PageSpeed ​​Insights untuk gatsbyjs.org:
Jalankan 1 - v6: 67 - v5: 85
Jalankan 2 - v6: 78 - v5: 87
Dampak terbesar disebabkan oleh metrik baru "Total Blocking Time" yang berada di bawah skor 70 di kedua run dan juga memiliki bobot 25%.

Ya, untuk menambah @Pyrax : LCP (Largest Contentful Paint) dan TBT memiliki bobot masing-masing

LCP

• Menghapus animasi apa pun yang mungkin terpicu saat dimuat (mis. Cookie 💩 spanduk).
• Beralih ke gatsby-img tracedSVG sepertinya sedikit membantu, karena kami memiliki gambar pahlawan besar di sebagian besar halaman. (Tidak yakin kenapa sih, tanpa investigasi lebih lanjut. UX juga meningkat sedikit.)

TBT

• Singkatnya, Unused JS dari bundling Gatsby tampaknya menjadi cuplrit terbesar (didukung dokumen web.dev ), dengan tembakan panjang. Guncangan pohon tingkat halaman pasti bisa ditingkatkan di sini?

Pembaruan Lighthouse baru-baru ini tampaknya baru saja mengacaukan skor kinerja semua orang, termasuk kinerja mereka sendiri:

Satu-satunya situs gatsby saya yang belum benar-benar dilenyapkan adalah situs yang pada dasarnya satu halaman dan seperti 99% html. Tetapi bahkan yang satu itu turun sekitar 5-10 poin.

Saya melihat kebalikan dari kebanyakan orang, yaitu, Lighthouse di browser Chrome masih menunjukkan skor yang bagus untuk situs saya, tetapi ketika dijalankan di PageSpeed ​​Insights, skor kinerja turun 20-30 poin ... mungkin versi Lighthouse Chrome saya dibelakang? Chrome adalah yang terbaru, tidak yakin cara memeriksa versi Lighthouse bawaan ...

Pembaruan Lighthouse baru-baru ini tampaknya baru saja mengacaukan skor kinerja semua orang, termasuk kinerja mereka sendiri:

Satu-satunya situs gatsby saya yang belum benar-benar dilenyapkan adalah situs yang pada dasarnya satu halaman dan seperti 99% html. Tetapi bahkan yang satu itu turun sekitar 5-10 poin.

Saya melihat kebalikan dari kebanyakan orang, yaitu, Lighthouse di browser Chrome masih menunjukkan skor yang bagus untuk situs saya, tetapi ketika dijalankan di PageSpeed ​​Insights, skor kinerja turun 20-30 poin ... mungkin versi Lighthouse Chrome saya dibelakang? Chrome adalah yang terbaru, tidak yakin cara memeriksa versi Lighthouse bawaan ...

Versi Lighthouse ditampilkan di bagian bawah audit.

@dylanblokhuis ah, ya itu dia. Saya menggunakan 5.7.1, apakah v6 belum dikirimkan di Chrome?

@dylanblokhuis ah, ya itu dia. Saya menggunakan 5.7.1, apakah v6 belum dikirimkan di Chrome?

Bukan itu. Belum. Jika Anda menginginkan yang terbaru, Anda dapat menginstalnya dari npm dan kemudian menjalankan lighthouse https://yoursite.com --view dan Anda akan mendapatkan skor Anda dalam format yang sama seperti yang biasa Anda lakukan dengan audit Chrome :)

Bagi siapa pun yang mendapat pukulan besar dalam skor, # 24866 mungkin juga relevan. Ada perubahan yang tampaknya cukup signifikan tentang bagaimana Gatsby menyerahkan potongan. Meskipun perubahan tersebut tampaknya sangat masuk akal, setidaknya bagi kami, perubahan ini telah menghasilkan kode yang didistribusikan ke seluruh bagian yang terkonsentrasi dalam potongan commons dan app . Artinya js load / parse yang jauh lebih besar.

Hal yang paling memprihatinkan di sini adalah bahwa metrik ini akan mulai memengaruhi Peringkat Halaman dalam waktu dekat.

Saya telah menghapus semua permintaan pihak ketiga (Tag Manager / Typekit / Pixel / Analytics / ReCaptcha) dan itu hanya memberikan peningkatan skor yang relatif kecil, jadi ada hal lain yang sedang dimainkan.

Selain itu, bagi siapa pun yang ingin menjalankan Lighthouse 6 secara lokal, Lighthouse 6 sekarang tersedia di Chrome Canary dan dijadwalkan untuk dikirimkan ke Chrome pada bulan Juli beberapa waktu.

Pertama: Saya menghubungi teknisi Google yang bekerja di web.dev dan bertanya tentang ini. Tidak yakin apakah itu akan mengarah pada penjelasan yang lebih besar, tetapi mereka tampaknya bermaksud membantu. Saya akan menindaklanjuti ketika saya berhasil mengobrol dengan mereka.

Skor kinerja saya naik dari 94-99 menjadi 40-55. 😢

Cat Konten Terbesar untuk situs web saya sebagian besar berlaku pada halaman dengan gambar besar. Untuk beberapa alasan, dikatakan bahwa gambar membutuhkan waktu 14 detik untuk dimuat.

Jika Anda membuka salah satu situs pemula Gatsby minimal, semua halaman dengan gambar tampaknya berusia maksimal 70-an.

Berikut adalah dua permulaan pertama yang saya lihat dengan banyak gambar:

ghost.gatsby.org :

gcn.netlify.app :

Namun, blog pemula Gatsby memiliki 98 kinerja (memang, ini adalah halaman yang sangat minim hanya dengan beberapa teks):

gatsbyjs.com :

Bandingkan skor lama dengan skor baru di Chrome

Anda masih dapat membandingkan skor metode Lighthouse lama vs. baru tanpa menggunakan CLI. Saya merasa berguna untuk melihat apa yang telah berubah.

Lihat tes Lighthouse lama

Untuk melihat skor Lighthouse lama, jalankan ekstensi chrome Lighthouse dari alat pengembang chrome Anda, bukan dari bilah alat browser.

Lihat tes Lighthouse baru

Klik ikon dari bilah ekstensi chrome Anda.

Halaman saya berubah

Ini adalah dua skor yang saya miliki untuk halaman yang sama persis:

Mercusuar tua (melalui alat dev Chrome)

Mercusuar baru (melalui ekstensi Chrome di bilah alamat)

🤷‍♂️

@nandorojo Kesan saya dengan gambar adalah bahwa emulasi dilakukan dengan koneksi yang sangat lambat dan di sana, gambar membutuhkan waktu lama untuk ditampilkan

Karena pilihan untuk menghapus gambar tidak selalu memungkinkan, mungkin skor 70-an ini adalah nilai normal untuk jenis halaman ini

Dan, opsi untuk menunda pemuatannya sehingga pengguna dapat memulai interaksinya lebih cepat, tampaknya tidak berhasil (dalam kasus saya)

Hei, maaf atas jawaban yang terlambat. Saya telah bekerja di Lighthouse, saya akan mencoba menjelaskan sebaik mungkin.

Pengembang Chrome telah menerbitkan "Web Vitals", metrik penting untuk situs yang sehat. Ini berisi banyak metrik tetapi yang intinya adalah Largest Contentful Paint (LCP) , First Input Delay (FID) , dan Cumulative Layout Shift (CLS) . Untuk alat seperti Lighthouse FID ditukar dengan Total Blocking Time (TBT) .

Lighthouse v6 juga memperhitungkan metrik ini dan telah bergeser. Ini tidak berarti Gatsby lambat. Mungkin beberapa pengoptimalan yang berbeda diperlukan.

Beginilah hal-hal berubah:

Jika Anda ingin tahu lebih banyak tentang LCP, Anda harus memeriksa https://www.youtube.com/watch?v=diAc65p15ag.

Jadi mari kita bicara tentang Gatsby. Gatsby sendiri masih cukup cepat dan kami semakin meningkatkannya. Kami sedang membuat API baru sehingga pembuat halaman seperti MDX, teks kaya Contentful, ... dapat mengoptimalkan bundel juga. Banyak yang bisa dilakukan dengan mengoptimalkan LCP Anda. Pastikan saat menggunakan font & gambar, mereka tidak dimuat dengan malas dan dimuat secepat mungkin. Aset ini harus dimuat dari sumber yang sama dengan situs Anda, aset tersebut tidak boleh dimuat dari CDN.

Sayangnya TBT adalah masalah yang sulit dipecahkan dan merupakan sesuatu yang tidak dioptimalkan oleh React. Jika Anda ingin menghapus TBT, Anda harus membayar prak . Preact memiliki API yang sama dengan React tetapi memiliki footprint javascript yang lebih kecil. Mereka melakukan sesuatu secara berbeda tetapi komponen React kompatibel. Anda menginstalnya dengan menjalankan gatsby recipes preact .

Sesuatu yang saya perhatikan ketika membuat profil gatsbyjs.com & gatsbyjs.org adalah kita harus memuat Google Analytics, dll sedikit lebih lambat dari yang kita lakukan sekarang untuk memastikan itu tidak menjadi bagian dari TBT.

Jika kita melihat .com dengan menunda analitik dan GTM dan memastikan font dimuat lebih cepat, kita sudah dapat melihat peningkatan +17. Jika kita menambahkan preact ke dalam campuran kita melihat +6.

Kita dapat melakukan hal yang sama untuk .org, kita mulai dengan skor 63. Dengan beberapa pengoptimalan LCP dan TBT kita bisa mencapai 75.

Saya tidak yakin apa yang harus kami lakukan dengan masalah ini. Saya merasa kita bisa menutupnya karena tidak banyak lagi yang bisa kita lakukan di sini. Apa yang kalian pikirkan?

@wardpeet Ty untuk wawasan ekstra.

Kami telah banyak menggali masalah ini pada proyek Gatsby besar yang kami miliki yang menggunakan Contentful dan akan digunakan di banyak situs untuk kami (tema Gatsby mengagumkan). Saya akan membagikan beberapa temuan jika mereka membantu orang lain yang melihat ini.

1. Kami memiliki situasi yang mungkin tidak terlalu umum, tetapi saya telah cukup melihatnya untuk percaya bahwa ini juga tidak unik, di mana kami harus menggunakan useStaticQuery untuk mengambil gambar yang berasal dari Contentful dan .find one dengan pengenal. Kami selalu tahu ini salah, tetapi kami tidak secara nyata dihukum untuk itu sampai skala situs berkembang menjadi 300+ gambar dan LH6 muncul dan menghajar kami.

Alasannya adalah karena gambar adalah bagian dari penyematan Teks Kaya, dan kami tidak dapat membuat grafik untuk gambar tersebut di tingkat kueri halaman (pada dasarnya ini adalah bidang json yang memiliki paket untuk diurai oleh Contentful). Saat menggunakan penganalisis bundel Webpack, kami melihat file JSON yang sangat besar (sekitar 720 KB) dan melacaknya menjadi data dari kueri tersebut, yang dikelompokkan ke dalam template yang kami gunakan untuk sebagian besar halaman oleh Webpack. Ini berarti bahwa setiap pengguna yang mengunjungi situs kami mendownloadnya sebagai bagian dari potongan untuk keseluruhan template halaman, terlepas dari halaman tersebut menggunakan gambar atau tidak.

Kami melakukan woopsi besar, tetapi jika ada orang lain yang melakukan kueri statis yang besar (yang tentu saja tidak dapat Anda berikan parameter untuk mengecilkan ukurannya) pastikan Anda berhati-hati terhadap situasi tersebut dan mengawasi potongan bundel Anda.

1. Kami baru saja berhasil hari ini dengan menggunakan properti loading untuk gambar Gatsby pada gambar yang berada di paro atas (Gambar pahlawan untuk kami). Kami telah mencoba mengerjakan Largest Contentful Paint dan ini membuahkan hasil yang baik dalam beberapa pengujian awal. Ada bagian penting yang hampir saya lewatkan untuk ini: Jika Anda menyetel loading="eager" untuk gambar teratas Anda, Anda mungkin ingin menyetel fadeIn={false} juga untuk gambar itu karena transisi antara base64 dan dimuat penuh gambar membutuhkan waktu yang menunda LCP.

Berikut adalah dokumentasi alat peraga yang saya maksud dan catatan tentang fadeIn ada di bagian bawah: https://www.gatsbyjs.org/packages/gatsby-image/#gatsby -image-props

Saya ingin membagikan tangkapan layar tetapi saya tidak tahu apakah diizinkan, maaf. Jika Anda menggunakan devtools Chrome dan melihat panel kinerja, Anda akan diberi tag kecil yang bagus di bawah baris "pengaturan waktu" untuk FP, FCP, FMP dan LCP. Ketika kami beralih ke pemuatan gambar pertama secara kritis, kami tidak hanya melihat ~ peningkatan skor kinerja 8-10 tetapi Anda dapat melihat tag LCP dimuat segera setelah FMP alih-alih satu detik kemudian dalam kasus saya.

Semoga bisa membantu siapa pun memecahkan masalah ini, dan terima kasih kepada semua orang yang telah merespons sejauh ini.

Sesuatu yang saya perhatikan saat membuat profil gatsbyjs.com & gatsbyjs.org adalah kita harus memuat Google Analytics, dll sedikit lebih lambat dari yang kita ketahui untuk memastikannya tidak menjadi bagian dari TBT.

@wardpeet bagaimana Anda menunda analitik dan GTM?

@wardpeet terima kasih atas balasan Anda. Ini berguna. Mungkin hasil terbaik dari masalah ini adalah beberapa dokumentasi yang menguraikan cara mengoptimalkan untuk setiap metrik di Lighthouse baru. Saya yakin bahwa situs kami terasa cepat bagi pengguna dan Gatsby sendiri melakukan pekerjaan yang sangat baik dalam mengoptimalkan situs untuk pengguna yang sebenarnya. Namun jika web vitals Google akan mulai menginformasikan peringkat halaman, mendapatkan skor mercusuar yang bagus akan menjadi misi penting untuk sebagian besar situs.

@Jimmydalecleveland kami memiliki masalah yang sama di mana kami harus memuat semua item sumber daya sehingga kami dapat menggunakan data dari dalam penurunan harga untuk mengkonfigurasi filtwr (yaitu kami tidak dapat memfilter menggunakan GraphQL) dan dioptimalkan dengan menggunakan fragmen yang berbeda (a subset bidang yang jauh lebih kecil) saat memuat sumber daya lengkap vs. saat memuat semua sumber daya untuk pemfilteran. Ini sangat mengurangi JSON kami dan karena itu ukuran bundel kami.

@treyles Anda harus berhati-hati dalam menunda pemuatan Analytics karena ini bisa berarti statistik Anda tidak lengkap. Misalnya, rasio pentalan yang dilaporkan tidak akurat. Ada beberapa skrip yang pemasaran tidak mengizinkan kami untuk menunda (piksel, analitik, hotjar dan oleh karena itu pengelola tag), tetapi yang lain, misalnya Interkom baik-baik saja dan merupakan pengoptimalan yang bermanfaat. Dalam hal cara menunda skrip ini, skrip yang disediakan oleh pihak ketiga biasanya memuat asinkron, tetapi ini saja tidak cukup. Apa yang mungkin perlu Anda lakukan adalah mengganti skrip ini dengan skrip Anda sendiri. Dengarkan window.load, lalu picu unduhan. Anda harus berhati-hati karena beberapa skrip mengandalkan window.load untuk menginisialisasi, dan jika Anda telah menggunakannya untuk memuat skrip, skrip tidak akan aktif lagi, jadi Anda perlu menginisialisasi secara manual. Misalnya dengan Intercom kami:

• menghapus degault <script>...</script> disediakan oleh Intercom.
• menambahkan pendengar untuk window.load
• menambahkan penundaan singkat dalam pendengar ini
• memicu skrip default Intercom versi modifikasi yang memuat async libnya.
• disurvei untuk melihat kapan skrip dimuat (Intercom tidak menyediakan acara yang dapat diandalkan)
• secara manual menginisialisasi skrip mereka (yang dilakukan di halaman.load oleh skrip default mereka).

@wardpeet terima kasih atas wawasan yang sangat berguna!

Mengenai solusi ini:

Pastikan saat menggunakan font & gambar, mereka tidak dimuat dengan malas dan dimuat secepat mungkin. Aset ini harus dimuat dari sumber yang sama dengan situs Anda, aset tersebut tidak boleh dimuat dari CDN.

Bukankah ini bertentangan dengan cara kerja gambar gatsby? Selain itu, sebagian besar CMS menangani transformasi gambar di server dan dihosting di CDN-nya sendiri. (Yang merupakan hal yang baik, imo). Tetapi jika kita menghostingnya di situs kita sendiri, bukankah ini juga akan menjadi kontraproduktif?

Menambah apa yang dikatakan @Undistraction , Gatsby memang cepat tapi kalau menurut Google tidak cepat maka jadi bermasalah. Apalagi mereka memasukkan ini dalam pembaruan peringkat halaman tahun depan.

@Jimmydalecleveland Saya menemukan cara untuk bekerja dengan gambar gatsby di dalam teks kaya konten tanpa peretasan kueri itu! Inilah intinya . Kode telah disalin dari gatsby-source-contentful . Pada dasarnya, Anda dapat menghasilkan cairan konten atau alat peraga tetap di luar GQL. Yang sempurna untuk teks kaya konten.

Saya juga membuat permintaan tarik sehingga kami dapat mengakses API langsung dari gatsby-source-contentful .

Sesuatu tidak cocok untukku. Saya membangun situs web yang sangat sederhana dengan tentang gambar per halaman, saya menggunakan SVG untuk gambar tanpa gambar gatsby, saya juga mencoba menghapus Google analytics dan itu tidak membuat banyak perbedaan, skor saya sekitar 50 - 60 untuk kinerja.

Sesuatu yang sangat membingungkan bagi saya adalah hanya halaman beranda (index.js) yang mendapatkan skor sangat rendah, sedangkan halaman lain seperti halaman layanan atau halaman kontak mendapatkan skor ~ 80. Saya membangun situs ini dengan cukup konsisten sehingga tidak ada perbedaan yang mencolok antar halaman, namun untuk beberapa alasan halaman beranda memiliki skor ~ 50 sedangkan halaman layanan memiliki skor ~ 80.

Seperti yang saya sebutkan sebelumnya, dengan mercusuar v5, skornya ~ 90, sama sekali tidak masuk akal bahwa situs sederhana seperti ini sekarang akan memiliki skor rendah ~ 50.

Ngomong-ngomong, pernahkah di antara Anda mencoba menyetel gambar paruh atas sebagai eager ?
Tindakan ini menonaktifkan pemuatan lambat dan dapat meningkatkan skor. Buram atau svg
efek pemuatan mungkin membingungkan Lighthouse (yang jika memang demikian
cacat dalam algoritme mereka).

Pada hari Sabtu, 13 Jun 2020, 10:48 t2ca [email protected] menulis:

Sesuatu tidak cocok untukku. Saya membangun situs web yang sangat sederhana
dengan sekitar gambar per halaman, saya menggunakan SVG untuk gambar tanpa gambar gatsby,
Saya juga mencoba menghapus Google Analytics dan itu tidak menghasilkan banyak
perbedaannya, skor saya sekitar 50 - 60 untuk kinerja.

Sesuatu yang sangat membingungkan bagi saya adalah hanya halaman muka saja
(index.js) mendapatkan skor yang sangat rendah, sementara halaman lain menyukai
halaman layanan atau halaman kontak mendapatkan skor ~ 80. Saya membangun ini
situs cukup konsisten sehingga tidak ada perbedaan yang mencolok antara
halaman namun untuk beberapa alasan halaman beranda memiliki skor ~ 50 sedangkan
halaman layanan memiliki skor ~ 80.

Seperti yang saya sebutkan sebelumnya, dengan lighthouse v5, skornya ~ 90, itu saja
tidak masuk akal sama sekali bahwa situs sederhana seperti ini sekarang akan memiliki harga rendah
skor ~ 50.

-
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-643648423 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAARLB2Q2IVSNVKGGBZ3ZPDRWOUU5ANCNFSM4NHP7XCA
.

@KyleAMews Kami memiliki, dan itu membuat peningkatan yang signifikan dalam skor kinerja dan cat pertama. Inilah yang saya uraikan sebagai poin 2 dalam komentar panjang saya di atas. Membatalkan fadeIn inilah yang akhirnya membuat LH senang.

Sunting : Saya, mungkin secara tidak sadar, merasa bahwa fokus pada LCP bukanlah pendekatan yang tepat untuk secara universal mengambil perhatian pada gambar. Jelas anekdot, tetapi saya merasa bahwa sebuah situs web terasa lebih cepat ketika semua konten dimuat dan gambar memudar di kata penutup, kecuali gambar itu penting untuk konten.

Salah satu contoh umum adalah artikel Medium. Tentu, Anda bisa mengatakan itu adalah cacat desain, tetapi sebagian besar artikel Medium (dan banyak blog lainnya) dimulai dengan gambar besar di bagian atas yang hanya untuk pembuatan suasana hati atau pemandangan dan saya tidak peduli jika itu lambat dimuat di .

Ngomong-ngomong, pernahkah di antara Anda mencoba menyetel gambar paruh atas sebagai eager ? Tindakan ini menonaktifkan pemuatan lambat dan dapat meningkatkan skor. Efek pemuatan blur atau svg mungkin membingungkan Lighthouse (yang jika demikian masalahnya adalah kesalahan dalam algoritme mereka).
…

Saya akan mencoba ini sekarang.

Saya pikir saya membuat kemajuan yang baik di sini. Saya mendapatkan skor saya dari 57 menjadi 84 dengan perubahan yang sangat mendasar. LCP saya berubah dari 12 detik menjadi 2 detik .

Bisa dikatakan, itu tidak konsisten. Sejak membuat perubahan yang akan saya jelaskan di bawah, skor saya bervariasi dari 69 - 84. Jelas ada beberapa varian acak pada skor kinerja.

TLDR

Pertama, seperti @KyleAMathews dan @Jimmydalecleveland menyarankan, saya mencoba setting loading="eager" dan fadeIn={false} pada saya komponen gatsby gambar yang di atas flip.

Selanjutnya, saya menyingkirkan base64 dari kueri saya.

Ini membuat perbedaan besar.

Yang baik

• Menambahkan _noBase64 ke fragmen gambar saya meningkatkan skor saya 20 poin!

  • Sepertinya gambar base64 menambah banyak bobot di perangkat seluler. Saya meminta gambar dari konten yang berisi menggunakan localFile -> childImageSharp -> fluid -> GatsbyImageSharpFluid_withWebp_noBase64 .

• loading="eager" dan fadeIn={false} membuat waktu Largest Contentful Paint saya turun sekitar 50%!

  • Skor kinerja saya yang sebenarnya hanya naik 6-7 poin karena suatu alasan, tetapi LCP pasti membuat kemajuan ...

Kueri saya terlihat seperti ini:

localFile {
  childImageSharp {
      fluid(maxWidth: 800, quality: 100) {
        ...GatsbyImageSharpFluid_withWebp_noBase64
      }
   }
}

Dan gatsby-image terlihat seperti ini:

<Image 
  fluid={localFile.childImageSharp.fluid}
  fadeIn={false} 
  loading="eager"
/>

Yang kurang bagus

UX saya di situs web saya sekarang terlihat jauh lebih buruk. Base64 + fade in memberikan UX yang bagus. Sekarang, agak berombak. Saya kira itu trade-off yang harus kita pertimbangkan sekarang?

Sebelum & sesudah eager & fadeIn={false}

Berikut adalah beberapa perbandingan berdampingan dari halaman yang sama persis. Satu-satunya perbedaan adalah bahwa di sebelah kanan, gambar memiliki loading="eager" dan fadeIn={false} .

1. Halaman rumah

LCP turun 49%. Skor kinerja naik 6 poin.

2. Halaman Produk

LCP turun 46%. Skor kinerja naik 7 poin.

Yang aneh tentang contoh di atas: tangkapan layar di sebelah kiri memiliki perilaku gatsby-image default (mereka memudar, dan tidak memiliki eager aktif.) Namun, meskipun skor kinerjanya lebih rendah , tangkapan layar kecil di bagian bawah membuatnya tampak seperti memuat lebih cepat daripada gambar di sebelah kanan.

Mungkin itu dalam margin kesalahan untuk bagaimana mereka menilai kinerja, atau mungkin itu bug di pihak mereka terkait dengan efek fade, seperti yang disebutkan @KyleAMathews .

Setelah menyetel _noBase64 dalam fragmen gambar

Berikut adalah layar yang sama seperti contoh di atas. Mereka semua memiliki loading="eager" , fadeIn={false} props di Gatsby Image. Juga, fragmen gambar di graqhql adalah GatsbyImageSharpFluid_withWebp_noBase64

Agak tidak bisa dijelaskan, tapi saya menjalankan tes mercusuar di halaman yang sama berulang kali, dan mendapatkan 84, 75, dan 69.

Agak aneh, tapi bagaimanapun juga, itu meningkatkan nilai saya.

Saya pikir algoritma Lighthouse terasa sangat murah hati di sini lol ^

Setelah penyelidikan lebih lanjut, saya menemukan bahwa mercusuar mengeluh tentang elemen tertentu yang memengaruhi skor LCP.

Yang saya lakukan hanyalah memindahkan elemen ini yang hanya satu paragraf dan skor saya melonjak di atas 80. Angka lanjut. Tidak begitu yakin mengapa memindahkan paragraf meningkatkan skor saya dari ~ 50 menjadi ~ 80.

@nandorojo Terima kasih atas

Setelah penyelidikan lebih lanjut, saya menemukan bahwa mercusuar mengeluh tentang elemen tertentu yang memengaruhi skor LCP.

Yang saya lakukan hanyalah memindahkan elemen ini yang hanya satu paragraf dan skor saya melonjak di atas 80. Angka lanjut. Tidak begitu yakin mengapa memindahkan paragraf meningkatkan skor saya dari ~ 50 menjadi ~ 80.

@ t2ca Inilah yang saya dapatkan (meskipun milik saya adalah tag header). Tapi kemana kamu memindahkannya?

@ t2ca Inilah yang saya dapatkan (meskipun milik saya adalah tag header). Tapi kemana kamu memindahkannya?

@michaeljwright Hal pertama yang saya lakukan adalah menghapus paragraf dan memeriksa skor mercusuar. Setelah saya menghapus paragraf, skor saya meningkat sekitar 20 poin. Saya mengulangi tes itu berkali-kali hanya untuk memastikan. Saya juga mengembalikan paragraf dan melakukan tes lebih lanjut dan nyeri saya berkurang sekali lagi.

Akhirnya, saya memutuskan untuk memindahkan paragraf saja, saya menggunakan gerakan framer di dalam div dan saya baru saja memindahkan paragraf di luar div. Ini memberi saya hasil yang sama seperti ketika saya menghapus paragraf.

@ t2ca Saya rasa LCP menghukum animasi apa pun di halaman pahlawan kami yang mengecewakan.

Inilah skor LCP saya di mana tag paragraf adalah LCP

Dengan animasi:

Tanpa animasi:

@ t2ca Saya rasa LCP menghukum animasi apa pun di halaman pahlawan kami yang mengecewakan.

Inilah skor LCP saya di mana tag paragraf adalah LCP

Dengan animasi:

Tanpa animasi:

@ daydream05 Terima kasih telah mengonfirmasi!

@hayal_lucu

Bukankah ini bertentangan dengan cara kerja gambar gatsby? Selain itu, sebagian besar CMS menangani transformasi gambar di server dan dihosting di CDN-nya sendiri. (Yang merupakan hal yang baik, imo). Tetapi jika kita menghostingnya di situs kita sendiri, bukankah ini juga akan menjadi kontraproduktif?

Tidak, karena gatsby-image juga berfungsi dengan gambar lokal, tidak perlu menyimpannya di CDN yang berbeda. Semuanya bermuara pada mengoptimalkan render pertama Anda (apa yang ada di viewport). Menghostingnya di domain / CDN yang berbeda berarti Anda harus membuka koneksi baru (penyelesaian dns, jabat tangan tls, ...) ini dapat memakan waktu hingga 300 md pada perangkat yang lambat dan kemudian Anda masih harus mengunduh gambar Anda.

Menambah apa yang dikatakan @Undistraction , Gatsby memang cepat tapi kalau menurut Google tidak cepat maka jadi bermasalah. Apalagi mereka memasukkan ini dalam pembaruan peringkat halaman tahun depan.

Kami akan lebih mengoptimalkan Gatsby untuk memastikan pengguna kami bisa mendapatkan 100 gratis.

@ t2ca Saya rasa LCP menghukum animasi apa pun di halaman pahlawan kami yang mengecewakan.

Itu diharapkan karena layar Anda tidak pernah berhenti melukis. Biasanya LCP harus mengabaikan animasi CSS, tetapi itu tergantung pada bagaimana Anda melakukan animasi.

@ t2ca

Jika Anda dapat menunjukkan situs tersebut kepada kami, kami dapat membantu mencari cara untuk memperbaikinya, tetapi mungkin itu mengatur gambar menjadi bersemangat.

@tokopedia

Tulisan yang luar biasa! Adakah kemungkinan Anda dapat memberi kami tautan ke laporan mercusuar itu?

Itu diharapkan karena layar Anda tidak pernah berhenti melukis ...

@wardpeet, maukah Anda

@DannyHinshaw Saya menerima penjelasan ini dari mercusuar
"Menurut saya yang terjadi adalah LCP peduli tentang gambar yang dimuat penuh dan waktu yang dilaporkan adalah saat gambar dimuat sepenuhnya dan bukan saat gambar pertama kali terlihat. Kali ini dapat berbeda karena gambar progresif dan cat berulang. "

Lalu tautan ini, mungkin bantuan
https://web.dev/lcp/#when -is-terbesar-konten-cat-dilaporkan

Sementara itu, yang juga dapat Anda coba adalah mengubah Largest Contentful Paint (LCP) dari gambar menjadi teks (jika Anda memiliki kemewahan), preloading / prefetching font, dan malas memuat gambar. Dalam kasus saya, itu berarti mengurangi ukuran gambar pahlawan di ponsel yang meningkatkan skor kami kembali ke 90-an saat masalah ini sedang dibahas.

import semiBoldFont from 'static/fonts/SemiBold-Web.woff2';
...
<Helmet>
   <link rel="prefetch" href={semiBoldFont} as="font"></link>
</Helmet>

https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fwhatsmypayment.com%2F
https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content

Itu diharapkan karena layar Anda tidak pernah berhenti melukis ...

@wardpeet, maukah Anda

Tentu saya tidak tahu situs mana ini, saya mencoba menemukan URL di utas ini tetapi itu sulit. LCP tidak memperhitungkan animasi CSS akun (transisi, alat peraga animasi dalam css). Namun, jika Anda memiliki konten yang menggunakan setTimeout / setInterval yang mengganti komponen react, itu akan mempertimbangkannya. Pendekatan terakhir akan memberi Anda skor CLS yang sangat buruk.

Jadi jika Anda ingin menghidupkan teks / gambar pahlawan Anda. Silakan gunakan animasi css.

Halo,

Saya mencoba mencari tahu mengapa proyek saya mendapat skor sangat rendah di Google Page Speed ​​Insights, audit Google Lighthouse, dan banyak lagi.

Singkatnya memulai dari awal saya tidak yakin apa masalahnya. Saya menggunakan starter / tema ini untuk memulai: https://github.com/alexislepresle/gatsby-shopify-theme

Saya kebanyakan dan sedang dalam proses changibg css hal-hal seperti berpindah dari bulma ke chakra-ui.

Ini repo saya: https://github.com/Chizzah/genesis-style
Saya mencoba menghapus semua item akun dan hal-hal gatsby-plugin-appollo-shopify tetapi itu tidak mengubah banyak hal.

Ini tautan langsungnya: https://genesis-style.netlify.app

Tidak ada yang tampaknya saya lakukan yang mengubah banyak hal. Saya lebih suka tidak memulai dari awal. Jika ada yang bisa memberi saya petunjuk atau sesuatu, saya akan menghargainya.

Sepertinya saya terlalu terbiasa dengan Gatsby memberikan 90-100 gratis

Terima kasih untuk utas ini karena diskusi tentang pencapaian skor mercusuar yang bagus diperlukan. Skor luar biasa menjadi lebih sulit dengan v6, sebagian besar karena metrik LCP yang baru. Situs saya (https://www.jamify.org) turun dari ~ 100 menjadi ~ 70 dengan Lighthouse v6.

Untuk mengembalikannya ke 100 di desktop, saya harus

• menghapus gambar latar belakang yang tidak diperlukan (karena salah dipilih sebagai LCP)
• mengoptimalkan ukuran gambar
• setel gatsby-image menjadi loading="eager" dan fadeIn=false
  (itu benar-benar mengecewakan karena saya suka efek blur-up)

Di seluler, saya masih terjebak di 80, lagi-lagi karena LCP 5 detik. Ini dapat ditingkatkan dengan mengukur gambar secara tepat khusus untuk seluler:

Secara keseluruhan, pengoptimalan ini cukup layak, namun, saya sangat tidak senang karena sekarang saya harus memilih antara gambar yang lambat dimuat dengan blur atau skor Lighhouse yang bagus: roll_eyes:

Apakah ada yang sudah melakukan tes pada mercusuar v6.1? Saya telah memperhatikan peningkatan pada skor kinerja saya.

Tanya Addy dari Google tentang masalah LCP yang kabur & itu adalah sesuatu yang sedang mereka perbaiki https://twitter.com/addyosmani/status/1277293541878673411

Pelajaran di sini adalah jangan perlakukan skor kinerja baru sebagai mutlak dulu - mereka masih menyempurnakan kasus tepi.

Saya yakin masalahnya semakin parah dengan Lighthouse 6.1. Ada beberapa saran bagus di sini seputar LCP tetapi kami tidak terlalu banyak melihat TBT yang menurut saya merupakan alasan terbesar untuk skor buruk di ponsel dan paling sulit dipecahkan.

Anda dapat menguji Lighthouse 6.1 di Chrome Canary. Saya telah membandingkan situs saya antara 6.0 dan 6.1, serta beberapa lainnya yang disebutkan di sini dan TBT meningkat secara drastis. Misalnya dalam tes 6.1 saya:

• gatsbyjs.org TBT: 2550ms
• situs saya TBT: 2200ms
• @ situs TBT: 1250 md

Apa pun yang lebih dari 600 untuk TBT berwarna merah dan bobot menurut kalkulator adalah 25% jadi faktor utama. TBT disebabkan oleh fungsi yang membutuhkan waktu lebih dari 50 md untuk dijalankan antara FCP dan Time to Interactive.

Tangkapan layar di atas adalah profil dari situs saya. Jika Anda menggunakan Lighthouse di Chrome, Anda dapat mengklik tombol View Trace untuk memuat hasil ke tab profil untuk melihat hal yang sama. Setiap tugas setelah FCP dengan bendera merah di sudut dihitung sebagai TBT. Saya belum menggali lebih dalam apa tugasnya jadi mungkin seseorang yang memiliki pengetahuan lebih tentang Gatsby dapat membantu di bidang ini dan mungkin @wardpeet dapat memberikan wawasannya tentang TBT jika memungkinkan. Ada beberapa tugas besar yang membutuhkan waktu antara 500ms - 1s dalam pengujian saya, jadi menurut saya tugas tersebut harus dianalisis.

@IanLunn itu jejak yang menarik, apakah Anda bisa memahami apa tugas-tugas di bawahnya?

Kemungkinan ada korelasi antara berapa banyak JS yang dimiliki setiap Situs Gatsby dan seberapa mahal jadinya di utas utama browser. Bagaimanapun saya pikir ruang terbuka untuk diskusi bisa jadi, adakah cara Gatsby dapat membantu "mengurangi" dampak dengan cara memuat kueri dan skrip sekaligus?

Ada tiga area yang saya coba pahami dengan lebih baik saat ini:

• Gatsby menambahkan secara default <link rel=preload/> untuk setiap skrip yang dibutuhkan (sesuai dengan pola PRPL ) terlepas dari berapa banyak yang ada. Saya telah memperhatikan beberapa perbedaan dalam FCP terukur (yang cukup mengejutkan saya) tetapi sebagian besar pada celah antara FCP / LCP saat menghapus ini (yang mungkin bukan ide cemerlang untuk dilakukan tanpa perubahan lain). Masalah mercusuar ini membahas yang terakhir.
• Kueri akhirnya membuat JSON (halaman-data.json dan yang di-hash untuk kueri statis) yang dievaluasi pada utas utama. Lihat https://github.com/gatsbyjs/gatsby/issues/18787 tetapi tampaknya kami tidak menemukan (atau jika ada) alternatif yang tidak memblokir utas utama. Semakin besar datanya, semakin banyak kinerja yang dicapai (jadi anggaran kinerja untuk ukuran kueri pasti akan sangat diterima) - tetapi data tersebut tidak benar-benar diperlukan hingga proses rehidrasi, atau benarkah?
• Potongan sebenarnya ditambahkan sebagai <script src=foo.js async /> di akhir </body> . Ini berarti bahwa segera setelah browser selesai mengurai HTML (yang seharusnya segera dilacak), browser akan mulai mem-parse dan menjalankan skrip tersebut (karena sudah dimuat sebelumnya). Tugas yang panjang pasti akan muncul karena utas utama diminta untuk mengurai dan menjalankan semua javascript itu. Apakah ada cara yang lebih baik untuk menangani ini (setidaknya _ketika_ skrip tersebut mulai diurai) untuk menghindari pemblokiran utas utama? Apakah ada cara untuk melakukan ini (baik parsing atau eksekusi) dalam tugas kecil tambahan yang tidak menunda masukan masukan (dan dengan demikian membahayakan TTI), atau memblokir thread utama dalam waktu singkat (dan dengan demikian membahayakan TBT)?

Sementara saat ini memang benar situs Gatsby sedang dikenai sanksi karena LCP belum mengenali pola LQIP dari gatsby-image - jika menyangkut apa pun yang terkait dengan TBT / TTI (dan mungkin hukuman besar pada biaya Javascript dibandingkan dengan Lighthouse v5) Saya rasa tidak ada apa pun dalam peta jalan tim mercusuar yang akan meningkatkan skor saat ini.

@juanferreras Tugas terbesar tampaknya adalah domready / ready.js (pihak ketiga). Saya merasa pernyataan Anda tentang hukuman Lighthouse JavaScript benar dan meskipun pengoptimalan kecil mungkin dilakukan di Gatsby, itu bukanlah sesuatu yang dapat dipecahkan.

Jika akan menjadi seperti ini di Lighthouse, saya tergoda untuk setidaknya meminta mereka mengurangi bobot TBT atau memberikan opsi untuk menyetel lingkungan pengujian yang diinginkan. Memberikan skor berdasarkan anggaran telepon tidak selalu sesuai untuk situs yang sedang diuji. Kita harus bisa menunjukkan kepada atasan / klien bahwa ya, telepon murah mendapat skor 75 tetapi telepon kelas atas yang 95% pengguna kami mendapat skor 90 misalnya.

• Kueri akhirnya membuat JSON (halaman-data.json dan yang di-hash untuk kueri statis) yang dievaluasi pada utas utama. Lihat # 18787 tetapi tampaknya kami tidak menemukan (atau jika ada) alternatif yang tidak memblokir utas utama. Semakin besar datanya, semakin banyak kinerja yang dicapai (jadi anggaran kinerja untuk ukuran kueri pasti akan sangat diterima) - tetapi data tersebut tidak benar-benar diperlukan hingga proses rehidrasi, atau benarkah?

@juanferreras , mengenai masalah penguraian data json di utas utama, yang terlintas dalam pikiran adalah pekerja web. Gatsby dapat mendaftarkan pekerja web jika tersedia di klien, dan menyangga hal-hal semacam ini ke dalamnya, proses rehidrasi tidak terlalu dibutuhkan dengan segera, jadi ini bisa dilakukan.

Pekerja web didukung di browser utama termasuk IE10.

… Kami tidak terlalu memperhatikan TBT yang menurut saya merupakan alasan terbesar untuk skor buruk di ponsel dan paling sulit dipecahkan.

Saya ingin menambahkan sesuatu yang menurut saya relevan dengan Total Blocking Time. Setelah meninjau bundel saya dengan penganalisis bundel Webpack, saya melihat bahwa data dari kueri statis disertakan dalam bundel JavaScript. Saya yakin ada alasan bagus untuk itu, tetapi ini berhasil melawan TBT rendah.

TBT adalah masalah yang sulit dipecahkan terutama karena React tidak dibuat untuk itu. Pindah ke preact adalah langkah awal yang baik. Kami akan meningkatkan TBT lebih banyak lagi dalam beberapa bulan mendatang, kami ingin Gatsby memiliki jejak yang sangat kecil.

Pada versi gatsby> 2.24.0 kami mengirimkan dukungan polyfill yang ditingkatkan sehingga kami hanya memuat polyfill di browser lama seperti IE11. Kami juga telah menghapus kueri statis dari webpack, beberapa hari yang lalu (@MarkosKon).

@Teclone sayangnya, webworker tidak bagus untuk penguraian JSON. Anda masih membayar harga untuk serialisasi dan deserialisasi antar utas. Dengan ShardArrayBuffer itu akan menjadi cerita yang berbeda, sayangnya mereka dinonaktifkan secara default karena Meltdown / momok

Saya baru saja mendapatkan 100/100 dengan baik untuk semua yang ada di Lighthouse (6.0) bawaan di Chrome dan kemudian menggunakan versi web.dev (6.1) dan kembali dengan kinerja di tahun 70-an karena LCP (sekitar 5-6 detik dalam 6.1, sekitar 0,5 detik dalam 6.0). Ini adalah gambar header dekoratif (menggunakan gatsby-background-image) yang dikeluhkan.

Melihat situs web saya sendiri, runtime Webpack memiliki jumlah waktu eksekusi javascript tertinggi. Sesuatu yang bahkan tidak dibutuhkan halaman sampai pengguna mulai berinteraksi dengan halaman.

Gatsby sepertinya hanya memuat semua sumber daya ini (potongan) sekaligus. File js itu sendiri sangat kecil, ini adalah sebuah loader, Anda dapat melihat bahwa hanya perlu 2ms untuk melewatkan file tersebut. Tetapi file itu sendiri memuat potongan dan file template.

Faktanya, ketika saya memeriksa file chunk, saya menemukan bahwa semuanya adalah impor dinamis, yang, kami berharap file tersebut dimuat hanya saat diperlukan, tetapi tidak, semuanya dimuat secara default. Perilaku ini tidak seperti yang saya harapkan.

Melakukan sedikit pengoptimalan gambar header kami seperti menggunakan gambar secara langsung daripada Gatsby-Image dan mengurangi resolusi dan kompresi, dan milik kami sedikit lebih baik. Hanya saja, saya baru saja menemukan cara yang sulit bahwa Safari tidak mendukung WebP (grr). Dan terus menjadi kasus bahwa versi web Lighthouse jauh lebih tidak memaafkan daripada yang ada di Chrome, setidaknya untuk situs pengembangan "tersembunyi" kami. Waktu akan memberi tahu apakah data pengguna yang dikumpulkan membantu setelah ditayangkan - Saya tidak yakin ada banyak yang menggunakan Moto G5 di dunia nyata!

@derykmarl Ini harus segera didukung: https://www.macrumors.com/2020/06/22/webp-safari-14/
Saya tidak mengerti mengapa Apple membutuhkan begitu banyak waktu untuk mendukung format gambar yang tersebar luas ...

Saya membaca bahwa pagespeedinsight mengemulasi bagaimana skor dihitung. Tampaknya mereka tidak membatasi jaringan sehingga Anda bisa mendapatkan laporan lebih cepat. Saya pribadi menggunakan https://lighthouse-metrics.com/ tetapi mereka belum mendukung 6.1.

Masalah dengan mercusuar 6.x adalah bahwa hal itu bergantung pada waktu persepsi, Anda dapat menjalankan pengujian yang sama 10 kali dan Anda tidak akan mendapatkan hasil yang sama tergantung pada kondisi jaringan.

itu muncul kembali dengan kinerja di tahun 70-an karena LCP

Saya memiliki LCP yang merupakan gambar latar belakang untuk situs web saya, saya dapat secara drastis mengurangi LCP saya dengan membagi gambar menjadi 6 sub gambar. Saya membuat skrip python untuk melakukan ini dengan mudah, selama Anda tahu ketinggian yang Anda inginkan untuk setiap segmen Anda

from PIL import Image
import os
import ntpath

def crop(pathToFile, height, width=False):
    im = Image.open(pathToFile)
    imgwidth, imgheight = im.size
    [name, ext] = ntpath.basename(pathToFile).split('.')

    if(not width):
        width = imgwidth

    k=1
    for i in range(0,imgheight,height):
        for j in range(0,imgwidth,width):
            box = (j, i, j+width, i+height)
            a = im.crop(box)
            a.save(os.path.join("./" + name + "-" + str(k) + "." + ext), compress_level=9, optimize=True)
            k +=1

pathToFile = '/path/to/your/img.jpg'
crop(pathToFile, 933)

Saya juga menemukan situs web kompresi gambar ini berfungsi sangat baik untuk mengurangi ukuran gambar Anda tanpa kehilangan terlalu banyak kualitas. Saya biasanya bisa turun ke tanda kualitas 20% -30% dan secara drastis mengurangi ukuran file saya.

Saya mengajukan beberapa pertanyaan tentang ini secara online dan beberapa orang menyarankan agar saya hanya membagi gambar saya menjadi 2, untuk paruh atas dan paro bawah, tetapi menurut saya, membelah menjadi 6 bekerja jauh lebih baik.

@wardpeet pada catatan TBT / TTI, kami mungkin dapat melihat bagaimana situs berbasis react lainnya sekarang mengurangi dampak keseluruhan pada utas utama browser.

reactjs.org itu sendiri (yang juga dibangun dengan Gatsby sejauh yang saya tahu) tampaknya memiliki TTI yang jauh lebih kecil (7-8 ~ vs 12 ~) daripada gatsbyjs.com yang baru (selamat atas peluncurannya!). NextJS juga mempertahankan angka yang sangat baik di TTI / TBT meskipun berbasis React sendiri (mungkin juga karena ukuran skrip relatif - di mana gatsby.com memiliki sekitar 628.3kb skrip menurut PSI, reatjs.org 466.1kb , dan nextjs.org hanya 216.8kb)

(ini jelas sekali berjalan dan tidak boleh digunakan sebagai perbandingan sebenarnya, tetapi trennya cukup konsisten di beberapa proses).

Apakah sebagian besar perbedaan skor disebabkan oleh Biaya Javascript ™ secara keseluruhan? Jika tim Gatsby mengoptimalkan situs web baru di beberapa titik, itu mungkin merupakan peluang bagus untuk berbagi beberapa wawasan tentang prosesnya, asalkan tidak banyak keajaiban yang tersisa untuk ditambahkan ke bagaimana kerangka gatsby sudah menangani javascript secara internal.

@juanferreras @wardpeet , Ada juga sesuatu yang saya temukan di proyek saya sendiri. Jika Anda menggunakan komponen bergaya, untuk beberapa alasan, gaya dihitung ulang / dibuat ulang selama hidrasi dan dimasukkan kembali ke dalam browser. Ini membutuhkan banyak utas utama.

Ini karena masalah hidrasi di gatsby. https://github.com/styled-components/styled-components/issues/2171

Gatsby juga bekerja untuk menjalankan ssr selama pengembangan, https://github.com/gatsbyjs/gatsby/issues/25729 , ini akan membantu mengatasi masalah kinerja semacam ini. terlalu.

@ditprokem

https://github.com/styled-components/styled-components/issues/2171 tampaknya tidak menawarkan solusi. Bagaimana Anda memperbaikinya dalam proyek Anda?

@dfguo , untuk saat ini, belum ada solusi untuk itu, karena tidak ada yang tahu persis mengapa gaya diregenerasi selama rehidrasi karena gatsby dalam produksi tidak menawarkan bantuan pengembangan dengan kesalahan rehidrasi.

Artinya, tidak ada log konsol dari perbedaan penunjuk React selama rehidrasi karena log tersebut dinonaktifkan dalam build produksi gatsby.

Tujuan dari pekerjaan yang sedang berlangsung # 25729 ini adalah untuk menjalankan RSK yang sebenarnya dalam pengembangan, sehingga kita dapat mengetahui alasannya. termasuk tim gatsby.

BTW, Anda dapat membangun situs Gatsby dengan gatsby build --no-uglify untuk membangun situs Anda dengan versi pengembangan dari React untuk melihat log. https://www.gatsbyjs.com/docs/gatsby-cli/#build

Dev SSR akan sangat membantu di masa depan untuk hal-hal seperti ini!

Jadi, saya telah memutuskan untuk memigrasi situs saya dari @emotion dan theme-ui menjadi linaria sambil menerapkan mode dark-light dengan variabel css khusus

Tujuannya adalah untuk mengurangi waktu pemblokiran / utas utama / apa pun yang terkait dengan js, karena sekarang css tidak lagi dievaluasi saat runtime tetapi dikompilasi pada waktu pembuatan (sebenarnya linaria tampaknya jauh lebih selaras dengan gatsby pernyataan daripada @emotion dalam hal ini)

Prosesnya tidak sepenuhnya mulus, sebagian besar hal yang saya lakukan dengan @emotion hanya bekerja dengan linaria , tetapi beberapa yang lain tidak dan Anda harus menulis ulang dan / atau menerapkannya kembali melalui custom css variabel

Pengalaman DX dengan gatsby adalah __bad__, hot reload tidak berfungsi (Anda harus berhenti dan memulai lagi jika ada perubahan karena browser sepertinya kehilangan koneksi), tetapi secara keseluruhan prosesnya bagus karena memaksa Anda untuk lebih berhati-hati tentang apa yang benar-benar Anda perlukan dari kemampuan runtime @emotion

__Apa yang dikatakan, metrik mercusuar sangat mirip__

Saya dapat membandingkan dua penyebaran netlify dan sebenarnya situs @emotion memiliki 70-an tinggi dan situs linaria memiliki 70-an rendah-menengah

Tak perlu dikatakan, saya tidak terlalu bersemangat

Menganalisis bundel:

• dokumen situs telah meningkat dari 14 Kb menjadi 28 kb
• skrip kerangka tetap identik pada 38,7 kb
• Skrip aplikasi telah berkurang dari 58,2 kb menjadi 46,1 kb
• Dan skrip keempat ( component--content.. . Lalu, 20bae078.. sekarang) telah berubah dari 44.2 kb menjadi 46.8 kb

Jadi saya berasumsi bahwa gaya di js telah pindah ke gaya di css (dan ~ 12 kb adalah IMO yang signifikan), tetapi ini tidak berdampak nyata dalam metrik mercusuar (dan inilah yang penting, bukan?)

Jadi, saya sama sekali tidak mengatakan bahwa pindah ke linaria tidak masuk akal, saya tidak akan terkejut jika seseorang melakukan hal yang sama dan memiliki hasil yang lebih baik (secara teori seharusnya demikian (?)), tetapi di tangan saya, proses tersebut tidak sepadan

Namun, menjelajahi skrip aplikasi saya telah membuka masalah baru mencoba mencari cara untuk mengurangi js bundel https://github.com/gatsbyjs/gatsby/issues/26655

Pengalaman DX dengan gatsby buruk , hot reload tidak berfungsi (Anda harus berhenti dan memulai lagi pada setiap perubahan karena browser tampaknya kehilangan koneksi), tetapi secara keseluruhan prosesnya bagus karena memaksa Anda untuk lebih berhati-hati tentang apa yang benar-benar Anda perlukan dari kemampuan runtime @emotion

@kuworking Saya mengalami masalah serupa, tetapi perhatikan bahwa itu hanya terjadi pada gatsby versi yang lebih baru dari 2.24.9 ; Tidak yakin apakah penyebabnya sama, tapi saya pikir itu mungkin membantu seseorang mengetahui bahwa orang-orang membicarakannya di edisi # 26192 .

@kuworking Saya mengalami masalah serupa, tetapi perhatikan bahwa itu hanya terjadi pada gatsby versi yang lebih baru dari 2.24.9 ; Tidak yakin apakah penyebabnya sama, tapi saya pikir itu mungkin membantu seseorang mengetahui bahwa orang-orang membicarakannya di edisi # 26192 .

Saya telah dengan "gatsby": "2.24.14" selama beberapa minggu, menurut saya, dan sejauh ini saya hanya mengalami ini dengan linaria
Tetapi mengetahui hal ini, saya tidak akan memperbarui gatsby sampai ini diketahui, terima kasih 👍

@kuworking Yang ingin saya sarankan adalah mungkin jika Anda menurunkan versi ke 2.24.9 maka masalah penghentian server pengembangan tidak akan terjadi bahkan dengan linaria ; tapi itu hanya sebuah ide. Saya ingin tahu apakah itu masalahnya.

Pengalaman DX dengan gatsby buruk , hot reload tidak berfungsi (Anda harus berhenti dan memulai lagi pada setiap perubahan karena browser tampaknya kehilangan koneksi), tetapi secara keseluruhan prosesnya bagus karena memaksa Anda untuk lebih berhati-hati tentang apa yang benar-benar Anda perlukan dari kemampuan runtime @emotion

Sudahkah Anda mencoba penyegaran cepat ?

Saya baru-baru ini memigrasi situs gatsby produksi (~ 120 halaman) untuk melakukan preact dengan harapan dapat meningkatkan TBT & LCP. Situs kami adalah svg heavy menggunakan komponen react svg yang dihasilkan dengan svgr dan ditata menggunakan gaya material-ui. Hasil kinerja rata-rata berada di kisaran + -5 dari skor awal (~ 45 kinerja seluler turun dari ~ 85 sebelum v6) dan meskipun migrasi relatif tidak menyakitkan menggunakan tema, itu memang membutuhkan migrasi ke penyegaran cepat yang sebelumnya tidak.

Jujur saja, saya sedikit kecewa karena tidak ada pengoptimalan lain yang dapat saya temukan untuk dicoba atau metrik yang lebih detail untuk dimatikan selain peringatan mercusuar "Hapus javascript yang tidak terpakai" generik.

Kecepatan adalah salah satu alasan utama kami memilih gatsby dan meskipun halaman masih cepat dimuat, sulit untuk dibenarkan dari sudut pandang SEO ketika skor wawasan Anda sangat terpukul ...

berbisik: Saya beralih ke NextJS dan saya mendapatkan skor yang lebih baik 🤭

berbisik: Saya beralih ke NextJS dan saya mendapatkan skor yang lebih baik 🤭

Bagaimana dengan Svelte?

Akan lebih baik untuk mengetahui apakah Gatsby devs memberikan rasa penting / prioritas khusus ini dalam peta jalan (selain yang diharapkan), karena saya berasumsi bahwa tidak ada solusi langsung tetapi mungkin semacam arah dan implementasi masa depan yang difokuskan pada ini atau itu

Karena gatsby melakukan kompilasi dengan gatsby-node *, saya bertanya-tanya apakah mereka mencari cara untuk meningkatkan bagian itu dan memanfaatkan bagian klien

* Untuk mengurangi pageContext yang saya gunakan (data tentang semua posting yang diterbitkan), saat ini saya menyimpan (melalui gatsby-node ) sebagian besar data itu dalam json file dan mengambilnya jika diperlukan dari situs, yang mengurangi ukuran paket tetapi juga terasa lebih logis

Jangan terlalu terpaku pada skor mercusuar - terutama saat itu
dimaksudkan sebagai tolok ukur versus situs lain, dan bukan tujuan yang seharusnya
berusaha keras untuk mencapai nilai sempurna.

Baru belakangan ini gatsby berhasil mencapai 100-an murni - tentu saja, di sana
adalah beberapa masalah yang harus diatasi tetapi permainan SEO saat ini adalah kecepatan plus konten
plus tautan, dan kami telah menutupinya.

Dua sen saya.

Pada Jum, 28 Agustus 2020, 16:57 kuworking, [email protected] menulis:

berbisik: Saya beralih ke NextJS dan saya mendapatkan skor yang lebih baik 🤭

Bagaimana dengan Svelte?

Akan sangat baik untuk mengetahui apakah Gatsby devs memberikan beberapa hal yang spesifik
rasa pentingnya / prioritas dalam peta jalan (selain yang diharapkan
satu), karena saya berasumsi bahwa tidak ada solusi langsung, tetapi mungkin beberapa
jenis arah dan implementasi masa depan yang difokuskan pada ini atau itu

Karena gatsby melakukan kompilasi dengan gatsby-node *, saya bertanya-tanya apakah mereka
sedang mencari cara untuk meningkatkan bagian itu dan memanfaatkan bagian klien

* Untuk mengurangi pageContext yang saya gunakan (data tentang semua
posting yang diterbitkan), saat ini saya paling banyak menyimpan (melalui gatsby-node)
dari data tersebut dalam file json dan mengambilnya jika diperlukan dari situs,
yang mengurangi ukuran bundel tetapi juga terasa lebih logis

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-682664232 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ALSIKRHQUIKR5YO6OGA3DC3SC7AWPANCNFSM4NHP7XCA
.

Maaf atas tanggapan yang terlambat, ada banyak hal yang masuk ke metrik kinerja dan beban hanyalah sebagian kecil dari teka-teki. Kami termotivasi di kuartal ini dan berikutnya untuk membuat Gatsby lebih kecil dan mengurangi TBT. Masalah terbesar saat ini adalah ukuran paket React, MDX, halaman besar (konten / gaya), skrip pelacakan dan font / gambar sebagai konten utama pada pemuatan pertama.

Saat ini saya sedang mempelajari skrip gatsby-image & analytics untuk melihat bagaimana kami dapat meningkatkan waktu muat dan menunda analitik.

Sayangnya, saya tidak bisa memberikan perkiraan apapun. Kami juga melihat situs .com kami dan pelanggan kami untuk melihat apa masalah umumnya sehingga kami dapat membuat pengoptimalan ini ke dalam gatsby atau di plugin kami.

Edit:

Saya senang melihat salah satu kode sumber Anda untuk mendapatkan lebih banyak wawasan tentang apa yang Anda semua lakukan untuk melihat bagaimana kami dapat meningkatkannya.

Saya membuat posting reddit di mana saya mencoba mengumpulkan semua tip peningkatan yang dapat saya temukan. Jika Anda dapat memperoleh lebih banyak tip, harap buat daftar

Menghapus hanya gatsby-image (

Dalam beberapa pengujian baru-baru ini yang saya lakukan, saya menemukan bahwa menggunakan tracedSVG sebenarnya secara dramatis meningkatkan skor kinerja Largest Contentful Paint. Saya membayangkan ini akan diperbaiki di Lighthouse, tetapi mulai sekarang ini terjadi karena SVG dianggap memiliki dimensi yang sama dengan gambar resolusi penuh, jadi tidak pernah bertukar dari SVG sebagai target LCP ke gambar penuh.

Saat menggunakan base64, resolusi kecil membuatnya bukan kandidat untuk LCP sehingga Lighthouse menggunakan gambar resolusi penuh setiap kali memuatnya.

Jadi jika Anda tidak keberatan dengan tampilan SVG yang dilacak (saya lebih suka mereka secara pribadi), Anda mungkin ingin mencobanya.

Mengapa v5 lebih baik dari pada v6? Saya menggunakan NextJS, hasilnya selalu berubah dari 60 menjadi 85.

+1

Saya telah mengerjakan penerus gatsby-image. Belum 100% di sana, masih perlu menulis versi yang dapat disusun sehingga Anda dapat membuat rasa gambar gatsby Anda sendiri tetapi itu akan memperbaiki sebagian besar skor mercusuar yang buruk.

Anda sudah dapat menggunakannya tetapi ini belum diuji dalam pertempuran.
https://github.com/wardpeet/gatsby-image-nextgen/tree/main/gatsby-image

Anda dapat menginstalnya dengan npm install --save @wardpeet/gatsby-image-nextgen . Ada lapisan compat untuk pengguna gatsby-image saat ini .

Hal-hal yang belum didukung:

• object-fit perlu dilakukan oleh css di luar komponen
• arah seni

Demo gambar gatsby saat ini:
situs: https://wardpeet-using-gatsby-image.netlify.app/
pagespeed-insights: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwardpeet-using-gatsby-image.netlify.app%2F
webpagetest: https://webpagetest.org/result/200928_4M_0879160e38bb6c5489f85534de2dd197/

Demo gatsby-image-nextgen baru:
situs: https://gatsby-image-nextgen.netlify.app/
pagespeed-insights: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fgatsby-image-nextgen.netlify.app%2F
webpagetest: https://webpagetest.org/result/200928_C0_63317160bdfc71ece1a2057df8b08133/

@wardpeet Tautan pagespeed-insights Anda untuk demo saat ini mengarah ke nextgen sehingga menunjukkan skor yang sama.
Kerja yang luar biasa, btw. Sungguh menyenangkan melihat kemajuan.

Terima kasih sudah diperbaiki!

Pembaruan ini menunjukkan sesuatu kepada saya bahwa saya tidak terhubung sebelumnya, saya tidak menggunakan gatsby-image tetapi sebenarnya gatsby-background-image yang tampaknya tidak menggunakan gatsby-image bawah tenda ... Saya mungkin harus menulis ulang komponen itu dengan @wardpeet/gatsby-image-nextgen jika memungkinkan ....

Artikel ini mencantumkan beberapa tip tambahan https://www.freecodecamp.org/news/gatsby-perfect-lighthouse-score/ meskipun saya pikir banyak dari mereka telah disebutkan di utas ini ...

@DannyHinshaw saat fitur plugin sudah selesai. Saya akan melihat plugin itu juga. Saya harus melihat gambar komentar juga

Saya telah menerbitkan versi baru @wardpeet/gatsby-image-nextgen - 0.0.2.

1. memperkecil css & js di html
2. hanya memuat bit yang diperlukan, saat pemuatan gambar asli diaktifkan, kami hanya memuat sekitar 2kb (tanpa gzip).
3. pastikan placeholder hanya dipanggil saat pemuatan pertama, gambar yang disimpan dalam cache akan segera dimuat
4. Perbaiki animasi blur-up dengan mendekode asinkron

Saya bertanya-tanya berapa banyak dari Anda yang membutuhkan komponen Image yang dapat disusun di mana Anda dapat membuat pembungkus Anda sendiri dan berapa banyak dari Anda yang benar-benar menggunakan art-direction dan menginginkannya di dalam gatsby-image secara default? Ide pertama saya adalah menonaktifkan fungsionalitas tetapi mengaktifkannya dengan gatsby-image yang dapat disusun sehingga Anda harus membuat komponen gambar Anda sendiri untuk mendukungnya.

Demo terbaru: https://gatsby-image-nextgen.netlify.app/

@wardpeet Ini bagus! Saya sangat bergantung pada art-direction bawaan gatsby-image. Tapi saya rasa contoh / jalur peningkatan yang mulus juga akan baik-baik saja!

Saya selalu menerima 99 di ponsel sekarang menjadi 76. Semuanya bagus kecuali LCP saya 7.0s dan dikatakan itu gambar pahlawan saya. Tidak masuk akal. Saat saya membuka situs saya di ponsel mana pun, situs itu sangat cepat. Orang-orang kagum ya tahu? Ia juga memberitahu saya untuk memasukkan gambar saya ke webp atau yang lain, tapi saya sudah menggunakan childImageSharp_withWebp jadi saya tidak mengerti. Saya mulai berpikir bahwa Gastby Image dan background-image tidak berfungsi dengan versi baru ini di lighthouse dan pagespeedinsight. Pikiranku bingung. Saya pergi dan mematikan animasi, mengubah ukuran semua gambar saya setengahnya dan itu tidak bergerak satu titik pun. Saya membaca ini dan tidak melihat apa pun untuk membantu saya .... Oh, saya baru saja melihat ke atas ... Saya pikir @wardpeet saya menjadi sesuatu 👍🏻

Pikiran @davidpaulsson berbagi contoh tentang bagaimana Anda melakukan ini? Penyebab art-direction masih dimungkinkan dengan gatsby-image baru, Anda harus melakukan beberapa langkah manual.

Pikiran @davidpaulsson berbagi contoh tentang bagaimana Anda melakukan ini? Penyebab art-direction masih dimungkinkan dengan gatsby-image baru, Anda harus melakukan beberapa langkah manual.

Tentu! Saya menggunakannya seperti ini saat ini

const artDirection = [
  medium.childImageSharp.fluid,
  {
    ...large.childImageSharp.fluid,
    media: `(min-width: 1390px)`,
  },
];

return <Img fluid={artDirection} />

@wardpeet Hai. Bisakah blurha.sh berguna untuk gambar

@wardpeet Saya menggunakan plugin

Namun, kami juga menggunakan art-direction, mirip dengan cara @davidpaulsson menggunakannya, dan sepertinya saya tidak bisa membuatnya berfungsi seperti pada gatsby-image.

Bisakah Anda menguraikan langkah-langkah manual yang diperlukan untuk memungkinkan hal ini dengan plugin nextgen? Terima kasih lagi!

@Jimmydalecleveland Terima kasih Jimmy! Mengganti GatsbyImageSharpFluid_withWebp dengan GatsbyImageSharpFluid_withWebp_tracedSVG secara dramatis meningkatkan skor kinerja Gatsby Webiste baru saya. Saya mendapatkan tidak lebih dari 54% dan sekarang dengan tracedSVG saya mendapatkan lebih dari 80%. Itu peningkatan besar 💯

Dalam beberapa pengujian baru-baru ini yang saya lakukan, saya menemukan bahwa menggunakan tracedSVG sebenarnya secara dramatis meningkatkan skor kinerja Largest Contentful Paint. Saya membayangkan ini akan diperbaiki di Lighthouse, tetapi mulai sekarang ini terjadi karena SVG dianggap memiliki dimensi yang sama dengan gambar resolusi penuh, jadi tidak pernah bertukar dari SVG sebagai target LCP ke gambar penuh.

Saat menggunakan base64, resolusi kecil membuatnya bukan kandidat untuk LCP sehingga Lighthouse menggunakan gambar resolusi penuh setiap kali memuatnya.

Jadi jika Anda tidak keberatan dengan tampilan SVG yang dilacak (saya lebih suka mereka secara pribadi), Anda mungkin ingin mencobanya.

@abdullahe Kami telah memeriksanya sebelumnya dan ini memiliki ketergantungan pada kanvas dan node-kanvas tidak terlalu dapat diandalkan. Atau setidaknya tidak di masa lalu. Saya akan memberi tahu Anda jika kami mempertimbangkannya lagi :)

@guydumais pastikan untuk memasukkan loading="eager" itu akan mengubah skor Anda juga.

@BenjaminSnoha & @davidpaulsson Saya akan membagikan contoh sebentar lagi. Masalah terbesar dengan art-direction jika rasio aspek antara gambar berubah, seperti horizontal ke vertikal.

@wardpeet bagaimana cara menggunakan @wardpeet/gatsby-image-nextgen dengan gatsby-remark-images ? Apakah ini kasus hanya dengan menunjuknya sebagai plugin di gatsby-config.js , atau tidak mungkin sampai digabungkan ke dalam monorepo gatsby?

sementara ini mungkin tidak ada hubungannya dengan mercusuar, saya bertanya-tanya mengapa file JSON data halaman gatsby tidak mendukung hashing konten, seperti file js.

Saya tahu bahwa hashing konten untuk file js dilakukan oleh Webpack, tetapi gatsby juga dapat melakukan hal yang sama untuk file JSON data halaman. ini dapat menghemat banyak permintaan jaringan cdn

File @teclone page-data.json tidak boleh diunduh berulang kali jika caching Anda diatur dengan benar. Mereka akan memuat sekali dan kemudian browser memvalidasinya kembali. Masalah dengan hashing konten untuk data halaman (vs file JS / CSS) hanya karena jumlahnya sangat banyak. Dengan hashing konten, sebelum Anda dapat memuat file, Anda perlu memuat manifes yang diterjemahkan dari x menjadi x.LONG_HASH karena hash tidak dapat diprediksi. Dengan JS / CSS, memuat manifes masuk akal karena hanya ada begitu banyak file JS bahkan di situs yang sangat besar. Tetapi dengan data halaman, ada satu data per halaman sehingga manifes bisa bertambah besar. Kami biasa melakukan ini dan kami menemukan di situs 10k halaman, manifes sudah ~ 500k dikompresi. https://github.com/gatsbyjs/gatsby/pull/13004

Jika Anda melihat file halaman-data.json diunduh berulang kali - periksa apakah Anda belum menonaktifkan caching di alat pengembang Anda & periksa tajuk caching Anda dengan https://www.npmjs.com/package/check-gatsby-caching

@KAMews , terima kasih telah mengklarifikasi hal itu. Itu adalah pendekatan yang sangat masuk akal

@wardpeet apakah benar image-nextgen tidak mendukung fadeIn="false" atau fadeIn="{false}"

Ini bekerja jauh lebih baik, pergi dari ~ 80 menjadi ~ 95

@MelleNi tidak, saya rasa itu tidak perlu tapi kami senang mempertimbangkannya.

Anda dapat melihat di https://github.com/gatsbyjs/gatsby/discussions/27950 untuk melihat apa yang kami kirim.

@wardpeet bagaimana cara menggunakan @wardpeet/gatsby-image-nextgen dengan gatsby-remark-images ? Apakah ini kasus hanya dengan menunjuknya sebagai plugin di gatsby-config.js , atau tidak mungkin sampai digabungkan ke dalam monorepo gatsby?

Kami juga akan memindahkan komentar ke plugin ini :)

@MelleNi tidak, saya rasa itu tidak perlu tapi kami senang mempertimbangkannya.

Anda dapat melihat # 27950 untuk melihat apa yang kami kirim.

@wardpeet bagaimana cara menggunakan @wardpeet/gatsby-image-nextgen dengan gatsby-remark-images ? Apakah ini kasus hanya dengan menunjuknya sebagai plugin di gatsby-config.js , atau tidak mungkin sampai digabungkan ke dalam monorepo gatsby?

Kami juga akan memindahkan komentar ke plugin ini :)

Senang mendengar tentang komentar, karena saya melihat banyak peningkatan dalam kecepatan.

Namun, saya perhatikan saya tidak bisa mendapatkan 99-100 tanpa menonaktifkan javascript Gatsby (dan mengintegrasikan kembali fungsi tertentu secara manual). Saya bisa mendapatkan gambar Gatsby lama untuk bekerja tanpa javascript, menggunakan fadeIn={false} , tetapi tidak image-nextgen. (Mungkin saya melewatkan sesuatu, dan itu benar-benar mungkin?) Sekarang tanpa javascript saya tidak pernah turun di bawah 99 tanpa nextgen.

Saya mengerti bahwa menonaktifkan jenis javascript mengalahkan gagasan Gatsby, tapi oh well.

Menariknya, saya melihat peningkatan pada skor kinerja seluler (~ 70 hingga ~ 90) ketika saya berhenti menggunakan font yang dihosting sendiri (sumber font) dan beralih ke font "sistem".

@wardpeet Adakah kesempatan Anda berbagi contoh tentang cara membuat komponen gambar yang dapat disusun dengan arah seni? Saya berada di perahu yang sama dengan @BenjaminSnoha & @davidpaulsson , dan saya tidak keberatan membuat komponen yang dapat disusun dalam proyek saya sendiri.

Masalah terbesar yang saya lihat adalah menangani pertanyaan media dan SSR. Pustaka seperti fresnel berfungsi, tetapi kinerjanya buruk karena memuat semua komponen, kemudian membersihkan DOM setelah komponen window tersedia.

Di situs web saya, tampaknya semua halaman yang dibuat dengan createPage memiliki kode sumber (komponen reaksi markdown dan penurunan harga di dalam penurunan harga) di javascript berat pagespeed (Hapus JavaScript yang tidak digunakan)

Saya baru saja meluncurkan Plaiceholder yang dapat digunakan untuk membuat placeholder kabur CSS murni . Mungkin ini akan menarik? Lebih dari senang untuk mengobrol dengan salah satu tim inti tentang opsi ke depan

Saya membuat versi Next.js dari Jamify Blog Starter yang mendapat skor bagus dengan Lighthouse 6.4.0 terbaru:

Anda dapat memeriksa situs demo di next.jamify.org .

Saya memposting ini di sini, BUKAN untuk menyarankan Anda beralih ke Next.js. Sebaliknya, untuk mempelajari bagaimana hal yang sama dapat dicapai dengan Gatsby. Menurut saya, faktor kunci suksesnya adalah:

• gambar yang sangat dioptimalkan (Selanjutnya mencapai ini dengan pengoptimal lambda, tetapi ini juga dapat dilakukan dengan gatsby-plugin-sharp).
• svg placeholder sederhana (efek bagus seperti blur akan memperlambat halaman).
• penggunaan pengamat persimpangan untuk hanya menampilkan gambar ketika dalam tampilan (lihat / gambar berikutnya).
• memastikan pemuatan gambar yang lambat.
• ukuran bundel kecil.

Jika Anda ingin membahas ini lebih lanjut, Anda dapat menghubungi saya di twitter .

@styxlab Saya mendapatkan hasil yang sedikit lebih rendah di web.dev/measure

tetapi lebih baik dalam hasil posting, nilai pasti sangat bagus dalam hal apapun dan sangat berbeda dari versi gatsby https://demo.jamify.org/

Saya juga akan memposting bahwa di satu situs saya telah mengubah gatsby 11ty , dan kinerjanya telah meningkat tetapi tidak secara dramatis

(gatsby)

(desain berbeda, konten dasarnya sama, 11ty)

Atau di halaman serupa, kali ini dengan gambar

(gatsby)

(desain berbeda, konten dasarnya sama, 11ty)

Saya akan mengatakan bahwa 11ty pengalaman pengembang sangat bagus (Anda juga dapat - secara eksperimental menggunakan jsx dan styled-components ), tetapi js di sisi klien hilang (Anda dapat memasukkannya dan bertarung dengan webpack, saat itulah Anda merindukan gatsby)

Ketika saya menggunakan 11ty, saya juga berpikir betapa menyenangkannya gatsby mengaktifkan semacam strategi render 11ty sehingga seseorang dapat menyebarkan halaman statis yang bereaksi dan tidak bereaksi dalam satu kerangka kerja ...

ada pembaruan tentang ini? Saya tidak memiliki gambar apa pun dan saya mendapatkan performa 76 karena Total Blocking Time