Plugin optimasi gambar terbaik menurutmu atau menurut pengalamanmu?…

Plugin optimasi gambar terbaik menurutmu atau menurut pengalamanmu?

Source

8 comments

  1. Optimasi gambar terbaik adalah sebelum di upload.

    Set dimension, set ekstensi jpg/webp, clear exif, watermark, compress, etc

    Optimasi setelah di upload, pake plugin itu kurang significan, impact ada tp selisih cuma beberapa kilobyte #imho #cmiiw

  2. Pertama, terkait dimensi dan size media gambar/foto..

    Dari perspektif SEO, berapa sih ukuran panjang atau lebar ideal sebuah gambar yang dianjurkan Google? Sependek yang saya tahu, Google belum atau tidak pernah secara eksplisit memberikan berapa angka dimensi pixel sebuah image yang dia mau. Google seringnya hanya bilang gunakan gambar yang “provided great user experience”.

    Provided great user experience itu sering saya maknai begini. Jangan upload gambar terlalu kecil dimensinya (panjang x lebar), serta jangan terlalu buruk kualitasnya (burik). Dari pengalaman Googling2 gambar di Google, sering saya dapati Google nampilin gambar yang tak terlalu besar, pun tak terlalu kecil pada default preference.

    Saya sendiri pada 2019 silam hijrah ke ukuran gambar postingan dengan sisi terpanjang 1280px (rasio 16:9, jadinya 1280×720), dimana sebelumnya (2015) hijrah dari sisi terpanjang “sembarang” ke 800px (16:9 juga). Jadi gambar/attachment postingan saya sebelum tahun 2015 itu bener2 acak2an, baik dari dimensi maupun rasio.

    Media image 1280px itu menurut saya future-proof, baik dari sisi perkembangan teknologi desain web maupun efisiensi dalam penyimpanan jangka panjang. Artinya, dalam 5-10 mendatang atau bahkan lebih tidak perlu ganti dimensi gambar lagi serta media storage-nya pun tak akan “jebol” duluan karena file size kegedean.

    JPEG 1280x720px itu ketika dikompres ke 70-150KB masih bagus/acceptable kalau dari mata saya. Dengan catatan visualnya tidak banyak pattern/pola kek rumput/daun rimbun, hamparan kerikil, kain perca, dll. yang bikin data membengkak hingga burik saat “dipaksa” ke <150KB, bahkan dengan kompresi WEBP sekalipun.

    Sayangnya, lebar bodi konten (content container) yang "provided great user experience” itu setahu saya jauh lebih ramping dari 1280px, lazimnya di angka 600-900px, setidaknya sampai tahun 2021 ini. Belum lagi ketika visitornya kebanyakan mobile kayak saya, pastinya lebar viewport yang dilihat visitor akan lebih imut lagi (<600px).

    Solusi yang dipakai biasanya dengan “srcset (responsive)”, yakni memecah gambar original jadi beberapa ukuran/varian thumbnail yang nantinya akan dipanggil sesuai dengan lebar viewport device visitor. Metode ini sebenarnya sedikit mengorbankan efisiensi penyimpanan, tapi cara ini yang paling mudah dan simpel.

    Solusi lain yang “tidak simpel” namun saya pakai adalah bikin varian thumbnail dengan on-the-fly image manipulation via webserver, misal Nginx dengan directive image_filter-nya. Metode ini akan membuat media image di "/wp-content/uploads/" tetap sebiji, sehingga tujuan hemat media storage untuk jangka panjang tercapai.

    Mungkin ada pertanyaan, kalau yang tampil di postingan itu varian thumbnail (medium to small), kenapa kudu punya media > 1200px? Original file bisa disuguhkan dalam structured data (Schema). Dari pengalaman saya, metode ini membuat “image ori” tetap bisa bersaing di SERP Images meski pada preference “Size-Large”.

  3. Kedua, terkait hijrah ke WEBP atau tetap di JPEG..

    Bila memutuskan untuk pakai WEBP, satu hal penting yang perlu diperhatikan adalah jangan sampai file asli atau “master file” JPEG-nya hilang. Kenapa begitu, WEBP ini adalah teknologi yang menurut saya masih rawan di-legacy-kan alias akan punah lantaran adaptasinya sangat2 lambat. Dari 2010 diperkenalkan, hingga 2021 ini “market/usage share” WEBP masih berkutat di angka 2 persen saja.

    Misal di kemudian hari teknologi WEBP punah, lalu kita punya backup master JPEG-nya, proses rolled back-nya akan lebih mudah. Kalau file yang tersisa tinggal WEBP, akan sedikit ribet itu nanti proses convert ulang ke JPEG-nya. Selain itu, ketika kita hanya memiliki WEBP, jangan berharap kualitas visualnya usai di-convert ulang ke JPEG akan sama bagusnya dengan master file JPEG-nya.

    Ketika kita pakai teknologi/produk “non industry standard” atau potensi untuk menjadi teknologi yang dipakai mayoritas belum jelas kayak WEBP, kudu siap dengan segala risikonya. Pada kasus WEBP misalnya, beberapa image processing/editing “industry standard” seperti Photoshop belum secara native mendukung WEBP, kecuali pakai plugin/add-on. Jadi misal mau edit2 ulang file postingan ya tak sepraktis JPEG.

    Lalu metode apa yang paling aman dan nyaman dalam mengadopsi WEBP di web2 kita? Ada dua, pertama on-the-fly image manipulation di origin server-nya. Jadi webserver akan melakukan convert JPEG ke WEBP secara on-the-fly (non destructive) alias bikin file baru yang bakal diakses oleh visitor. File on-the-fly ini temporarily, jadi kudu digabungkan dengan cache agar tak terus2an bikin file baru yang beratkan server.

    Metode kedua, pakai saja layanan media hosting, proxy, atau CDN yang menduking file cache-nya berformat WEBP. CDN gratisan dari Photon/WP itu setahu saya secara default menyimpan cache dalam format WEBP (meski ekstensinya masih tertulis .jpg). Fitur serupa juga ada di Cloudflare, namanya Cloudflare Polish. Sayangnya untuk yang di CF ini kudu pelanggan Pro Plan ($20/mo) yang bisa pakai Polish.

    Satu lagi, antara JPEG/WEBP dan PNG/GIF/SVG itu beda segmen. JPEG/WEBP lazimnya untuk realistic image yang biasa dipakai pada media content foto. Sementara PNG/GIF/SVG itu untuk line drawing/art, text-heavy image, atau iconic graphic yang biasa dipakai pada elemen navigasi dan logo sebuah website. Tapi SVG dan PNG bisa juga masuk ke media content non realistic, seperti di ilustrati postingan2 hosting provider.

  4. Ketiga, terkait pakai CDN pasti bakal makin ngebut?

    Tergantung kualitas infrastruktur/network CDN-nya atau provider CDN apa yang dipakai. Jangan sampai kualitas server, jaringan, dll. pada CDN yang dipilih malah lebih inferior dibanding origin server-nya atau hosting yang kita pakai. Pada kondisi seperti itu (infrastruktur CDN lebih inferior), malah bisa bikin performa web secara keseluruhan menurun, alih2 makin ngebut.

    Satu yang perlu digarisbawahi, ketika ngomongin “pakai CDN” itu lazimnya akan dimaknai yang di-CDN-kan itu hanya asset2anya ya, bukan root domain/url atau HTML utamannya. Maka itu, biasanya enggak ngaruh ke misal time to first byte (TTFB) dari root URL-nya. TTFB asset2nya saja seperti gambar, font, JS, dll. yang punya potensi membaik/memburuk.

    2016 saya pakai KeyCDN, 2017 BunnyCDN, 2018 Verizon + Akamai (via Azure) serta nyoba Highwinds/StackPath. 2019-sekarang bolak-balik antara Cloudflare (gratis) dan enggak pakai CDN. Beberapa bulan silam, waktu masih pakai cache2an (proxy cache), saya tidak pakai CDN. Kini setelah server-nya tanpa cache2an, balik lagi “numpang CDN” (asset only) di CF.

    Idealnya, ketika saat ini saya pakai server di AWS (Lightsail) yang infrastruktur/network-nya jempolan dan target visitor saya hanya satu daerah/region, tidak perlu pakai CDN. Malah rasanya sayang kalau pakai CDN, gratisan “bandwidth premium” 8 TB (akumulasi gratisan BW/data transfer pool 4 VM) dari AWS Lightsail mubazir kalau enggak dipakai.

    Tapi, kalau enggak pakai CDN2an, itu server2 saya di Lightsail yang cuma pakai $5-an dengan spek imut2 (setara t2.micro – baseline CPU credits 10%) bakal ngos2an nge-load asset2 static di web saya, khususnya media image yang pakai on-the-fly manipulation (resize, crop, dll.). Solusinya ya di-cache-kan saja ke CF biar meringankan beban origin server-nya.

    Ketika saya cek TTFB-nya via DevTools Chrome dengan koneksi antara Tri dan Telkomsel (seringnya sih Tri) itu asset2 yang saya “titipkan” ke CF lebih inferior, jarang dapet < 70ms pada PoP region yang sama dengan origin-nya (AWS-SG). Sebagai pembanding, static2 asset yang diakses langsung via origin-nya di AWS sering dapet < 70ms, bahkan tak jarang nyentuh 50an ms. Pada kondisi seperti yang saya alami saat ini, akan muncul pertanyaan, ngapain pakai CDN kalau malah tidak meningkatkan kecepatan akses web secara keseluruhan alias tidak bisa menggenjot performa static2 asset-nya. Bukankah lebih baik ke setup sebelumnya, yang tidak pakai CDN tapi cuma cache (proxy cache) di server-nya namun lebih ngebut? Setup server, CDN, dll. di blog2 saya itu sebenarnya belum final, bahkan mungkin tak akan pernah “selesai”. Untuk saat ini, ketika lagi pengen web/blog2saya jalan tanpa cache2an, baik di level server-nya atau di level WP-nya, CDN dari CF membantu banget untuk ringankan beban server. Bisa jadi besok, lusa, dst. berubah lagi dengan pakai cache2an di origin tanpa CDN CF.

  5. **bonus. Keempat, terkait nyimpan media di pihak ketiga..

    Nyimpan media di luar direktori “wp-content/uploads” atau di-push ke tempat lain itu bagus atau tidak, jawabannya relatif. Saya sendiri cenderung menghindari nyimpan media di luar wp-content. Dengan menyimpan media di direktori standarnya WP, rasanya lebih nyaman karena saya punya hak akses penuh atas file tersebut. Tidak ada rasa khawatir file-nya hilang, struktur URL/path file-nya berubah dll.

    Benar, nyimpen media di pihak ke-3 juga punya hak akses penuh atas file tersebut karena akunnya punya kita. Namun, apakah bisa menjamin layanan tersebut tetap ada dalam 4-5 tahun ke depan? Kalau layanan hosting media pihak ke-3 tidak mengharuskan ganti path “wp-content/uploads/xxxx/xx/”, enak2 saja sih pas suatu hari harus balik ke “wp-content/uploads”. Bagaimana bila sebaliknya, “/xxxx/xx/” atau jejak tahun dan bulannya terlanjur ilang?

    Salah satu blog saya memiliki 4 ribuan gambar dari tahun 2012 yang masih terorganisir dengan baik dalam format direktori/path default WP “wp-content/uploads/xxxx/xx/“. Tak bisa saya bayangkan betapa tidak nyamannya ketika suatu saat harus mengatur atau mengedit media2 di postingan lama, lalu ribuan gambar itu hanya tersimpan di satu folder. Pasti kondisi seperti itu rasanya berantakan sekali, mirip tampilan desktop laptop/komputer cewek.

    Karena media file di blog tertata dengan begitu rapinya (setidaknya dari perspektif saya), saya merasa nyaman sekali atau tak menemui kesulitan ketika dalam beberapa tahun gonta-ganti root domain untuk media tersebut. Gonta-ganti mulai dari “cdn.domain-saya”, “static.domain-saya”, “media.domain-saya”, “domain-cdn”, “domain-object-storage” dll. Kan yang berubah2 hanya root domainnya, saat edit2 file aslinya tetap nyaman karena jajak/identitas tanggal file-nya terjaga.

    Saat ini media file saya pakai pull CDN Cloudflare alias file aslinya masih tertata dengan baik di origin servernya (wp-content/uploads). Format domain/root yang saya pakai “domain-cdn” atau domain sendiri, dalam hal ini xxx,wp-asset,com. Mengingat CF itu adalah pull CDN, artinya saya pakai CDN CF bukan untuk ngejar hemat storage server, tapi lebih ke keyakinan bahwa “setangguh2nya server saya di Upcloud, tetap tidak lebih tangguh dibanding punyanya Cloudflare”.

    Ngomong2, keengganan untuk tidak pakai media penyimpanan pihak ketiga di atas mirip2 dengan keputusan saya sampai detik ini tidak memakai sama sekali fitur embed dalam setiap postingan2 di blog2 Gnews saya, baik itu embed Twitter, Instagram, Youtube dll. Saya lebih memilih untuk pakai cara jadul, screenshot postingannya, lalu upload di direktori web sendiri sebagai gambar. Sering kali saya temui artikel2 web besar ada broken-embed dan terlihat aneh.

Leave a comment

Your email address will not be published.