İnternetin oluşturulmasından bu yana, ortalama dosya boyutları sürekli olarak artmaktadır. Kilobayt olarak başlayan şey megabaytlara ulaştı (evet, çoğul) ve dosyalarımız sadece büyümeye devam ediyor.
Bu olgu ilk bakışta rahatsız olmazken, performans ve sürdürebilirlik üzerindeki etkisi korkunç. Yaşlanma cihazlarını, bant genişliği kısıtlamalarını veya genel olarak yavaş hızları ekleyin… ve daha büyük bir problemimiz var.
Neyse ki, sadece dosya boyutlarımız üzerinde değil, sayfalarımızın tarayıcıda nasıl işlendiğini de kontrol ediyoruz. Bu tür bir kontrol, web geliştiricilerine kendimizi bu sorunu hafifletmeye yardımcı olma şansı verir ve süreçte daha iyi performans için kodumuzu optimize eder.
ABD'deki çoğu internet bağlantısının bu günlerde oldukça hızlı olduğu zaman ilgisizliğini tamamen anlıyorum. Demek istediğim, eğer her şey yolunda gidiyorsa, neden rahatsız oluyor?
Performans ve optimizasyon, içeriği ne kadar hızlı indirebileceğimizden daha fazlasıdır. Ayrıca, kodumuza bakmak için zaman ayırmak zorunda kalabileceğiniz birkaç SEO ve UX avantajı da vardır. Daha iyi performans için kodumuzu optimize ederek dosya boyutlarını düşürmenin, bant genişliği maliyetlerimizi ana bilgisayar olarak azaltma ve kullanıcı düzeyinde de bant genişliği kullanımını azaltma (ISP / hücresel veri başlıkları) azaltma avantajı da vardır.
Modüler kod genellikle daha fazla seçenek biçiminde bloat ekler. Burada, kodlarımızın mümkün olduğunca çok sayıda ortak parçasını birleştirmek açısından modüler düşünmek istiyoruz. Eğer iki CSS sınıfını bir araya getirebilir ve aynı sonucu sağlamak için daha az kod kullanırsak, yapmalıyız.
Temel HTML ve CSS söz konusu olduğunda modülerlik önemli değildir, ancak JavaScript'in daha karmaşık dünyasına girdiğinizde, çok fazla şişkinliğe sahip olmak, özellikle de mobil cihazlarda size zarar verebilir.
Bağımlılık istekleri, çoğu sayfa yükleme hızını yavaşlatan en büyük faktördür. Her ek talep ayrıştırma ve indirme işlemine bloat ve başka bir karmaşıklık katmanı ekler. Stil sayfanızdaki görüntülerin de sayıldığını da unutmak çok kolaydır, bu nedenle bunları sınırlandırdığınızdan ve mümkün olduğunda sprite veya SVG gibi alternatif optimizasyon yöntemlerini kullandığınızdan emin olun.
Dış bağımlılıklar konusuna odaklanırken, web siteniz minimum düzinelerce talep gerektirecek kadar büyükse… Bir CDN kullanmayı düşünmek için zaman olabilir. İçeriğinizi dağıtmak için bir CDN kullanmak, dosya boyutlarını ve / veya yükleme sürelerini, fazladan HTTP isteklerini bir araya getirecek kadar azaltmayacaktır, ancak bu, yavaş sunucu bağlantılarını en azından denklemin dışında kaldırabilir.
Geliştirme ve üretim seviyesi kodlarınızı karşılaştırırken çok farklı bir fark olmalı. Bu adımı tek başına almak, bazen dosya boyutlarındaki en büyük düşüşü tahtadan görebilir.
Bugün, geliştiricilerin, özellikle büyük ölçekli projelerde “üretim” veya “gelişim” ortamlarına atıfta bulunmalarını görmek tipik bir durumdur. Ama aynı zamanda şeylerin küçük ucunda da yararlıdır. İki ortam arasındaki en büyük fark, görüntü sıkıştırma ve kod küçültme / sıkıştırma ile görülebilir. Sonuç olarak, üretim ortamımızın mümkün olduğunca yalın ve hızlı olmasını ve geliştirme ortamımızın aynı olması gerektiğini, sadece görüntü / kod sıkıştırma optimizasyonunun eksi olmasını istiyoruz.
Photoshop'un “Web için kaydet” sıkıştırması gibi yerleşik araçları kullanarak görüntüler için iyi bir başlangıç noktası olabilir. Olması gereken çok fazla bilgi var. başka yerde araştırıldı görüntü formatları, sıkıştırma algoritmaları, kalite kontrol ve en iyi uygulamalarla ilgili konuşmalar ile.
Kod için, en iyi sıkıştırma kullanımı genellikle birlikte çalıştığınız dile bağlıdır. Kodun sıkıştırılmasının, kodunuzu anlamaya çalışan diğer insanlara yardım edip etmediği ya da acıtıp bozmadığı da oldukça tartışmalıdır, ancak bu başka bir zaman için bir konuşmadır. Düz HTML ve CSS söz konusu olduğunda, Google'ın htmlcompressor ve YUI Kompresör CSS için.
Bazen yazdığımız kod, zincirdeki en yavaş bağlantıdır. Verimsiz CSS veya şişirilmiş JavaScript, yükleme sürelerini sandığınızdan daha fazla zarar verebilir. Bu Mozilla post, yalın CSS seçmenlerinin yazılmasının önemi ve tarayıcıların bunları nasıl işlediğini açıklamak konusunda çok detaylı. Kısacası, tam yolun bir zincirler zincirinin aşağısına yazılması, bunun yerine sadece en küçük benzersiz tanımlayıcıyı kullanmaktan çok daha az verimlidir. İkisi de stili aynı öğeye yönlendirir, ikincisi işi çok daha hızlı yapar.
JavaScript, kötü yazılmış CSS'den bile daha kötü olabilir ve birçok durumda kolayca gözden kaçabilir. Kaynağa gerçekten derinlemesine bakmadan, projenize harici bir JS kütüphanesini kaç kez kopyalayıp yapıştırdınız? Typekit bunun harika bir örneğidir, çünkü sunucuları durduklarında fontlarını kullanarak bir web sayfasını dizlerine getirebilir ve 30 saniye veya hatta fazladan bir ek yükleme süresine neden olabilir.
Neyse ki, bu tür olaylar nadiren gerçekleşir, ancak Google Analytics’te olduğu gibi mümkünse JavaScript’i sonlandırmak iyi bir uygulamadır. Bunu yapmak, tarayıcının baş dosyalarını (CSS, HTTP istekleri, vb.) Ayrıştırmasına ve JavaScript'in işleri yavaşlatmaya başlamadan önce işaretlemeyi görüntülemesine izin verir.
Daha yalın CSS seçmenleri yazma ve bloatı minimumda tutma hedefimiz doğrultusunda, etkin HTML yazmanın da bir önceliği olması gerekir.
CSS sıfırlamaları genellikle tüm ortak öğeleri hedefler ve üzerlerinde stilleri “sıfırlamaya” zorlar. Dolayısıyla, bu ekstra div hedeflemiyor olsanız bile, dolgu ve kenar boşluğunu en aza indirgemek zorunda kalmaya devam ediyor. Tipik olarak, bir ekstra div ya da iki gerçekten bir şey zarar vermez. Onlarca düzinelerce bitirmeye başladığınızda işler çıldırır. HTML5 özelliklerine daha fazla elemanın girmesiyle, bu alanda da çok daha fazla esnekliğe sahibiz.
Google, interneti toplu olarak şekillendirmeye öncelik verdi. Arama sonuçlarında öne çıkan konumları işgal etmek için sayfalar artık nasıl oluşturulduklarıyla ilgili birçok farklı özelliğe çok dikkat etmelidir. Çok fazla harici kaynak aramak, saçma büyük görüntülere sahip olmak, ya da iyi yazılmış bir JavaScript’e sahip olmak siteyi sıralamada bir yere çekebilir.
Neyse ki, iyi bir arama sıralaması için gereksinimleri iyi geliştirme uygulamaları etrafında inşa edilir gibi tüm iyi niyetle. Google ayrıca bir çok derinlikli rehber Daha iyi SEO için sitenizin farklı yönlerini optimize etmek - aynı zamanda fantastik geliştirme uygulamalarını teşvik etmek için de olur.
Kodumuzu optimize ederken, sadece dosya boyutlarını düşünmemeli, aynı zamanda nasıl okunacağını da düşünmeliyiz; ya tarayıcılar ya da başka insanlar tarafından. Günümüzde çok kısıtlayıcı veri sınırlarını uygulayan birçok hizmet sağlayıcı ile mobil kullanım da göz önünde bulundurulmalıdır.
Tüm bu optimizasyonu gerçekleştirmek zaman alabilse de, yalnızca tarayıcıda ve mobil cihazlarda daha iyi bir performans sunmadığı için, aynı zamanda daha iyi geliştirme uygulamalarını teşvik etme ve içeriğinizi daha yüksek bir sıralama elde etme şansına sahip olduğu için kesinlikle bir çabadır. Google gibi arama motorlarında.
Bir dahaki sefere fırlatmaya hazırlanırken, görüntülerinizi bir sıkıştırma motoruna atıyorsunuz… Kaç megabaytın tıraş olabileceğine şaşırabilirsiniz!
Özellikli resim, modüler hız görüntüsü Shutterstock üzerinden.