Panduan WPO: Cara Mengoptimalkan Kecepatan Loading Situs Web Anda
David Kaufmann
Tutorial SEO
17 min read
Selama beberapa tahun terakhir, kami telah menyaksikan para profesional pemasaran menempatkan kecepatan loading di puncak setiap proses optimasi. Pada tahun 2017, Google mulai menekankan pentingnya kecepatan loading dan pengaruhnya di masa depan terhadap ranking, tetapi baru pada musim panas 2018 Google membuat pernyataan ini resmi.
Pada artikel ini kami bertujuan untuk membantu Anda mulai mengoptimalkan dan meningkatkan kecepatan loading situs web Anda sendiri. Seperti proses optimasi mana pun, ada sisi teknis yang bisa menjadi rumit. Di SEO Alive, setiap kali kami menulis artikel jenis ini, kami ingin Anda dapat menerapkannya sendiri, meskipun beberapa tindakan memerlukan pengetahuan tingkat yang lebih teknis. Sejujurnya, mari kita tidak menjadi gila mengejar skor dalam alat-alat yang akan kita gunakan untuk mengaudit WPO situs kita.
Optimasi sangat bergantung pada bagaimana template dirancang, dan tidak setiap template memungkinkan Anda mendapatkan performa yang sama. Penting untuk mengingat itu.
Mari kita mulai!
Apa itu WPO?
Web Performance Optimization, yang kami sebut WPO, hanyalah optimasi dari berbagai proses yang memengaruhi bagaimana sebuah situs web dimuat.
Bagaimana cara mengukur kecepatan loading situs web?
Ada banyak alat untuk mengukur kecepatan loading. Yang paling populer adalah:
Sebelum memulai audit, penting untuk mengingat bahwa kecepatan loading bervariasi untuk setiap pengguna. Variabel yang berbeda dapat memengaruhi bagaimana kecepatan terasa bagi pengguna di Cuenca dibandingkan dengan pengguna di Ottawa.
Itulah mengapa, daripada bekerja pada waktu loading dalam detik, kami merekomendasikan untuk fokus pada optimasi:
›
Bobot situs web (MB)
›
Request
›
Waktu respons server
Jika kita meningkatkan 3 area ini, kecepatan loading akan meningkat terlepas dari di mana pengguna berada.
Kita akan menyelami setiap area dan, melalui berbagai alat, kita akan melihat cara mengerjakannya untuk meningkatkan performa setiap URL. Mengapa saya katakan setiap URL? Karena, meskipun mungkin terlihat jelas, saya telah menemui banyak kasus di mana hanya data beranda yang dievaluasi, dan tentu saja, setiap halaman di sebuah situs tidak memuat sumber daya yang sama.
Google Developer Tools
Sebelum kita mulai, saya ingin menjelaskan beberapa opsi yang ditawarkan Google melalui developer tools-nya. Alat ini adalah salah satu yang paling penting untuk menganalisis cara kerja sebuah situs web. Klik kanan pada halaman yang dibuka browser dan panel dengan opsi yang berbeda akan muncul. Kita akan pergi ke Inspect (Ctrl + Shift + I).
Setelah alat tersebut terbuka, kita akan menuju ke opsi NETWORK yang akan Anda temukan di bagian atas. Jika kita menekan ENTER lagi di browser, alat tersebut akan menunjukkan loading dari berbagai sumber daya.
waktu loading di Google developer tools
Di bagian bawah gambar, kita dapat melihat data yang menarik bagi kita untuk pandangan umum tentang bagaimana situs dimuat.
Menggali lebih dalam ke panel ini dari atas dan melihat struktur kolom, kita memiliki:
›
Name: nama sumber daya.
›
Status: kode respons sumber daya (200, 301, 404...)
›
Type: jenis sumber daya (script, font, png, jpg, stylesheet...)
›
Initiator: sumber daya mana yang memicu request.
›
Time: berapa lama request membutuhkan waktu.
›
Waterfall: representasi grafis dari waktu loading sumber daya.
Jika kita klik kanan di bagian atas, kita dapat menambah dan menghapus kolom dengan informasi ini.
menambah dan menghapus elemen informasi di network
Mengaktifkan elemen informasi tambahan seperti Domain, Scheme atau Cookies dapat membantu dalam kasus tertentu untuk menemukan sumber daya yang mungkin menyebabkan beberapa jenis masalah, tetapi pada titik ini kita akan tetap dengan yang sudah pre-defined.
Ada satu aspek yang, meskipun sangat menarik, hanya akan saya singgung sedikit agar kita tetap mengingatnya. Kecepatan koneksi, terutama di mobile, adalah bagian penting dari bagaimana sebuah situs dimuat. Dari alat ini kita dapat mensimulasikan kecepatan yang lebih lambat seperti 3G di mobile.
mensimulasikan kecepatan transfer yang lambat
Bagaimana mengetahui bobot URL dan bagaimana menguranginya?
Bobot, baik dalam Megabyte atau Kilobyte, adalah salah satu alasan utama URL membutuhkan waktu untuk dimuat. Itulah mengapa kita mulai dengan menyelami aspek ini, karena ini akan menentukan jalan untuk mencapai optimasi yang baik di situs kita.
Data berikut berasal dari alat yang disebutkan di atas, GTMETRIX, dan sesuai dengan situs web yang akan saya mulai optimalkan.
metrik bobot web
Kita akan fokus pada data di kolom kanan, yang mengacu pada (Page Details), khususnya Total Page Size.
Sekilas, bobot situs ini jauh di atas rata-rata, tetapi ingatlah bahwa yang penting bukanlah bobot total situs tetapi berapa lama bobot itu dimuat, karena ada sesuatu yang disebut Lazy Load, sebuah fitur yang menunda loading hingga pengguna membutuhkan sumber daya tersebut. Kita akan membicarakannya nanti.
Kita juga dapat menemukan informasi ini di developer tools, di panel yang kita lihat di atas, yang akan saya ingatkan kembali kepada Anda.
waktu loading di Google developer tools
Jika Anda melihat di bagian bawah, baik 7.5 MB maupun 215 request sangat dekat dengan angka yang dilaporkan oleh GTMETRIX. Penting bagi Anda untuk mengetahui dari mana GTMETRIX mendapatkan informasinya jika Anda pernah ingin menggunakan alat yang berbeda.
Sekarang mari kita lihat apa yang membebani begitu banyak dan bagaimana kita bisa memperbaikinya.
Opsi Waterfall menawarkan tampilan visual tentang bagaimana sumber daya dimuat, menampilkan URL sumber daya, status, domain dan kolom Size. Jika kita klik kolom terakhir itu, ia akan mengurutkan bobot dari yang terbesar ke terkecil dan dari yang terkecil ke terbesar.
menganalisis loading melalui waterfall
Melihat bobotnya, kita dapat melihat, seperti yang terjadi di sebagian besar kasus, bahwa gambar sebagian besar bertanggung jawab atas bobot URL yang berlebihan.
Tidak ada spesifikasi formal untuk bobot maksimum yang harus dimiliki gambar, tetapi kami merekomendasikan tidak lebih dari 100 KB dan, jika Anda memiliki opsi (jika Anda menggunakan Photoshop Anda punya), atur gambar untuk dimuat secara progresif sebagai JPG dan hindari PNG kapan pun Anda tidak memerlukan saluran Alpha (transparansi).
Dengan mengurangi bobot gambar, kita akan secara signifikan meningkatkan loading situs, dan ada beberapa alat yang bisa Anda gunakan. Saya pribadi mengoptimalkan dengan Photoshop, tetapi ada opsi online yang menarik:
Baik GTMetrix maupun alat Google memungkinkan kita melihat sumber daya berdasarkan jenis, yaitu, hanya gambar, script, CSS...
Ini berguna untuk perspektif yang lebih luas tentang di mana harus bekerja. Pada URL ini, gambar menyumbang 4 MB dari 7.2 MB, jadi sebagian besar masalah bobot ada di sana. Meskipun demikian, ada sumber daya lain yang menonjol sebagai sangat berat untuk jenisnya, seperti file CSS lebih dari 700 KB dan Script lebih dari 300 KB.
Pada titik ini saya ingin mengklarifikasi bahwa ketika kita melakukan optimasi kecepatan loading (WPO) kita harus menghadapi masalah tertentu yang, meskipun memiliki solusi, tidak berada dalam jangkauan kita untuk bertindak.
Dalam kasus ini kita melihat file CSS yang sangat besar. Jika desainer membuat CSS lebih dari 700 KB, mengoptimalkan file tertentu itu akan sulit.
Apa yang dapat kita lakukan untuk mengurangi bobot file-file ini?
Minify (CSS, JS dan HTML)
Minifikasi adalah proses yang berusaha mengurangi bobot file dengan menghapus data yang tidak perlu seperti komentar, spasi, kode berulang dan kode yang tidak digunakan. Ada banyak alat untuk melakukan proses ini, kecuali untuk bagian kode yang tidak digunakan, yang lebih sulit untuk dioptimalkan dan akan memerlukan masuk secara manual ke dalam file (sesuatu yang tidak saya rekomendasikan).
Untungnya kita berbicara tentang WordPress, dan seperti yang kita semua tahu, di WordPress sangat jarang tidak menemukan plugin yang menangani operasi ini.
Secara pribadi saya suka menggunakan yang sepenuhnya gratis, Autoptimize, dan yang berbayar, WP Rocket.
Pada artikel ini saya tidak ingin menjelaskan bagaimana plugin ini bekerja sebanyak bagaimana melakukan tugas optimasi. Karena jika kita menggunakan plugin lain, mereka juga memiliki opsi ini, dan yang terbaik adalah memahami apa yang kita lakukan.
Minify dengan WP Rocket
Bagian ini tidak rumit. Kita hanya pergi ke tab optimasi file dan centang kotak minify HTML. Di WP Rocket opsi ini diulang di bawah untuk file CSS dan JS. Tetap saja, saya merekomendasikan untuk mengaktifkan kotak ini dan mengetes. Ulangi opsi ini satu per satu, karena jika ada yang gagal akan lebih mudah untuk menentukan masalahnya.
minify html dengan wp rocket
Sebelum memeriksa efek minifikasi kita harus membersihkan cache, jika tidak kita tidak akan melihat hasil dari HTML yang diperbarui.
Bagaimana cara membersihkan cache browser?
Plugin jenis ini dilengkapi dengan opsi untuk membersihkan cache, yang dapat kita lihat di bagian atas.
bersihkan cache dengan wp rocket
Cara lain adalah melalui browser, setelah Google Developer Tools diaktifkan (Ctrl + Shift + I).
Klik kanan pada panah "reload page" dan pilih "empty cache and hard reload."
membersihkan cache dari browser Chrome
Minify dengan Autoptimize
Dengan Autoptimize, aksi optimize adalah yang melakukan minifikasi, dengan keistimewaan menawarkan opsi untuk menyimpan komentar HTML. Komentar ini biasanya ditambahkan oleh developer untuk menyimpan informasi yang mungkin berguna di masa depan.
minify html dengan autoptimize
Untuk memeriksa bahwa optimasi ini telah berlaku, kita akan pergi ke source code URL dan seharusnya melihat sesuatu seperti ini:
contoh html yang sudah di-minify
Kode menjadi tidak terbaca tetapi fungsionalitasnya sama.
Opsi-opsi ini berulang dengan cara yang sama di WP Rocket dan Autoptimize untuk file CSS dan JS. Seperti yang saya sebutkan sebelumnya, saya tidak merekomendasikan mengoptimalkan semuanya sekaligus, tetapi 1 per 1. Plugin ini menyimpan salinan file yang di-minify, jadi kembali ke aslinya dimungkinkan dengan menghapus centang pada kotak yang sesuai.
Untuk terus mengurangi bobot halaman kita memiliki 2 opsi lagi:
›
Hapus atau kurangi plugin yang menambahkan CSS atau JS ke loading.
›
Hapus atau pangkas kode yang tidak digunakan dari file CSS.
2 opsi ini lebih kompleks dan memerlukan lebih banyak pengetahuan, karena Anda harus berhati-hati dan memastikan tidak ada panggilan dari halaman lain ke bagian yang Anda hapus.
Meskipun menghapus plugin tidak selalu memungkinkan karena sumber daya yang mereka berikan, ada plugin yang lebih dioptimalkan daripada yang lain, artinya lebih sedikit request dan JS yang lebih ringan. Jadi di ekosistem WordPress yang luar biasa hampir selalu ada alternatif.
Loading time vs response time
Sekarang saatnya berbicara tentang request, response time dan loading time. Pada titik ini kita harus menyebutkan bagian fundamental dari proses tersebut: server. Optimasi server biasanya berada di luar kendali kita, jadi penting untuk memilih solusi yang efisien.
Tetapi mari kita ambil langkah demi langkah.
Apa itu request?
Sebuah request, atau HTTP Request, adalah panggilan yang dilakukan dari client ke server untuk meminta sumber daya tertentu. Request dapat mencapai server yang berbeda.
Request bisa berupa HTTP atau HTTPS. Jika kita melihat struktur request, kita dapat menganalisis di mana penundaan waktu terjadi.
Analisis waktu HTTP request
struktur HTTP request
Mari kita uraikan apa yang kita lihat dalam grafik waktu ini.
›
Request dimulai tetapi diblokir atau diantrian: Jika blok berlangsung lama bisa karena beberapa alasan: request prioritas yang lebih tinggi atau banyak request ke origin ini.
›
DNS Lookup: browser sedang menyelesaikan alamat IP dari request.
›
Connecting: waktu yang dibutuhkan untuk terhubung ke server untuk menyelesaikan request. Jika waktu ini tinggi, bisa jadi indikasi masalah jaringan, kesalahan koneksi atau server yang kelebihan beban.
›
Sending: request sumber daya dikirim.
›
Waiting: ini adalah waktu yang dibutuhkan server untuk menyelesaikan request dan mengirim respons; jika lama, ada masalah di server.
›
Receiving: menerima sumber daya.
Sebuah HTTPS request menambahkan satu langkah lagi, yang ditampilkan di sini.
analisis HTTPS request
Dua screenshot ini milik dua situs yang berbeda, satu tidak teroptimasi (HTTP Request) dan satu lagi teroptimasi (HTTPS Request).
Jika Anda perhatikan dengan cermat dan membandingkan, perbedaan terbesar ada pada waktu tunggu. Dalam kasus ini, Anda perlu menganalisis server dengan lebih detail.
Server request: bagaimana cara menguranginya?
Seperti yang telah kita lihat, jumlah request terkait erat dengan loading time, jadi mengurangi jumlah request akan meningkatkan loading time URL. Akal sehat berperan dalam proses optimasi dan mengetahui apakah suatu sumber daya benar-benar berguna bagi pengguna atau bisnis kita. Ini adalah saatnya untuk mengucapkan selamat tinggal pada sumber daya tertentu yang tidak menambahkan apa pun, tetapi saya bukan orang yang memutuskan itu.
Tetap saja, kita memiliki opsi untuk meningkatkan request, meskipun tindakan ini tidak membawa perubahan besar pada loading situs. Saya akan mengulangi diri saya: yang terbaik adalah menghapus sumber daya yang tidak menambahkan apa pun.
Combine CSS dan JS
Tindakan populer lainnya saat mengoptimalkan halaman web adalah menggabungkan sumber daya CSS dan JS, tetapi apa artinya itu?
Tujuan dari penggabungan adalah untuk mengurangi request dengan biaya meningkatkan bobot file. Menggabungkan berarti menyatukan berbagai sumber daya CSS atau JS menjadi satu.
Jika response time lama, menggabungkan dapat bermanfaat. Jika send time sangat lambat, mungkin teknik lain lebih baik.
Idealnya adalah menggabungkan sambil memiliki server yang baik, sehingga kita menang di kedua sisi.
Menggabungkan sumber daya dengan WP Rocket dan Autoptimize
Operasi combine dengan plugin ini sesederhana sebelumnya. Kita hanya mencentang kotak yang sesuai.
combine css di wp rocket
Di WP Rocket opsi untuk menggabungkan CSS dan JS sama; panel-panelnya hampir identik. Seperti yang kita lihat di gambar, ada kotak untuk menambahkan path file yang tidak ingin kita gabungkan.
Autoptimize menawarkan lebih banyak opsi untuk bekerja dengan CSS dan mengurangi request. Pada opsi yang saya tandai, ia menggabungkan dan memberi Anda peringatan tentang efek yang mungkin terjadi, tetapi pada akhirnya ini selalu relatif.
Pada bagian pertama artikel ini, saya ingin menjelaskan apa yang dimaksud dengan tindakan dasar tertentu, yang biasanya kita lihat di hampir semua plugin optimasi WPO, tetapi masih banyak yang bisa kita lakukan untuk meningkatkan baik request maupun loading times.
Konfigurasi Cache
Tanpa diragukan, optimasi cache adalah salah satu tindakan di mana kita akan memperhatikan peningkatan terbesar dalam bagaimana sebuah situs dimuat. Pada artikel tentang SEO untuk WordPress ini saya menjelaskan bagaimana cache bekerja. Saya menyarankan Anda untuk meliriknya untuk memahami bagaimana ia bekerja.
Autoptimize dan WP Rocket melakukan tindakan caching, tetapi WP Rocket memberi Anda beberapa opsi lagi. Perlu dicatat bahwa plugin telah mengubah optimasi ini menjadi sesuatu yang lebih sederhana: Anda hampir tidak memiliki beberapa opsi dan prosesnya cepat dan tanpa rasa sakit.
konfigurasi wp rocket
Seperti yang Anda lihat, WP Rocket memungkinkan Anda mengerjakan 4 hal:
›
Mengaktifkan caching untuk perangkat mobile.
›
Menyimpan file secara terpisah untuk perangkat mobile.
›
Mengaktifkan caching untuk pengguna yang login.
›
Menentukan waktu untuk membersihkan cache.
Tergantung pada setiap proyek opsi mana yang dipilih, tetapi dengan semua ini dalam pikiran saran saya adalah:
›
Cache mobile selalu, karena meskipun sebagian besar situs responsive, ada konten yang mungkin Anda miliki di mobile tetapi tidak di desktop.
›
File secara terpisah.
›
Tidak ada cache untuk pengguna yang login, terutama karena jika saya melakukan editing saya tidak ingin caching.
›
Waktu cache, yang tergantung pada berapa banyak perubahan yang Anda buat di situs Anda. Jika itu adalah situs berita harian, pendek; jika itu adalah konten yang tidak sering diperbarui, lebih panjang.
Lazyload
Fitur lazyload membantu menampilkan sumber daya (Gambar dan Iframe) ketika pengguna membutuhkannya; yaitu, browser tidak memuat sumber daya ini sampai pengguna menggulir ke sana. Fitur ini diimplementasikan di banyak plugin dan bahkan datang pre-configured di beberapa tema WordPress. Dari Chrome versi 76 dan seterusnya, bahkan datang secara native di browser.
Ini berarti dengan menambahkan atribut loading="lazy", browser sudah menafsirkan lazy loading gambar, tetapi tentu saja tidak setiap browser akan menafsirkan ini, jadi saya merekomendasikan untuk terus menggunakan plugin. Berikut video yang diambil dari web.dev yang menunjukkan contoh tentang apa itu lazy loading gambar.
Optimasi Iframe
Jika kita menggunakan iframe untuk menyematkan konten dari situs lain, kita memiliki dua tindakan yang dapat kita gunakan untuk meningkatkan loading kita.
›
Lazy loading melalui fungsi lazyload
›
Atau mengganti iframe dengan gambar sampai pengguna mengkliknya.
Baik opsi pertama maupun kedua dapat diaktifkan melalui, sekali lagi, plugin go-to kita WP Rocket.
Loading file JS yang ditangguhkan dengan Defer atau Async
File JS adalah salah satu penyebab dari apa yang disebut audit kecepatan sebagai render blocking dari sebuah halaman. Ini terjadi ketika, saat rendering, browser berhenti untuk mengunduh file JS dan menjalankannya. Tujuan dari optimasi WPO adalah untuk memberikan informasi kepada pengguna sesegera mungkin, itulah mengapa ini dianggap blocking, karena tidak ada yang dirender sampai JS yang diunduh dijalankan.
Itulah mengapa tindakan jenis ini cenderung ditandai dalam audit. Saat menggunakan plugin pihak ketiga atau tema yang tidak teroptimasi dengan baik, kita dapat memiliki JS yang memblokir rendering karena, misalnya, ada di header.
Dalam kasus ini kita harus menggunakan dua atribut yang ditambahkan dalam kode call JS, Defer dan Async. Agar atribut ini berfungsi, script harus eksternal.
Di SEO Alive kami menggunakan plugin Pre Party Resource Hints, yang memungkinkan Anda memilih file mana dan metode loading mana yang ingin Anda terapkan. Sebuah keajaiban!
Apa perbedaan antara Defer dan Async?
Meskipun kedua atribut memiliki tujuan yang sama, mencegah interpretasi DOM HTML dihentikan oleh JS, ada perbedaan yang mencolok antara keduanya.
Dengan atribut Async sumber daya diunduh tanpa menghentikan loading HTML, tetapi setelah diunduh, loading HTML dihentikan untuk menjalankan JS; dengan atribut defer sumber daya juga diunduh secara paralel dengan loading HTML, tetapi dijalankan ketika loading selesai, sehingga tidak ada blocking oleh script.
Dalam hal ini ada perbedaan antara WP Rocket dan Autoptimize. WP Rocket membuat keputusan jauh lebih mudah untuk Anda dan bertindak secara semi-otomatis untuk mencegah JS memblokir rendering; di Autoptimize, di sisi lain, Anda hanya dapat mengaktifkan opsi Async.
Di Autoptimize, di bawah tab extra kita memiliki opsi ini untuk menambahkan file JS yang ingin kita muat dengan Async, tetapi untuk fleksibilitas yang lebih besar mereka merekomendasikan plugin pelengkap lain, "Async Javascript".
async load autoptimize
Dengan plugin ini kita dapat bekerja dengan Defer dan Async, dan bahkan menawarkan opsi sekali klik untuk memudahkan. Hal yang baik tentang plugin ini adalah kita dapat bekerja dengan script dan mengecualikan yang kita anggap perlu. Di WP Rocket, di sisi lain, kita harus mempercayai apa yang dilakukan plugin, meskipun melakukannya dengan baik.
Opsi ini ada di tab optimasi file yang sama.
atribut defer wp rocket
Apa itu CDN dan bagaimana ia dapat membantu kita?
CDN adalah apa yang dikenal sebagai content delivery network. CDN bertanggung jawab untuk menyimpan sebagian informasi dan sumber daya untuk meringankan beban server untuk sumber daya tersebut dan merespons dengan lebih baik terhadap loading. CDN juga memiliki fungsi salinan geografis, untuk menjaga sumber daya tersedia di titik yang berbeda dan menyajikannya kepada pengguna terlepas dari di mana mereka terhubung. Biasanya layanan jenis ini digunakan untuk file berat seperti Gambar dan Video.
Mendaftar untuk layanan ini penting ketika kita memiliki situs dengan banyak traffic, meskipun tidak boleh dikesampingkan untuk situs dengan sedikit traffic.
Tindakan lain yang akan memberi kita sedikit peningkatan lebih
Untuk menutup artikel ini kita memiliki 3 peningkatan lagi yang, meskipun tidak akan menghasilkan perubahan besar dalam loading time, akan membantu kita mengurangi request, dan pada akhirnya itulah yang kita inginkan.
Optimasi font
Optimasi font dapat dilakukan melalui plugin atau secara manual dengan mengedit dan mengoptimalkan CSS. Idealnya adalah hanya memanggil font yang akan Anda gunakan dan tidak, seperti yang terjadi dalam banyak kasus, mengunduh file dengan semua Google Fonts.
Autoptimize memiliki opsi untuk mengerjakan font.
optimalkan font dengan autoptimize
Sulit untuk mengatakan opsi mana yang harus dipilih tanpa melihat proyek, karena saya tidak tahu font mana yang digunakan template Anda dan kapan ia dimuat, jadi yang terbaik adalah menguji dan melihat hasilnya.
Seperti yang Anda lihat, tepat setelah opsi Google Fonts kita memiliki "Remove Emoji", yang akan menghemat kita request ke server. Fungsinya hanyalah mengonversi simbol yang merepresentasikan emoji menjadi ikon.
emoji wp rocket
WP Rocket juga memungkinkan kita menonaktifkan emoji ini dan juga menawarkan opsi untuk mencegah konten disematkan di situs pihak ketiga.
Pada akhirnya ada banyak tindakan untuk meningkatkan kecepatan loading sebuah situs. Tidak selalu mungkin untuk bekerja secara mendalam untuk mengoptimalkan setiap sumber daya, karena tergantung pada jenis bisnis dan apa yang dibutuhkannya.
Saya berharap panduan optimasi WPO ini bermanfaat dan Anda dapat menerapkannya pada proyek Anda atau untuk klien Anda.
Saya telah menghabiskan lebih dari 10 tahun terakhir benar-benar terobsesi dengan SEO — dan jujur saja, saya tidak mau menukarnya dengan apa pun.
Karier saya mencapai level baru ketika saya bekerja sebagai senior SEO specialist untuk Chess.com — salah satu dari 100 website paling banyak dikunjungi di seluruh internet. Bekerja di skala seperti itu, di jutaan halaman, puluhan bahasa, dan di salah satu SERPs paling kompetitif yang ada, mengajari saya hal-hal yang tidak akan pernah bisa diberikan oleh kursus atau sertifikasi mana pun. Pengalaman itu mengubah cara pandang saya tentang seperti apa SEO yang benar-benar hebat — dan menjadi fondasi bagi semua yang saya bangun setelahnya.
Dari pengalaman itu, saya mendirikan SEO Alive — sebuah agency untuk brand yang serius menggarap pertumbuhan organik. Kami tidak di sini untuk menjual dashboards dan laporan bulanan. Kami di sini untuk membangun strategi yang benar-benar menggerakkan hasil, menggabungkan yang terbaik dari SEO klasik dengan dunia baru yang menarik dari Generative Engine Optimization (GEO) — memastikan brand Anda tidak hanya muncul di tautan biru Google, tetapi juga di dalam jawaban yang dihasilkan AI yang dikirimkan ChatGPT, Perplexity, dan Google AI Overviews kepada jutaan orang setiap harinya.
Dan karena saya tidak bisa menemukan tool yang menangani kedua dunia itu dengan benar, saya membangunnya sendiri — SEOcrawl, sebuah platform enterprise SEO intelligence yang menyatukan rankings, audit teknis, pemantauan backlinks, kesehatan crawl, dan pelacakan visibilitas brand di AI dalam satu tempat. Inilah platform yang selalu saya harap pernah ada.