Arayüz geliştirme sürecinde optimizasyon için ipuçları

Arayüz geliştirme sürecinde optimizasyon için ipuçları

İnternet çok hızlı gelişiyor ama insanlar, ona erişimlerinin her geçen gün daha da hızlanmasını bekliyor. Mesela bir zamanlar 6 saniye diye bir şey vardı. 6 saniye sonra insanların web sitesiyle ilgili bir sorun olduğunu düşündükleri veya dikkatleri dağılıp siteden ayrıldıkları söylenirdi. Şu anki beklentiyi bilmek ister misiniz?

SADECE 1 SANİYE

Evet. 1 saniye. Kullanıcınıza ne vaad ederseniz edin, onların size vereceği süre sadece 1 SANİYE.

Aslında bu yüzden birçok sitede de görebileceğiniz ilgi çekici bekleme (loading) animasyonlarıyla karşılaşmışsınızdır. Bazen hazırlanan arayüz ne kadar optimize edilmiş olsa da istenmeyen sürelerde beklemelere sebep olabiliyor. Burada kullanıcının en azından “Nooluyo orda yaa!?” etkisiyle ilgisini çekip o bekleme anını fark etmemesini sağlamaya çalışarak, biraz daha olsun sitede o bekleme anına tahammülünü arttırabiliyoruz. Ancak bazen öyle durumlar ortaya çıkabiliyor ki 20 saniyede açılan sitelerle karşılaşabiliyorsunuz.

Bekleme süresi kullanıcılar için çok önemlidir. İnternet doğası gereği her yerden ulaşılabilir bir konuma geldikten sonra kullanıcıların sabırsızlıklarıda tabii ki daha da arttı. Kullanıcılar, ziyaret ettikleri web sitelerinin kısa sürede yüklenmesini istiyor. Sunduğunuz hizmet onların cebindeki parayı almanıza sebep oluyorsa, o kullanıcının yaşayacağı stres ve öfke 2 katına çıkabiliyor. Üstelik yükleme hızı, arama motoru optimizasyonu açısından da çok önemli.

Bekleme (loading) ekranlarıyla ilgili yapılan kullanıcı testleri hakkında internette birkaç habere de rastlamıştım. Örneğin, geçtiğimiz sene Facebook mobil uygulaması üzerinden yapılan bir A/B testte kullanıcılara cihazın varsayılan bekleme (loading) animasyonunu, bir diğer gruba da kendi tasarımları olan bekleme animasyonunu gösterdiklerinde, kullanıcıların birinde kendi hataları olduğunu düşünürken diğerinde cihazın hatalı olduğunu düşündüklerini tespit etmişlerdir.

Peki bu tür durumlara karşı ne gibi önlemler alabiliriz? Bununla ilgili birçok optimizasyon işlemi yapılabiliyor. Web sitenizle ilgili optimizasyon kontrolü yapabileceğiniz Google PageSpeed Insight olmak üzere birçok araç var. Ancak ben burada proje bittikten sonraki klasik optimizasyon işlemleriyle beraber daha çok proje süresince daha kaliteli bir proje ortaya çıkarabilmek için neler yapabileceğimizden bahsedeceğim.

Plan, Plan, Plan

Evet. Her şeyin başında planlama yapmalısınız.  Bir geliştirici olarak, yaptığınız şey, aslında bir sistemi ve temellerini tasarlamaktır. Belirlenen kurguları ve aksiyonlara hayat vermektir. İyi derecede bilgiye sahip bir arayüz geliştirici yaptığı işe böyle bakarsa, bir tasarım eline ulaştığında, Allah ne verdiyse yazmaya başlamaz.

Bir mimar, bir bina için en uçuk fikirleri kullanabilir ancak bu binayı ayakta tutabilecek dinamikleri hesaba katmadıysa, o binayı bırakın ayağa kaldırmayı, büyük ihtimalle maketini bile yapamayacaktır.

Peki neyi planlamalıyız? Bunu hazırlayacağınız arayüzün genel yapısının kurgulanması olarak düşünebilirsiniz. Aslında buna “Code wireframe”de denilebilir. Burada kullanacağınız HTML yapsını, Css ve js’de kullanacağınız adlandırma yapısını kurgulayabilirsiniz.  Ayrıca projenizi kurgularken HTML yapısını da olabildiğince yalın halde tutmaya dikkat etmelisiniz.

Adlandırmayla ilgili SMACSS ve BEM gibi  metodolojiler kullanabilirsiniz. Bunlar size adlandırma kuralları açısından kolaylık sağlayacaktır ayrıca kendi kural sisteminizi oluşturmanız açısından rehber olabilir.

Yüksek dosya boyutları bir web sitesinin yüklenmesi sırasındaki en büyük problemdir. Dosya boyutlarındaki bu yükseklik çoğu zaman doğru planlanmamış yapamadığımız vbe Dosya boyutlarının en büyük sebebi, fazladan yazılan kodlardır. Bunun sebebi de doğru bir planlama yapılmamış olması ve arayüzün kodlamaya başlamadan göz gezdirilmemiş olmasından kaynaklanmaktadır. Bunları en aza indirmekse tamamen planlanmış bir yapılanma ile mümkün oluyor.

Kendi iş sürecinizi öğrenin.

Kendi iş süreçlerinizi takip edip, hata yaptığınız, yavaşladığınız, tıkandığınız durumları ortaya çıkartın ve bunlarla ilgili önlemler alın. Çünkü bu durumlar sizi zaman baskısı içerisinde atlatma çözümlere götürecektir. Atlatma çözümlerde her zaman proje sonunda içinden çıkılamaz bir yığın haline dönüşecektir.

İş süreciniz içerisinde kullandığınız araçlar, eklentiler ve/veya dış kaynaklı kütüphaneler vs. dikkat edin. Hazırladığınız projeye ne gibi etkileri olabileceğini kontrol etmenizde fayda var. Dış kaynaklı eklenti dosyalarının web sitelerinin açılmasını 10 saniye kadar geciktirdiği durumlarla karşılaşmışlığımız var.

Arayüzü komponentler halinde kodlamaya özen gösterin

Tekrar kullanılabilir (Reusable CSS) bir yapı oluşturduğunuzdan emin olun. Komponentler halinde oluşturduğunuz bir yapıyı başka bir yere taşınabilir, böylelikle daha fazla kod yazarak css ve/veya js dosya boyutlarını gereksiz artıştan korumuş olursunuz. Ayrıca tekrar kullanılabilir yapıların yönetimi de her zaman daha kolaydır.

Hiyerarşi olarak HTML’i doğru bir şekilde konumlandırmanız ve bu konumlandırmaya uygun CSS yazmanız da tekrar kullanılabilir bir css yapısı oluşturmanız açısından çok önemlidir.

Bununla beraber CSS içerisinde çok fazla iç içe yapı oluşturmamaya dikkat edin. Birden fazla yerde kullanacağınız özelliklerin CSS içerisindeki spesifikliğini düşük tutun. Bu yapıları 3’lü hatta 4’lü iç içe yapılar içerisine yazmayın.

HTML Template oluşturun

Kendi iş akışımıza uygun olarak bir HTML template oluşturduk. Bu bizim ilk denememiz ve sürekli güncellemeye de devam ediyoruz. Amacımız dosya yapısı, görseller vs. dosya/klasör adlandırmamızı bir standarda oturtmak ve ekip içerisinde birlikte ve bireysel çalışmalarda projeyi kolay kontrol edebilmek. Bu bize hem ekip içerisindeki her projede daha projenin en başında düzenli bir yapı oluşturmanızı sağladı ve gerek sonradan projeye dahil olunacak durumlarda gerek ileride yapılacak güncellemelerde bize kolaylık sağlıyor.

CSS Preprocessorları kullanın

Daha önce şuradaki yazımda CSS Preprocessorlardan bahsetmiştim. CSS Preprocessorlar size daha dökünamte edilmiş bir CSS yazımı ve kontrollü bir yazım sağlayarak size zaman kazandırır. Gerek performan açısından gerek düzenli ve yalın bir kod yazımı açısından CSS preprocessorlar çok işinize yarayacaktır.

JavaScript Task Runnerları kullanın (GruntJS, GulpJS vs.)

Task runnerlar son zamanlarda daha sık kullanılmaya başlandı. GruntJS ve GulpJS gibi yayıgın ve kullanımı kolay olan task runer’lar sayesinde javascript, CSS ve görsellerin optimizsayonu ve daha bir çok işlemini kolaylıkla yapabilmenizi sağlıyor.

Bu dosyaların minify edilmesi yanında daha birçok işlemlerde de kullanılabliyorlar. Bununla ilgili GruntJS ve GulpJS ile ilgili plugin sayfalarından taskları inceleyebilirsiniz.

Tarayıcı testlerini göz ardı etmeyin

Tarayıcı testleriyle ilgili iş akışınız içerisinde belirli bir nokta belirleyin. Bu durumlarda ortaya çıkacak sorunların çözümüyle ilgili nasıl bir yol izleyeceğiniz konusunda emin olmalısınız.  Özellikle mobil cihazlar için hazırladığınız projelerde mutlaka mobil tarayıcı testlerini imkanınız ölçüsünde direkt hedeflediğiniz cihazlardan yapmaya çalışın. Chrome DevTools gibi araçlar çoğu zaman doğru sonuçları verse de cihazlardan kaynaklanan birçok durumu tespit etmenize engel olabiliyor.

Bu yazımızda daha çok iş süreci içerisindeki küçük hızlandırıcı etkilerden bahsetmeye çalıştım. İş alkışınızı iyi tespit etmeli, rutinlşmesini ve otomitize olması gereken alanları belirlemelisiniz. Bunu sağladığınızda iş akışınızı içerisindeki daha önemli alanlara konsantre olabilirsiniz.

Yukarıdaki birçok etken size iş akışınız içerisinde performans açısından küçük ama etkili geri dönüşler sağlayacaktır. Bazılarının direkt performans üzerinde etkisi olmasa da dolaylı yoldan, örneğin problemin doğrudan çözüm noktasının tespit edilmesi, bu yüzden oluşabilecek ek atlatma çözümleri engellemeniz saplayacaktır.

Kendinizce çözümler deneyin. İş süreciniz içerisinde hata yapmaktan korkmayın. Bazen iş başında plan yapmak, CSS ve HTML için anlamlı bir yapı oluşturmaya çalışmak size iş sürecinizde yük olarak görünebilir ancak, bunları rutine bindirdiğinizde takibi için neredeyse hiç çaba sarf etmeyeceğinizi, böylelikle enerjinizi daha doğru ve kaliteli bir şekilde kullanabileceğinizi unutmayın.

Fatih Akgöze İmza

  • Evren

    1 saniye çok iddialı olmuş:) Öyle bir dünya yok. 2.5-3 saniyeden kısa sürede açılan bir eticaret sitesi varsa ben bu sektörü bırakırım.

    • Fatih
      Fatih

      Buradaki 1 saniyeden kasıt, kullanıcıların beklentisini ifade ediyor. Bu yüzden yukarıda da bahsettiğim gibi bekleme animasyonlarıyla en azından ek süreyle kullanıcıların dikkatini farklı yöne çekerek gördüğü beyaz ekrandan sıkılmasını engellemeye çalışıyoruz. Kendi bilgisayarımızda, o 1 saniyeyi sağlasak bile, birbirinden farklı internet hizmetleri, ADSL ve Fiber internet kullanıcıları, AKK gibi uygulamalarla 1Mbit’e düşürülmüş kullanıcılar, 3G, EDGE, 4G gibi farklı hızlarda, hatta mobil internet kullanıcılarının farklı bölgelerdeki hız farklılığını da hesaba kattığınızda bunu her kullanıcı için sağlamak neredeyse imkansız. Ama bu imkansızlık insanların beklentilerini yine de değiştirmiyor. Yukarıda Facebook örneğinde de söylediğim gibi kullanıcının bekleme durumunda hatayı kendinden bilmesi ya da cihazdan bilmesi arasında çok ince bir çizgi var.

Bugün ilk makalen bizdendi.

Daha fazlası için SHERPA Blog okuru olmalısın.
Giriş Yap Ücretsiz kaydol

Benzer Yazılar

Gizle