Cara Buat Laman Web Anda Lebih Pantas: Senarai Semak Praktikal

Untuk membuat laman web lebih pantas, ukur dahulu dengan PageSpeed Insights, kemudian betulkan punca terbesar yang ditunjukkannya — biasanya imej yang terlalu besar, JavaScript yang terlalu banyak, fon yang berat atau skrip pihak ketiga. Sasarkan sasaran "baik" Core Web Vitals Google: kandungan utama kelihatan dalam 2.5 saat, respons kepada ketikan dalam 200 milisaat, dan hampir tiada susun atur yang melompat. Kebanyakan laman sampai ke sana dengan beberapa perubahan kecil, bukan penulisan semula.

Ukur sebelum anda mengubah apa-apa

Meneka membuang masa. Dua alat percuma meliputi hampir semua orang:

• PageSpeed Insights (pagespeed.web.dev) — tampal URL langsung. Ia menunjukkan data lapangan daripada pengguna Chrome sebenar (jika laman anda mempunyai trafik yang mencukupi) dan data makmal daripada muatan simulasi, serta senarai masalah tertentu.
• Lighthouse dalam Chrome DevTools — ujian makmal yang sama, dijalankan pada mana-mana halaman yang boleh anda buka, termasuk pratonton. Uji dalam mod mudah alih; telefon pada rangkaian yang lebih perlahan ialah tempat masalah kelihatan.

Nombor yang penting ialah Core Web Vitals Google. Setakat September 2026, dokumentasi Google di web.dev memberikan ambang "baik" ini, diukur pada persentil ke-75 muatan halaman:

INP menggantikan metrik First Input Delay yang lebih lama pada 2024. Jika sesuatu alat masih melaporkan FID, ia sudah lapuk.

Catat nombor permulaan anda. Selepas setiap pembetulan, uji semula supaya anda tahu apa yang membantu.

Masa pergi ke mana: pilihan dan pertukaran

Setiap punca biasa ada pembetulan, dan setiap pembetulan ada kosnya. Mulakan dengan yang di atas — ia paling murah dan paling biasa.

Imej

Imej ialah masalah yang paling biasa dan yang paling mudah dibetulkan. Foto 4,000 piksel yang dipaparkan pada 800 piksel memaksa setiap pelawat memuat turun lima kali ganda lebih banyak daripada yang mereka lihat.

• Hidangkan imej pada saiz yang dipaparkan, dengan saiz srcset responsif untuk telefon dan desktop.
• Gunakan format moden (WebP atau AVIF) dan mampatan yang munasabah.
• Tetapkan width dan height pada setiap imej supaya pelayar menempah ruang. Ini sahaja membetulkan kebanyakan anjakan susun atur.
• Lazy-load imej di bawah lipatan dengan loading="lazy".
• Jangan sekali-kali lazy-load imej utama di bahagian atas halaman. Panduan LCP Google jelas tentang ini: lazy-load imej LCP sentiasa melambatkannya. Berikan fetchpriority="high" sebaliknya.

JavaScript

Banyak laman yang dibina AI ialah aplikasi satu halaman (SPA): pelayar memuat turun bundle JavaScript dan kemudian melukis halaman. Semakin besar bundle, semakin lama skrin kosong. Pembetulannya, mengikut urutan usaha:

1. Buang apa yang anda tidak gunakan. Minta senarai kebergantungan dan potong pustaka yang pernah ditambah lalu dilupakan — pustaka tarikh untuk satu tarikh, pek ikon penuh untuk lima ikon.
2. Pisahkan mengikut laluan. Muatkan kod papan pemuka pentadbir hanya apabila seseorang membukanya, bukan pada halaman utama.
3. Prarender halaman awam. Halaman pemasaran yang dihantar sebagai HTML sebenar muncul sebelum mana-mana JavaScript dijalankan. Ini juga membantu enjin carian; lihat SEO untuk laman web yang dibina dengan AI.

INP yang perlahan biasanya bermakna satu tugas panjang menyekat halaman — menapis senarai besar pada setiap ketikan, atau merender semula seluruh jadual apabila satu sel berubah. Panel Performance dalam Chrome DevTools menunjukkan yang mana.

Fon

Setiap keluarga dan berat fon ialah satu lagi fail. Dua keluarga dan tiga atau empat berat biasanya sudah mencukupi. Pramuat fon yang digunakan di atas lipatan, gunakan font-display: swap supaya teks dipaparkan serta-merta, dan hoskan fon sendiri jika perkhidmatan fon luaran perlahan untuk pelawat anda.

Skrip pihak ketiga

Widget sembang, analitik, peta haba, piksel iklan, video terbenam dan suapan sosial semuanya memuatkan kod dari pelayan lain. Setiap satu kelihatan kecil; bersama-sama selalunya ia bahagian halaman yang paling perlahan. Simpan yang benar-benar anda lihat. Muatkan yang lain selepas halaman itu interaktif, dan gantikan embed yang berat (pemain YouTube, peta) dengan pratonton ringan yang memuatkan yang sebenar apabila diklik.

Respons pelayan

Time to First Byte (TTFB) — berapa lama pelayan mengambil masa untuk mula menjawab — terletak di bawah setiap metrik lain. Halaman statik yang dihidangkan dari CDN (rangkaian pelayan yang dekat dengan pelawat anda; lihat apa itu CDN) pantas hampir di mana-mana. Halaman yang dibina oleh pelayan pada setiap permintaan bergantung pada pelayan itu dan pangkalan datanya. Caching untuk kerja yang berulang dan menambah indeks pangkalan data untuk pertanyaan yang perlahan ialah pembetulan biasa.

Prompt yang berfungsi

Jadilah spesifik: namakan halaman, metrik dan kekangan. Tampal penemuan PageSpeed Insights jika anda ada.

PageSpeed Insights melaporkan LCP 4.8 s pada mudah alih untuk halaman utama, dan elemen LCP ialah imej hero. Ubah saiz dan tukar imej hero kepada WebP, hidangkan saiz responsif, tetapkan width dan height, berikan fetchpriority="high" dan pastikan ia tidak di-lazy-load. Lazy-load setiap imej di bawah lipatan. Jangan ubah reka bentuk.

Audit kebergantungan aplikasi ini. Senaraikan setiap pakej, apa yang menggunakannya dan kira-kira berapa ia menambah kepada bundle. Buang yang tidak digunakan dan pisahkan laluan /admin dan /settings kepada cebisan berasingan yang hanya dimuatkan apabila dilawati.

Kotak carian pada /products terasa lambat. Debounce penapis, elakkan merender semula seluruh senarai pada setiap ketikan, dan paginate atau virtualisasikan senarai jika ia mempunyai lebih daripada 200 item.

Langkah demi langkah

1. Uji halaman langsung dalam PageSpeed Insights pada mudah alih. Catat LCP, INP dan CLS, serta tiga masalah teratas yang disenaraikan.
2. Betulkan imej dahulu: saiz, format, dimensi, lazy loading di bawah lipatan, keutamaan untuk hero.
3. Potong skrip pihak ketiga yang tidak anda gunakan, dan tangguhkan yang lain.
4. Kurangkan fon kepada apa yang diperlukan reka bentuk.
5. Kecilkan JavaScript: buang pakej yang tidak digunakan, pisahkan mengikut laluan.
6. Prarender halaman awam jika ia masih dirender pada klien dan LCP masih perlahan.
7. Semak pelayan: caching, indeks pangkalan data, hosting statik untuk kandungan yang jarang berubah.
8. Terbitkan semula dan uji semula. Data lapangan dalam PageSpeed Insights dikemas kini sepanjang minggu berikutnya apabila lawatan sebenar masuk, jadi nilai hasil awal berdasarkan data makmal.

Kesilapan biasa

• Menguji hanya pada komputer riba yang pantas. Pelawat anda berada pada telefon pertengahan dan data mudah alih yang tidak stabil. Uji dalam mod mudah alih.
• Mengejar 100 yang sempurna. Skor makmal ialah panduan. Apabila Core Web Vitals berada dalam julat baik, kandungan dan kebolehgunaan lebih penting daripada beberapa mata terakhir.
• Lazy-load segala-galanya, termasuk imej hero. Itu menjadikan LCP lebih teruk.
• Menambah pemalam atau pustaka kelajuan di atas. Membuang berat hampir selalu mengalahkan menambah kod untuk mengurusnya.
• Mengoptimumkan pratonton, bukan laman langsung. Pratonton pembangunan menjalankan binaan yang tidak dioptimumkan. Ukur URL yang diterbitkan.
• Membetulkan kelajuan sekali sahaja. Setiap widget, imej dan ciri baharu menambah berat. Uji semula selepas perubahan besar.

Senarai semak kelajuan

• LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1 pada mudah alih
• Imej diubah saiz, dimampatkan, format moden, dengan width dan height
• Imej hero tidak di-lazy-load; imej di bawah lipatan di-lazy-load
• Tiada pustaka JavaScript yang tidak digunakan; laluan berat dipisahkan
• Dua keluarga fon atau kurang, fon utama dipramuat
• Hanya skrip pihak ketiga yang anda gunakan, dimuatkan lewat
• Halaman awam diprarender atau statik jika boleh
• Diuji semula pada URL langsung selepas diterbitkan

Kelajuan dan susun atur mudah alih berjalan seiring; lihat cara membuat laman web responsif untuk mudah alih. Untuk semakan pra-pengeluaran yang menyeluruh, cara membawa prototaip AI ke pengeluaran meliputi baki langkahnya.

Kelajuan di Mythex

Di Mythex, anda membuat perubahan ini dengan meminta dalam sembang, atau dalam editor kod pada Pro. Semak URL yang diterbitkan, bukan Pratonton, kerana Pratonton menjalankan pelayan pembangunan. Frontend statik digunakan sebagai laman statik apabila anda menerbitkan (laman web statik), yang sesuai untuk halaman kandungan. Apl dengan pelayan akan skala ke sifar: ia tidur apabila tidak aktif dan bangun pada lawatan seterusnya, jadi permintaan pertama selepas tempoh senyap lebih perlahan, dan pangkalan data yang dilampirkan tidur selepas 5 minit tidak aktif (had hosting). Jika halaman awam hanya perlahan pada lawatan pertama, itu punca yang mungkin. Mengekalkan halaman pemasaran sebagai statik membantu. Selepas perubahan, terbitkan semula dan muat semula dengan paksa (hard refresh).

Soalan lazim