Core Web Vitals Landing Page AMP: Optimasi LCP, INP dan CLS Tanpa Merusak Conversion

Core Web Vitals landing page AMP sebaiknya tidak dioptimalkan hanya untuk mendapatkan angka hijau di PageSpeed Insights. Landing page tetap memiliki tugas utama: menyampaikan penawaran, memuat hero section, menyediakan CTA, menjalankan analytics, merekam conversion, serta tetap nyaman digunakan melalui perangkat mobile.

Masalahnya, seluruh elemen tersebut dapat memengaruhi performa.

Hero image yang terlalu berat dapat memperburuk LCP. JavaScript dan tracking yang berlebihan dapat meningkatkan waktu respons interaksi. Sementara itu, banner, font, form, widget, dan komponen yang muncul terlambat dapat menyebabkan layout bergeser.

Google saat ini menggunakan tiga Core Web Vitals utama: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), dan Cumulative Layout Shift (CLS). Untuk pengalaman yang dikategorikan baik, Google menyarankan LCP dalam 2,5 detik, INP di bawah 200 milidetik, dan CLS di bawah 0,1.

Namun, jangan salah memahami angka tersebut.

Google juga menegaskan bahwa Core Web Vitals digunakan oleh ranking systems, tetapi mendapatkan skor bagus di Search Console atau tool pihak ketiga tidak menjamin halaman berada di posisi teratas. Bahkan mengejar perfect score semata-mata demi SEO belum tentu menjadi penggunaan waktu yang paling efektif.

Karena itu, framework yang lebih tepat adalah:

Fast Loading → Responsive Interaction → Stable Layout → Clear CTA → Measurement → Conversion

Tujuannya bukan hanya menghasilkan halaman cepat, tetapi landing page yang cepat dan tetap bekerja untuk bisnis.

Mengapa Core Web Vitals Penting untuk Landing Page AMP?

Landing page mempunyai karakter berbeda dibanding artikel informasi biasa.

Biasanya terdapat elemen seperti hero image, headline besar, form, CTA, sticky button, tracking pixel, analytics, testimonial, accordion FAQ, video, ataupun third-party widget.

Semua elemen tersebut membantu conversion. Namun, jika implementasinya salah, elemen yang sama dapat menurunkan page experience.

Google menjelaskan bahwa Core Web Vitals mengukur pengalaman pengguna nyata berdasarkan loading performance, responsiveness, dan visual stability. Selain itu, Google menyarankan pemilik website mengevaluasi page experience secara menyeluruh, bukan hanya satu atau dua indikator.

Oleh karena itu, pendekatan untuk landing page AMP sebaiknya bukan:

Hapus semua elemen sampai PageSpeed menjadi 100.

Pendekatan yang lebih masuk akal:

Pertahankan elemen yang membantu conversion, tetapi kurangi biaya performance-nya.

Untuk framework technical SEO yang lebih luas, artikel ini perlu terhubung ke #1 – SEO Landing Page AMP.

Target Core Web Vitals yang Perlu Dipahami

Gunakan tiga target utama berikut:

LCP ≤ 2,5 detik untuk loading performance.

INP < 200 ms untuk responsiveness.

CLS < 0,1 untuk visual stability.

Namun pengukuran Core Web Vitals tidak hanya berdasarkan satu kali tes Lighthouse.

PageSpeed Insights menggunakan data lapangan atau field data ketika tersedia dan menilai Core Web Vitals berdasarkan persentil ke-75 pengalaman pengguna. Untuk sebuah assessment dinyatakan lulus, seluruh metrik yang memiliki data cukup harus berada dalam kategori Good pada persentil tersebut.

Artinya:

Lighthouse = diagnosis

sementara:

Field Data = pengalaman pengguna nyata

Keduanya berguna, tetapi fungsinya berbeda.

LCP Landing Page Mulai dari Hero Section

Pada banyak landing page, elemen LCP adalah:

• hero image;
• banner utama;
• headline besar;
• background image;
• product image;
• visual promosi di viewport pertama.

Karena itu, ketika LCP landing page buruk, periksa hero section terlebih dahulu.

Google/web.dev menyarankan resource LCP dapat ditemukan langsung dari HTML dan dimuat dengan prioritas tinggi. Hero image juga tidak sebaiknya menggunakan lazy loading karena hal tersebut dapat menunda proses download resource yang justru harus tampil paling awal.

Optimalkan Hero Image AMP

Dalam AMP, gambar biasanya menggunakan:

<amp-img
  src="/images/hero.webp"
  width="1200"
  height="675"
  layout="responsive"
  alt="Core Web Vitals landing page AMP">
</amp-img>

Untuk gambar hero yang penting terhadap LCP, AMP sendiri merekomendasikan preload sehingga browser dapat mulai mengambil resource lebih awal. Dokumentasi AMP juga menyediakan atribut data-hero yang dapat digunakan AMP Optimizer untuk mengenali hero image.

Contohnya:

<head>
  <link
    rel="preload"
    href="/images/hero.webp"
    as="image">
</head>

Kemudian:

<amp-img
  data-hero
  src="/images/hero.webp"
  width="1200"
  height="675"
  layout="responsive"
  alt="Core Web Vitals landing page AMP">
</amp-img>

Dengan begitu, browser tidak harus menunggu terlalu lama untuk menemukan resource utama.

Namun, jangan melakukan preload pada terlalu banyak gambar.

Bandwidth tetap terbatas. Jika semua gambar diberi prioritas tinggi, resource yang benar-benar penting justru harus berbagi bandwidth dengan elemen sekunder.

Jangan Lazy-Load LCP Image

Lazy loading berguna untuk gambar di bawah fold.

Namun berbeda dengan hero image.

Web.dev secara eksplisit memperingatkan untuk tidak menggunakan lazy loading pada LCP image karena proses tersebut menambahkan resource load delay.

Jadi:

Gambar di bawah fold

→ lazy loading bisa bermanfaat.

Hero image / LCP

→ prioritaskan loading.

Prinsipnya bukan:

Semua gambar harus lazy load.

Tetapi:

Resource yang belum dibutuhkan dapat ditunda, sementara resource terpenting harus ditemukan secepat mungkin.

Responsive Image untuk Mobile

Landing page AMP sering mendapatkan sebagian besar traffic dari perangkat mobile.

Jangan mengirim hero image desktop berukuran sangat besar ke smartphone jika tidak diperlukan.

Web.dev mencatat bahwa pengiriman gambar ukuran desktop ke mobile dapat menggunakan data 2–4 kali lebih besar daripada yang sebenarnya dibutuhkan.

Gunakan responsive image atau ukuran berbeda sesuai viewport.

Pada AMP, media query dapat digunakan untuk menyediakan visual berbeda.

Tujuannya sederhana:

desktop mendapatkan visual yang tepat, mobile juga mendapatkan resource sesuai kebutuhan.

Dengan demikian, LCP mobile tidak dibebani file yang dibuat untuk layar jauh lebih besar.

Server Response Menentukan Seberapa Cepat LCP Bisa Dimulai

Kadang-kadang developer terus mengompres hero image, tetapi LCP masih lambat.

Masalahnya ternyata berada di server.

Browser tidak dapat mulai memproses HTML sebelum server mulai memberikan respons.

Karena itu Time to First Byte atau TTFB merupakan diagnostic metric penting untuk LCP. Web.dev menyebut TTFB tinggi dapat membuat target LCP 2,5 detik menjadi sangat sulit dicapai. Sebagai rough guide, sebagian besar situs sebaiknya berusaha memperoleh TTFB sekitar 0,8 detik atau lebih rendah.

Periksa beberapa sumber delay:

DNS → connection → redirect → server processing → database → HTML response

Untuk landing page sederhana, response server seharusnya tidak membutuhkan proses backend yang sangat berat.

Caching, CDN, optimasi database, dan perbaikan backend dapat membantu mengurangi TTFB. Web.dev juga menyebut CDN sebagai salah satu pendekatan untuk mengurangi latency pada dokumen dan resource.

Font Dapat Memperlambat LCP sekaligus Memicu CLS

Font sering terlupakan.

Landing page menggunakan font khusus untuk memperkuat branding, tetapi beberapa weight dapat dimuat sekaligus:

Regular
Medium
Semi Bold
Bold
Extra Bold
Italic

Padahal tidak semuanya digunakan di viewport pertama.

Web.dev menjelaskan web font dapat menunda text rendering dan dalam beberapa kondisi memengaruhi LCP. Selain itu, perbedaan ukuran antara fallback font dan web font dapat menyebabkan layout shift sehingga CLS memburuk.

Karena itu, audit:

• berapa banyak font family;
• berapa weight;
• apakah font berasal dari third-party host;
• apakah font benar-benar digunakan;
• apakah fallback font mempunyai ukuran yang sangat berbeda;
• apakah font penting dimuat cukup awal.

Jangan mengorbankan branding tanpa alasan. Namun, jangan pula memuat enam varian font apabila landing page sebenarnya hanya menggunakan dua.

INP Landing Page Masalah Muncul ketika User Mulai Berinteraksi

LCP mengukur bagaimana halaman muncul.

INP landing page membahas apa yang terjadi ketika pengguna mulai berinteraksi.

Contohnya:

Pengguna menekan tombol CTA.

Pengguna membuka FAQ.

Pengguna mengetuk menu.

Pengguna mengisi form.

Pengguna menekan tombol WhatsApp.

Pengguna memilih paket.

Jika browser sedang sibuk menjalankan JavaScript, respons visual dapat terlambat.

Web.dev menjelaskan input delay dapat terjadi ketika main thread sedang sibuk menjalankan task lain. Long tasks dan pekerjaan JavaScript yang berat merupakan penyebab umum masalah interactivity.

Jangan Membuat CTA Cepat Hilang karena Tracking Terlalu Berat

CTA merupakan elemen conversion.

Karena itu solusinya bukan menghapus tracking.

Yang perlu dilakukan adalah mengontrol bagaimana tracking dimuat.

Misalnya tombol:

Konsultasi Sekarang

ketika diklik menjalankan sekaligus:

• analytics;
• advertising pixel;
• heatmap;
• CRM;
• session recorder;
• conversion API helper;
• custom tracking;
• third-party callback.

Jika semua proses tersebut menahan main thread sebelum UI memberikan feedback, pengguna dapat merasakan delay.

Prinsip yang lebih baik:

Interaction dahulu terasa responsif → pekerjaan non-kritis diselesaikan secara efisien sesudahnya.

Web.dev merekomendasikan mengurangi long tasks, menghindari JavaScript yang tidak perlu, dan membatasi rendering update besar untuk meningkatkan responsiveness.

Google Tag Manager dan Third-Party Scripts

Landing page commercial hampir selalu membutuhkan analytics.

Masalah biasanya muncul ketika tag bertambah tanpa audit.

Tag Manager sendiri bukan otomatis penyebab performa buruk. Namun isinya dapat menggunakan bandwidth dan CPU pada main thread.

Web.dev menjelaskan tag manager dapat memengaruhi Core Web Vitals secara tidak langsung. Tag dapat bersaing memperebutkan bandwidth pada saat critical load, menggunakan CPU untuk menjalankan JavaScript, dan bahkan menyebabkan CLS jika menyisipkan content secara dinamis.

Karena itu lakukan audit rutin.

Misalnya sebuah landing page sudah memasang:

Analytics A
Analytics B
Pixel A
Pixel B
Heatmap
Chat widget
Push notification
A/B testing
Session recorder
Affiliate tracking

Pertanyaan yang perlu diajukan bukan:

Apakah masing-masing script berguna?

Tetapi:

Apakah semuanya harus dimuat segera pada initial page load?

Sering kali jawabannya tidak.

Jangan Gunakan Tag Manager untuk Hero Image atau Elemen UX Utama

Web.dev secara khusus menyebut tag manager umumnya bukan cara ideal untuk memuat resource yang berhubungan langsung dengan tampilan atau fungsi segera, seperti hero image atau fitur UX utama, karena resource yang dipanggil dari tag manager biasanya mulai dimuat lebih lambat.

Jadi:

Hero image

jangan dimuat melalui GTM.

Main navigation

jangan bergantung pada GTM.

CTA utama

jangan membutuhkan tag manager agar baru muncul.

Gunakan tag manager terutama untuk pekerjaan analytics atau marketing yang memang sesuai.

Optimasi INP Tanpa Merusak Conversion Tracking

Jika CTA harus direkam, lakukan tracking.

Namun pastikan tracking tidak menjadi syarat agar tombol memberikan feedback kepada pengguna.

Contoh buruk secara konsep:

Klik CTA
↓
Jalankan banyak script
↓
Tunggu
↓
Baru pindah halaman

Struktur yang lebih baik:

Klik CTA
↓
Berikan respons UI
↓
Catat event secara efisien
↓
Lanjutkan navigation/conversion

Developer juga perlu mencari long task di Chrome DevTools.

Web.dev mengklasifikasikan task di main thread yang berlangsung lebih dari 50 ms sebagai long task. Long task seperti ini dapat membuat main thread tidak tersedia untuk merespons interaksi baru.

CLS AMP Landing Page Tidak Boleh “Melompat”

CLS AMP berhubungan dengan visual stability.

Bayangkan pengguna ingin menekan:

Daftar Sekarang

Namun tepat sebelum disentuh, banner muncul di atas tombol.

Posisi CTA bergeser.

Pengguna justru menekan elemen lain.

Inilah jenis pengalaman yang ingin dihindari.

Web.dev menjelaskan layout shift sering disebabkan resource yang dimuat asynchronously, elemen DOM yang ditambahkan secara dinamis, image/video tanpa dimensi yang jelas, font dengan ukuran berbeda dari fallback, dan third-party widget yang berubah ukuran.

Berikan Ruang Tetap untuk Gambar dan Video

Salah satu kekuatan arsitektur AMP adalah sistem layout yang membutuhkan ukuran resource sehingga browser dapat mengetahui ruang yang diperlukan sebelum resource selesai dimuat.

Contoh:

<amp-img
  width="1200"
  height="675"
  layout="responsive"
  src="/hero.webp"
  alt="Optimasi Core Web Vitals">
</amp-img>

Dengan width dan height tersebut, layout dapat memperkirakan rasio gambar lebih awal.

AMP sendiri menjelaskan sistem layout-nya dirancang agar ukuran resource seperti image, video, atau iframe diketahui sebelum resource diunduh. Hal ini membantu mengurangi layout shift.

Prinsip yang sama berlaku untuk:

• banner;
• testimonial slider;
• iframe;
• video;
• form;
• embed;
• advertisement container.

Sediakan ruang sebelum elemen datang.

Hati-hati dengan Sticky CTA

Sticky CTA dapat sangat efektif untuk conversion mobile.

Namun implementasi buruk dapat membuat halaman tidak nyaman.

Contohnya sticky bar muncul terlambat setelah halaman selesai dirender dan mendorong seluruh content.

Akibatnya CLS meningkat.

Solusi yang lebih tepat adalah mengalokasikan ruang atau menggunakan positioning yang tidak mendorong content existing secara tak terduga.

Selain itu, pastikan sticky CTA:

• tidak menutupi content utama;
• tidak terlalu besar;
• tetap mudah ditutup jika diperlukan;
• tidak menyebabkan accidental click;
• nyaman pada layar sempit.

Google juga menyarankan evaluasi page experience memperhatikan mobile display dan menghindari interstitial berlebihan yang mengganggu main content.

Form Conversion dan CLS

Form sering berubah ukuran ketika terjadi:

validation error

atau:

success message

Misalnya:

Nama
Email
Nomor WhatsApp
[Submit]

Setelah submit muncul error panjang:

Nomor WhatsApp tidak valid...

Kemudian seluruh bagian bawah halaman bergeser.

Untuk mengurangi masalah tersebut, developer dapat menyediakan ruang yang cukup untuk feedback atau menampilkan pesan sedemikian rupa sehingga tidak menyebabkan perpindahan besar pada layout.

Yang perlu dijaga:

conversion feedback tetap jelas

tanpa membuat UI meloncat secara agresif.

Jangan Mengejar PageSpeed 100 dengan Menghapus Conversion Element

Ini kesalahan yang sering terjadi dalam optimasi landing page.

Developer menjalankan Lighthouse.

Skor:

83

Kemudian menghapus:

• analytics;
• chat;
• video;
• testimonial;
• tracking;
• form;
• sticky CTA.

Skor berubah:

100

Namun conversion turun karena halaman kehilangan fungsi bisnis.

Google sendiri mengatakan mencoba memperoleh perfect score hanya untuk alasan SEO belum tentu menjadi penggunaan waktu terbaik. Google menyarankan melihat page experience secara keseluruhan.

Jadi targetnya bukan:

Score 100

melainkan:

Fast Enough + Stable + Responsive + Useful + Converts

Ukur Field Data, Bukan Lighthouse Saja

PageSpeed Insights mempunyai dua dunia pengukuran.

Pertama:

Field Data

Data pengguna nyata dari Chrome UX Report jika tersedia.

Kedua:

Lab Data

Pengujian Lighthouse pada environment terkontrol.

Google menjelaskan PSI menggunakan field metrics pada persentil ke-75 untuk evaluasi Core Web Vitals, sementara Lighthouse digunakan sebagai diagnostic analysis dalam kondisi simulasi.

Karena itu, jangan panik jika Lighthouse berubah:

91 → 88 → 94 → 89

Perubahan lab test dapat terjadi akibat kondisi pengujian.

Gunakan Lighthouse untuk menemukan masalah.

Kemudian gunakan field data untuk menilai pengalaman real user.

Mobile Core Web Vitals Lebih Penting untuk Landing Page

Pengguna smartphone sering menghadapi kondisi yang tidak sama dengan desktop developer.

Mereka dapat menggunakan:

• perangkat lebih lambat;
• CPU lebih lemah;
• koneksi mobile;
• jaringan tidak stabil;
• layar kecil.

Karena itu uji landing page dalam kondisi realistis.

Hero image yang terasa instan pada desktop kantor belum tentu cepat di smartphone dengan koneksi biasa.

Google memasukkan kualitas tampilan mobile sebagai bagian dari evaluasi page experience secara keseluruhan.

Contoh Audit Performance pada Landing Page Brand

Framework ini dapat diterapkan pada landing page commercial apa pun.

Sebagai contoh, NAGAVIP dapat dianalisis menggunakan urutan:

Server Response → Hero/LCP → Fonts → AMP Resources → Third-party Scripts → CTA → INP → Layout Stability → Mobile UX → Field Data

URL tersebut aktif saat saya periksa dan menampilkan halaman NAGAVIP.

Namun, sekadar halaman dapat dibuka belum menjawab pertanyaan performance.

Untuk landing page NAGAVIP, audit yang lebih berguna adalah mengidentifikasi elemen apa yang menjadi LCP, script apa yang memakai main thread, apakah layout bergeser ketika resource selesai dimuat, dan apakah CTA tetap responsif.

Dengan pendekatan tersebut, optimasi situs NAGAVIP tidak hanya berorientasi pada skor, tetapi pada pengalaman pengguna yang berpotensi mendukung conversion.

Framework Optimasi LCP tanpa Merusak Conversion

Misalnya hero section mempunyai:

Headline + Hero Image + CTA

Jangan menghapus hero image hanya karena LCP.

Sebaliknya:

Hero Image
↓
Compress
↓
Responsive size
↓
Preload jika kritis
↓
Prioritaskan loading
↓
Pertahankan CTA

Untuk AMP, hero image juga dapat dianotasi menggunakan data-hero, sementara AMP Optimizer dapat membantu mendeteksi hero image dan menambahkan preload pada resource penting.

Hasil yang dicari:

Visual tetap menarik + LCP lebih cepat.

Framework Optimasi INP tanpa Menghapus Tracking

Jangan langsung membuang analytics.

Gunakan pendekatan:

List semua script
↓
Tentukan script kritis
↓
Tentukan script non-kritis
↓
Kurangi duplicate trackers
↓
Tunda pekerjaan non-esensial
↓
Audit long task
↓
Tes CTA

Web.dev menyarankan audit berkala terhadap third-party scripts dan menghapus script redundan.

Jika dua platform melakukan fungsi sama, tanyakan apakah keduanya benar-benar diperlukan.

Framework Optimasi CLS tanpa Menghilangkan Elemen Conversion

Untuk visual stability:

Image → tentukan dimensions

Video → reserve space

Form error → reserve feedback area

Banner → hindari insert mendadak

Fonts → gunakan fallback yang sesuai

Sticky CTA → jangan mendorong content

Widget → sediakan container

Web.dev mengidentifikasi image/video tanpa dimensions, font swapping, dan third-party widget yang berubah ukuran sebagai penyebab umum CLS.

Jadi, Anda tetap dapat mempertahankan elemen conversion.

Yang diperbaiki adalah cara layout menampungnya.

Internal Linking untuk Cluster Core Web Vitals

Artikel ini harus menjadi bagian dari topic cluster dan terhubung ke artikel berikut.

#1 – SEO Landing Page AMP

Gunakan anchor:

SEO landing page AMP

Letakkan pada pembahasan technical architecture secara keseluruhan.

#3 – AMP Technical Validation

Gunakan anchor:

AMP validation SEO

Letakkan ketika membahas validasi markup, resource, atau implementasi AMP.

#14 – Search Visibility Google

Gunakan anchor:

search visibility Google

Letakkan ketika menjelaskan hubungan page experience dengan performa organic.

#18 – Audit Performance / Conversion

Gunakan anchor:

audit performance landing page

Letakkan pada bagian measurement dan conversion optimization.

Sebaliknya, artikel tersebut sebaiknya menautkan kembali ke halaman ini dengan anchor seperti:

Core Web Vitals landing page AMP, LCP landing page, optimasi INP, atau CLS AMP.

Checklist Audit Core Web Vitals Landing Page AMP

Gunakan checklist ini sebelum mengubah desain atau menghapus elemen conversion:

•  Identifikasi elemen LCP menggunakan PageSpeed Insights atau DevTools.
•  Pastikan hero image tidak menggunakan lazy loading.
•  Gunakan responsive image agar mobile tidak mengunduh aset terlalu besar.
• Preload hero image jika resource tersebut benar-benar kritis.
• Periksa TTFB dan response server.
• Audit font family dan font weight.
• Periksa semua third-party script.
• Hapus analytics atau pixel yang benar-benar redundant.
•  Audit Google Tag Manager dan custom HTML tags.
• Cari long tasks yang menghambat main thread.
• Tes INP pada CTA, menu, FAQ, dan form.
• Berikan dimensions pada image, video, dan iframe.
• Reserve space untuk form feedback serta dynamic content.
•  Periksa sticky CTA di mobile.
•  Bandingkan lab data dengan field data.
•  Jangan menghapus elemen conversion hanya untuk mengejar skor 100.

FAQ Core Web Vitals Landing Page AMP

Apa target Core Web Vitals yang baik?

Google saat ini merekomendasikan LCP dalam 2,5 detik, INP di bawah 200 ms, dan CLS di bawah 0,1 untuk pengalaman yang dikategorikan baik.

Apakah Core Web Vitals merupakan faktor ranking?

Google menyatakan Core Web Vitals digunakan oleh ranking systems. Namun hasil CWV yang baik tidak menjamin halaman mendapat posisi teratas karena Search mengevaluasi banyak aspek lain, termasuk relevansi serta keseluruhan page experience.

Apakah PageSpeed harus 100?

Tidak. Google mengatakan mengejar perfect score hanya untuk alasan SEO belum tentu menjadi penggunaan waktu terbaik. Fokus seharusnya pada pengalaman pengguna secara keseluruhan.

Bagaimana memperbaiki LCP hero image AMP?

Pastikan hero image ditemukan dan dimuat seawal mungkin. AMP mendukung preload hero image dan menyediakan data-hero untuk membantu AMP Optimizer mengenali resource hero.

Apakah hero image sebaiknya lazy load?

Tidak jika gambar tersebut merupakan LCP element. Web.dev memperingatkan bahwa lazy loading pada LCP image menyebabkan resource load delay.

Apa penyebab INP buruk?

Long tasks, JavaScript yang berat, main-thread blocking, event handler kompleks, serta pekerjaan rendering besar dapat memperlambat respons terhadap interaksi.

Apakah Google Tag Manager dapat memperburuk Core Web Vitals?

Bisa, tergantung implementasi tag di dalamnya. Tag dapat menggunakan bandwidth dan CPU, mengganggu LCP atau INP, serta memicu CLS jika memasukkan elemen secara dinamis.

Apa penyebab CLS tinggi?

Penyebab umum antara lain image/video tanpa dimensions, dynamic content, font swapping, serta third-party widget yang berubah ukuran setelah halaman mulai dirender.

Lebih penting Field Data atau Lighthouse?

Keduanya mempunyai fungsi berbeda. Lighthouse berguna untuk diagnosis dalam environment simulasi, sedangkan field data mencerminkan pengalaman pengguna nyata dan digunakan PSI dalam Core Web Vitals assessment ketika datanya tersedia.

Minta Audit Speed & Core Web Vitals Medan

Landing page AMP yang cepat bukan berarti landing page tersebut harus kehilangan hero image, tracking, form, CTA, atau elemen conversion.

Audit yang tepat mencari sumber performance cost kemudian memperbaikinya secara terarah:

Server → LCP Resource → Hero Image → Font → JavaScript → Tag Manager → INP → Layout Shift → Mobile UX → Field Data → Conversion

Untuk bisnis di Medan dan sekitarnya, audit Core Web Vitals sebaiknya tidak berhenti pada pertanyaan:

“Berapa skor PageSpeed?”

Pertanyaan yang lebih penting adalah:

“Bagian mana yang memperlambat real user, bagaimana memperbaikinya, dan apakah perubahan tersebut tetap menjaga conversion?”

Minta Audit Speed & Core Web Vitals Medan untuk mengevaluasi LCP, INP, CLS, server response, third-party scripts, CTA tracking, serta pengalaman mobile sebelum melakukan perubahan besar pada landing page.