+2017 AMP Optimizasyonları!

AMP nedir?

  • AMP, Hızlandırılmış Mobil Sayfalar Projesi’nin (AMP)
  • AMP, şu anda Google tarafından daha hızlı mobil sayfalar üretmek için yönlendirilen açık kaynaklı bir projedir

Amp optimizasyonları

Anlatmaktan ziyade AMP projesini kendisi bu makale AMP hızlı sayfaları ulaşmak için kullandığı başlıca optimizasyonlar bakacağız. Bu makalede, AMP’yi kullanarak sayfaların neden bu kadar hızlı yüklendiği ayrıntılı olarak açıklanmaktadır.

Bu optimizasyonların çoğu, AMP’yi uygulamayı planlamadıysanız ve normal sayfa hız iyileştirmeleri setinden daha sıkı kabul edilebilse bile kullanılabilir.

AMP’yi kullanmayı düşünüyorsanız, bu açıklamalar, AMP’yi işe yarayan ilkeleri anlamanıza yardımcı olabilir, böylece onları nasıl başaracağınızı daha iyi anlayabilirsiniz.

AMP’nin aşağıdaki ilkelerini tartışacağız:

1. Sadece eşzamansız betiklere izin ver

Bu, HTML’niz tarafından kullanılan veya çağrılan javascript’i ifade eder.

JavaScript değilse ertelenmiş veya asenkron yapılmış o zaman zamanında görülen olmaktan web sayfasını geciktirir.

Ertelenmiş değilse veya zaman uyumsuz olarak bilinir JavaScript hale engelleyen javascript ve bugün web etkileyen en yaygın sayfa hız konulardan biridir.

Asenkron javascript nedir?

Bir javascript uyumsuz olarak bildirildiğinde, tarayıcıya bu javascript’in yürütülmesinin sayfa oluşturma için önemli olmadığını söyler. Tarayıcı daha sonra bu javascript’in sayfayı oluşturmasını beklemesine gerek olmadığını anlamıştır.

Sayfa yüklenirken javascript başlayabilir, ancak sayfanın oluşturulmasını engellemez.

Hiçbir javascript engellemeyi sağlamak için, AMP zaman uyumsuz olmayan herhangi bir javascripte izin vermez.

AMP kullanmayacak veya kullanmayacaksanız bile, bu çok istenen bir hedeftir.

Javascript uyumsuz nasıl yapılır?

Çoğu durumda, böyle bir şeye benzeyen harici javascript çağrıları yapılacaktır …

<script src="https://siteniz.com/javascript.js"></script>

Harici javascripti uyumsuz hale getirmek için, çağrıya aşağıdaki gibi “async” eklemeliyiz …

<Script src = "https://example.com/javascript.js" async> </ script>

Bu kolay görünüyor, değil mi?

Javascript zaman uyumsuz olarak çağrıldığında maalesef bir web sayfasının pek çok özelliği doğru çalışmayabilir.

Web sayfaları bunu göz önünde bulundurarak oluşturulmalıdır, bunun ortak bir örneği jQuery gibi bir kütüphane olabilir.

JQuery’ye güvenen javascript’ler varsa, jQuery’nin kendisine dayanan javascriptlerden önce yüklenmesi gerektiği anlamına gelir.

Böyle bir durumda, tüm javascript’lerde async’in kullanılması, şeyler yüklendiğinde web sayfasında hiç değilse, bozuk veya düzgün görüntülenmemesine neden olacaktır.

İster AMP kullansanız da etmeyin …

  • İyi hazırlanmış ve performans gösteren bir sayfa, umarım asla javascript’i engelleyen render’a güvenir
  • Web sitenize üçüncü bir şahsa (ör. Seo aracı ya da analitik araç) javascript “kopyalayıp yapıştırdıysanız”, eşzamansız çalışabileceğinden emin olmanız gerekir; aksi takdirde üçüncü tarafa şikayet etmeniz gerekir. .
  • İnsanlara kendi web sitelerine “kopyalayıp yapıştırma” yapacak üçüncü şahıs javascripti sağladığınızda eşzamansız olarak çalışabilir veya araçlarınız veya hizmetleriniz, pagespeed ve web performansıyla (hemen hemen herkes için) ilgililer tarafından kullanılmayı bırakacaktır.

2. Tüm kaynakları statik olarak boyutlandırın

Amp dokümantasyonu şunu söyleyerek anlatıyor …

“Resim, reklam veya iframe gibi harici kaynaklar HTML’de boyutlarını belirtmelidir, böylece AMP, kaynaklar indirilmeden önce her bir öğenin boyutunu ve konumunu belirleyebilir.AMP, kaynakların indirilmesini beklemeden sayfanın düzenini yükler.”

Bu, karışıklığa neden olabilir, çünkü bunu okuyan insanların çoğu, bir görüntünün (width = 100 height = 200) gibi bir boyut belirtmesi gerektiğini düşünürler.

Ancak gerçek şu ki bu onların tam olarak ne anlama geldiği değil.

Boyutlar AMP’de nasıl iş görür?

Amp’de reklamlar, resimler, videolar ve iframe’ler için kullanılan özel durumlar (bir düzenin boyutunu bozabilecek şeyler) var. Çoğu durumda, bunlar için bildirilen açık boyutlar vardır, ancak bu boyutlar öğenin en boy oranını elde etmek için kullanılır; böylece yanıt verilebiliyorlar.

Bu sorunu göstermek için çözmeye çalıştıkları soruna bakmak iyi olur …

Bir web sayfası oluşturulduğunda, çoğunlukla birçok stil yeniden hesaplaması yapılır. Bu, tarayıcı indirilmeden önce bir şey boyutlarını anladığı takdirde gerçekleşmesi gereken büyük bir işin yapılmakta olduğu anlamına gelir.

Boyut bilgisi olmayan bir web sayfasından bir resim çağrıldığında, tarayıcının görüntünün ne kadar büyük olduğunu bilmek için resmi indirmesi gerekir.

Görüntü indirildikten sonra, tarayıcı görüntüyü gösterecek şekilde sayfayı ayarlamalıdır.

  • Tarayıcı sayfa koyuyor
  • Resim hiçbir boyut bilgisi olmadan çağrılır
  • Resim indirildi
  • Tarayıcı resim boyutunu alır
  • Tarayıcı, görüntünün görülebilmesi için sayfadaki her şeyi yeniden hesaplar

Tarayıcı resmin boyutunu bilseydi, yukarıdaki adımlar kümesi azaltılacaktı …

  • Tarayıcı düzenleri sayfası
  • Resim önceden hesaplanan yerde doğru şekilde indirilir ve görüntülenir

Bu adımları azaltarak sayfa daha hızlı yükleyebilir (özellikle birçok resim, reklam vb. Içeren sayfalarda).

AMP bunu nasıl yapar?

AMP, <amp-img> gibi özel etiketleri kullanarak, bir görüntünün bildirilmiş bir boyutunun, görüntünün gösterilmesi gereken mutlak sıkı ve açık bir boyut yerine kılavuz olarak kullanılabileceğini anlayabilir.

Bu, AMP olmadan nasıl yapılabilir?

Bu, planlanmış bir duyarlı görüntü çözümü ile başarılabilir. Srcset’i kullanarak tarayıcılar giderek daha fazla desteklenmektedir.

Ne tür bir teknik kullanırsanız yapın, bu çok basit ve az kullanılmış hiçbir zekayı unutmayın:

Bir görüntü 50 pikselden az ise, yalnızca genişlik ve yükseklik kullanarak açıkça boyutlandırmak gayet güzel olur.

Bu, şaşırtıcı miktarda görüntüleriniz için geçerli olacak. Okuduğunuz sayfayı bir örnek olarak kullanırsak – yazar fotoğraflarınızın resim etiketindeki yükseklik ve genişlikle açık bir şekilde boyutlandırılmış olursunuz. Çünkü gerçekten bir tarayıcı tarafından azaltılmayacak kadar küçük oldukları için.

Resimler belirli bir genişlik altında görüntülenmiyorsa, muhtemelen burada daha çok resim boyutunu belirtebilirsiniz.

Bir sayfanın 1000 pikselden daha geniş olması halinde gösterilen bir kenar çubuğumuz olduğunu söyleyelim. Bu kenar çubuğundaki görüntüler, ekranın ne kadar genişlediğine bakılmaksızın her zaman aynı boyutta olacak şekilde planlanırsa, onlara eski moda bir genişlik ve yükseklik eklemek için bir neden yoktur.

3. Uzantı mekanizmalarının görüntülemeyi engellemesine izin vermeyin

Bu, kritik oluşturma yolunu optimize etmek için tekrar eden temanın başka bir örneğidir .

Uzatma mekanizmaları nelerdir?

AMP belgelerinde kullanılan örnekler ışık kutuları, instagram gömülmeleri ve tweetlerdir.

Uzantı mekanizmaları, ek HTTP istekleri gerektiren bilinmeyen şeyleri görüntülemek için bir düzenin bir kısmını kullanır.

Bu tür şeyler çoğunlukla görüntülerin görüntülenecekleri boyutla aynı konuları doğuruyor ve bir görüntüden farklı olarak, düzen ilerledikçe devam eden çok daha karmaşık şeyler oluyor.

İdeal olarak, bu tür şeylerde bulunan düzen ve içerik için http istekleri, sayfanın oluşturulmasını engellememelidir.

Başka bir deyişle, web sayfası kendiliğinden oluşturulmalı ve bundan sonra diğer şeylerden endişelenmeliyiz. Buna, bir reklam içeren bir web sayfası örneği verilebilir. Web sayfası önce, daha sonra reklam yüklenmelidir. Web sayfası hazırlamanın gömülü şeyleri beklememesi gerekir.

Bu AMP’de nasıl işlenir?

AMP’de bu sorun, HTML’de bulunan özel bir etiketin dahil edileceğinin farkında olan bir komut dosyası çağırarak çözülür.

Buna bir örnek, bir web sayfasında bir iframe varsa, daha sonra bir amp-iframe etiketinin HTML’de olacağının farkına varacak olan amp-iframe betiği çağrılır ve böylece daha önce iframe kutusunu oluşturabilir Neyi içereceğinin farkında bile.

Bunu AMP olmadan nasıl halledebilirim?

İyi planlama ve erteleme.

Bu türden optimizasyon, bu tür şeyleri ilk sayfa yükünden erteleyerek başarılabilir.

Erteleme olarak, javascriptinize bir “erteleme” eklemeyi düşünmüyorum.

Yani sayfanın dışındaki başlangıçta görülebilen içerikler için gerekli olmayan her şeyi kendiliğinden ertelemek demektir. Bunu okuduğunuz sayfada yapıyorum ve Varvy.com’daki her sayfada bu tekniği kullanıyor.

  • Görüntüler başlangıçta görülebilir mi? Evet ise – onları arayın. Yoksa onları erteleyin.
  • Altbilginizdeki twitter widget’ı başlangıçta bir kullanıcı tarafından görülebilir mi? Hayır (altbilginizde olduğu için) – Erteleyin.
  • Işık Kutusu başlangıçta bir kullanıcı tarafından görülebilir mi? Yoksa erteleyin.

Bu ertelenmiş şey nedir?

Şeyleri ertelemek, olayları onload olayına kadar bekletme eylemidir.

Bu temel olarak, sayfanın yüklenmesine izin verin, o zaman (ve ancak o zaman) başka şeylerin olmasına izin verin.

Erteleme teknikleri hakkında geniş kapsamlı yazmıştım …

  • 4. Üçüncü taraf javascriptlerini kritik oluşturma yolunun dışında tutun

  • Yine, kritik oluşturma yoluna bir başka optimizasyon (gerçekten sayfa hızındaki en önemli kavramdır).Üçüncü taraf javascript’leri, genelde, sosyal düğmeler, analiz, seo araçları, pazarlama araçları, reklamlar vb. Şeyler için kopyalama ve yapıştırma çözümlerinin bir sonucudur.Üçüncü parti javascriptleri, son kullanıcı için çok düşüncesiz olma eğilimindedir.AMP, tüm üçüncü parti javascriptlerini engelleyerek bir web sayfasını, sayfanın görünür bölümünü görüntülemek için kesinlikle gerekli olanların haricinde herhangi bir şey beklemeden işlemek üzere boşaltır.Üçüncü tarafa özel bir önem vermenin nedeni, webmasterin senaryonun ne yaptığının kontrolünü elinde tutmamasıdır.Çoğu zaman betik eşzamanlı çağrıları veya document.write’ı kullanır ve her ikisi de render’ı önemli ölçüde engeller.

    AMP dokümantasyonları açıklayıcı bir örnek açıklar:

  • “… Beş reklamınız varsa ve her biri üç eşitleme yükü varsa, 1 saniyelik bir gecikme bağlantısı varsa, yalnızca JS yüklemesi için 18 saniyede bir yükleme süresindesiniz.”

Açıkçası üçüncü taraf javascriptleri kontrol edilmelidir.

Üçüncü parti javascript AMP’de kullanılabilir mi?

Evet.

Özel / üçüncü parti javascriptler yalnızca sanal alanlı iframe’lerde çalıştırılabilir.

AMP’nin bu optimizasyonla çözmeye çalıştığı problem nedir?

Üçüncü taraf ve özel javascript genellikle sayfa yükleme sürelerini önemli ölçüde etkileyen sorunlar yaratır.

AMP bu konuyla nasıl başa çıkıyor?

AMP, bu tür javascriptlerin, yalnızca sanal alan olan iframe’lerde çalışmasına izin vererek (sayfanın kendisiyle karışmasına engel olunca) kısıtlar.

Bu, kritik oluşturma yolunu ve ilk sayfa yükünü etkilemeyecekleri anlamına gelir.

Ayrıca, iframe ortamı tüm sayfanın çok daha küçük bir şeye sahip olması nedeniyle stil yeniden hesaplamaları da çok daha küçük olacak demektir.

AMP’yi kullanmadan bu soruna nasıl başa çıkılır?

Yapabileceğiniz en önemli şey, sayfanızın çağırdığı her üçüncü taraf javascriptinin aslında kullanılmakta olduğundan emin olmaktır. Çoğu zaman kod snippet’inin geride kalması, hiçbir şey yapmamaktır. Belki de sen ya da başkası bir aracı test edip kullanmadığına karar verdi, ancak yanlışlıkla kod parçasından ayrıldı.

Aradığınız şeyleri gerçekten kullandığınızdan eminseniz, şimdi bunları optimize etmeyi deneyebilirsiniz.

Zaman uyumsuz deneyin veya erteleme kalan JavaScripts sayfanız hala doğru fonksiyonları bakın.

Bu yöntemlerin sizin için işe yaramayacağını düşünüyorsanız, üçüncü tarafla iletişime geçin ve ürünlerini kritik oluşturma yolundan çıkarmak için bir çözümleri olup olmadığını sorun.

Bir çözüm bulamazlarsa, muhtemelen bunları web performansını öncelik alan benzer bir ürünle değiştirmeniz gerekir.

5. Tüm CSS satır içi ve boyut sınırlamalı olmalı

Kısacası, CSS 50 k’den büyük olamaz ve HTML’ye yerleştirilmelidir .

Bu, bir CSS çerçevesi kullanıyorsanız yollarınızı değiştirmeniz gerekebileceği anlamına gelir.

Unutmayın, tüm css engellenmiştir . Bu, CSS ele alınana kadar bir tarayıcıda hiçbir şeyin görüntülenemeyeceği anlamına gelir.

CSS çerçeveleri genellikle yüzlerce kilobayt CSS çağırır.

AMP’ye gitmek için, aslında tüm site için değil, sayfa için CSS yazmak zorunda kalacaksınız.

Bu sayfa örnek olarak

Tasarımımı beğendim. Güzel görünüyor, duyarlı ve hatta SVG ve animasyonları kullanarak büyük resimler var. Sanırım CSS şu anda okuduğunuz sayfa için ne kadar büyük?

Şuanlık makaleler en az 4kb CSS kullanıyor.

Evet bu doğru. 4k. Bu CSS yerinde çizildiğinden , sıkıştırma etkinleştirilmiş olduğumdan daha da azaltılıyor .

Bu, AMP’yi gerçekten kullanmadan AMP optimizasyonlarını kullanmanın harika bir örneğidir.

CSS’yi yalnızca üzerinde bulunduğu sayfa için yaptığınızda, ne kadar küçük olabileceği oldukça şaşırtıcıdır.

Sayfalarınızın ne kadar CSS’yi kullandığını görmek için resimlerin boyutlarını kontrol ediniz.

Çoğu web sitesi, özellikle çerçeveleri kullanan siteler için CSS, yüklediği CSS’nin yüzde 5-10’undan daha azını kullanan dev bir karmaşa.

Bootstrap, Foundation ve diğer CSS çerçeveleri artık gitmek için bir yol değil.

Bir çerçeveyi kullanmak zorunda olduklarını söyleyen bir tasarımcınız varsa, onları kiralamamanızı öneririm.

Çerçeveler sadece tasarımcılara yardımcı olur, aslında web sitelerini yavaşlatan şişirilmiş kodlar yaratarak tasarımcıyı ödeyen şirkete zarar verirler.

CSS önemli bir konudur. Bence CSS’yi 50 k altına kısıtlamak, web için mükemmel bir optimizasyon ve herhangi bir web sayfası için çok arzu edilen ve ulaşılabilir bir hedeftir.

AMP, CSS boyutunu nasıl sınırlar?

CSS boyutunu (50k) zorlu bir sınır belirleyerek yapar. AMP, 50k’den fazla CSS’nin geçerli olmadığı ve dolayısıyla AMP’yi kullanarak çalışmayacağından emin olarak bunu zorlar.

Bunu AMP olmadan nasıl yapacaksınız?

Web sitenizi daha hızlı hale getirmek için yapabileceğiniz en iyi şey (ve en zor şey) CSS’yi akıllıca kullanmaktır.

Buradaki asıl cevap, yalnızca sayfa için gerekli olan CSS’yi kullanmaktır.

Çoğu durumda, sitenin tamamı için ihtiyaç duyulan CSS her sayfa yükü için yüklenir.

Tipik bir WordPress şablonunu örnek olarak kullanarak bir sayfayı yüklemek için:

  • Herhangi bir sayfayı görmek için tüm yorum CSS’si (genellikle düzinelerce hatta yüzlerce satır) yüklenmelidir – bu sayfada hiçbir yorum yapılmamış olsa bile.
  • Herhangi bir sayfayı görmek için tüm eklenti CSS yüklenmelidir – sayfa bu eklentiyi kullanmıyorsa veya eklenti yönetici için bir şey olsa bile hiçbir kullanıcı görmeyecek bir şeydir
  • Herhangi bir sayfayı görmek için tüm ek stil şablonları (ör. Karanlık tema, hafif tema, vb.) Yüklenmelidir – tüm site bu şablon stilini kullanmasa bile

Umarım görüntüyü elde edersiniz, ancak Temel veya Önyükleme gibi bir CSS çerçevesi kullanıyorsanız, hiç kimsenin yüklediğiniz CSS’nin% 3’ünden% 8’ine kadarını kullanmadığı olasıdır.

Bunu değiştirmek basit bir görev değildir. Çok fazla para ve zamana mal olabilir.

Yeniden tasarım yapıyorsanız, büyük CSS çerçeveleri kullanmadığınızdan emin olun. AMP veya modern web için çalışmazlar.

Her sayfa yalnızca o sayfa için gereken CSS’yi kullanıyorsa 50k’ın üzerinde bir çok nedeni olmayacaktır.

6. Yazı tipi tetiklemesi verimli olmalı

Tipik bir web sayfasında, fontdan önce birçok js ve css dosyası yüklenir.

Yazı tipi dosyaları genellikle oldukça büyük olduğu için sayfa yükleme süreleri için bu kötü, buna karşın js ve css dosyaları daha az büyük.

Sağduyu çözümü, font dosyasının diğer tüm dosyalardan önce yüklenmesini ve böylece kaynağın mümkün olduğunca az gecikmeyle indirilmesini sağlamaktır.

Sorun, bunun bu işi kesmeksizin gerçekleştirmesini veya tüm fontu HTML’ye eklemenin gerçek bir yolu yoktur (bu sitede yaptığım gibi).

AMP dosyaları inanılmaz derecede hızlı yüklenmek için ilk kod satırından planlanır ve oluşturulur.

AMP’nin temel düşüncelerinden biri, webfont’ları en iyi biçimde nasıl ele alacağımızdır.

Tarayıcıların webfontlarıyla uğraşmasının temel yollarının hepsi idealden daha az, bu yüzden AMP bu sorunun üstesinden gelmek için bir kesmek kullanıyor.

AMP, yazı tipi tetiklemeyi nasıl verimli hale getirir?

Kesmek kullanıyor. Kesmek için en iyi çalışmak için javascript gerekiyor, ancak bir geri dönüş var.

Saldırı kendisini zaten değiştirdi ve muhtemelen değişmeye devam edeceği söylendi; bu yüzden kesmeyi tanımlamak yerine kesmenin ne yaptığını açıklayalım.

Amaç, tarayıcıların webfontlarıyla uğraşma biçimini geçersiz kılmaktır.

Daha spesifik olarak, amaç, yazı tipi isteğinin gerçekleşen ilk HTTP isteğinden kaynaklandığından emin olmaktır.

AMP temelde bir tarayıcıyı, sayfanın yazı tipini karşılayacak kadar yüklendiğini düşünmesini ister.

Bunu yaparak AMP, yükleme sürelerinin tipik olarak büyük yazı tipi dosyası tarafından ertelenmemesini sağlar.

İlk önce CSS ve Javascript dosyaları yüklenmek yerine, yazı tipi bunu yapar.

Bunu AMP olmadan nasıl yapacaksınız?

Ana yol webfontun HTML’ye yerleştirilmesidir. Okuduğunuz sayfanın fontu yeniden girildi.

Ne yazık ki, yazı tipini HTML içine yerleştirmek için pek çok dezavantaj olabilir:

  • Uzman bir şekilde yapılmazsa, HTML dosyasının boyutu çok büyük olabilir
  • Yalnızca, sayfada tek bir font / font varyantı kullanılırsa uygulanabilir
  • Bu, sayfanın görüldüğü yere bağlı olarak karışıklık gösterebilecek veya önemli olmayabilecek önemli uluslararası karakterleri dışarıda bırakabilir
  • Gerçekten olağanüstü performans gösteren bir sayfada ortaya çıkabilir
  • Bir webfontunu nasıl sıralayacağınızı (ve webfontlarını uygulamak için kullanabileceğiniz farklı yöntemleri) anlamak için, webfont seçenekleri sayfamıza bakın.Her durumda, webfont’ları akıllıca kullanmanız gerekir:
    • Bir sayfa bir webfont kullanmıyorsa, yüklemeyin.
    • Bir sayfa bir fontun “cesur” türevini kullanmıyorsa, yüklemeyin.
    • Genel tasarımınızda bir sayfada birkaç yazı tipi / font varyantına sahip olduğunuza güvenmeyin.

    Bu sitedeki web sitemizi bir yıldan fazla bir süredir, bunu yapmamamayı düşündüren sorunlar yaşamadığım milyonlarca pageload üzerinde uyarladım.

    Bu, yukarıdaki kat içeriği için yalnızca HTML dosyasına ihtiyaç duyacak şekilde bu siteyi hazırlamış olduğum için mümkün olmuştur. Varvy’deki her sayfada, HTML dosyasına girilen yazı tipi de dahil olmak üzere her şeyin üstü vardır (başta görünen içeriği görüntülemek için ek HTTP istekleri gerekmez).

  • 7. Stil yeniden hesaplamalarını en aza indirin

    Stil yeniden hesaplama nedir?

    Web sayfasında düzeni etkileyen bir şey değiştiğinde veya ölçülmesi gerekiyorsa, küçük değişiklikler için bile sayfanın tamamı yeniden hesaplanmalıdır.

    Görüntüleri bir örnek olarak kullanarak yukarıdaki konulardan biraz bahsettik, bunu kuşkusuz aşırı basitleştirilmiş bir durumla tekrar gözden geçirelim.

    Bir resimde bildirilen boyut yoksa, o zaman resim ne kadar büyük olduğunu bulmak için indirilmelidir.

    Diyelim ki bir sayfa bilinmeyen boyutta bir resimle birlikte 500 piksel yüksekliğe sahip. Resim yüklendiğinde, tarayıcı görüntünün 600 piksel yüksek olduğunu keşfeder.

    Bu durum açıkça bir stil yeniden hesaplama gerektirir.

    Bu yeniden hesaplamalar gerçekleştiğinde, sayfa hızı gittikçe birçok sorun yaratırlar.

    Ancak resimlerinizde değil, sayfanızdaki bir çok div, yüzdesi kullanan bir CSS stili içerebilir. Belki de her biri% 50 genişliğinde iki sütununuz vardır.

    Tarayıcı bunu anlamalıdır ve bunu gerçekleştirme işlemi buna mizanpaj denir.

    Mizanpaj birçok şeyi anlamalı, sadece font-size, h1, h2, divs, görüntüleri düşünün ve bu sayfa öğelerinin tipik bir sayfa yükünde birkaç kez yeniden hesaplanması gerekir.

    Bu neden oluyor?

    Birçok nedenden dolayı belki de yeni bilgi katıştırılmış bir içerik bloğu veya reklam gibi yüklenir. Bazen harici javascript yeni stiller veya animasyonlar arayabilir. Ya da en basit örneğimize dönersek, boyut belirtilmeyen bir resim bildirildi.

    Sebep ne olursa olsun, stil tekrar hesaplamaları kötüdür.

    Bir CSS çerçevesi kullanan ortalama bir web sitesinin geçmesi ve yeniden hesaplaması için neredeyse yarım meg (500k) CSS’ye sahip olabileceğini düşündüğünüz zaman daha da kötüleşirler.

    CSS ne kadar çok zaman ve çaba harcıyorsa tekrar hesaplanır.

    AMP bu yeniden hesaplamaları neredeyse tamamen ortadan kaldırma amacına sahiptir.

    Bu makalede şimdiye kadar tartıştığımız optimizasyonları kullanarak birçok yeniden hesaplamanın ortadan kaldırıldığını görebilirsiniz:

    • In AMP boyutları statik olarak bildirilmelidir. – stil yeniden hesaplamalarını kaldırır
    • AMP’de bu 50k CSS daha az olmalıdır. – stil yeniden hesaplama maliyetini kaldırır

    AMP aslında bu tip optimizasyonların üstünde ve sonrasında da geçerlidir.

    AMP, stil yeniden hesaplamalarını nasıl en aza indirir?

    Bu makalede tartıştığımız genel optimizasyonlara ek olarak AMP, tüm DOM okumalarının yazmadan önce gerçekleşmesini sağlar.

    Bu, her karenin büyük bir karmaşık yeniden hesaplamasına gerek olmadığı anlamına gelir, aslında çerçeve başına maksimum bir yeniden hesaplama yapılmasını sağlar.

    Bunu AMP olmadan nasıl yapacaksınız?

    Stil yeniden hesaplamalarını en aza indirmenin en iyi yolu, bu makalede tartıştığımız optimizasyonları izlemektir. Yukarıda da belirtildiği gibi, her biri komplikasyonları ve yerleşim sorunlarını doğaları gereği ortadan kaldırıyor.

    “Stil yeniden hesaplamalarını en aza indirin” diyerek, “sayfanızı iyi planlayın” diyerek aynı şey söz konusudur.

    Bir sayfa bir web sitesi yerine bir sayfa olarak yapıldığında, bunlar işe yarama eğilimindedir.

    Bununla kastettiğim, CSS’nin CSS’nin üzerinde olduğu sayfa için yapılmış olması yerine, tüm web sitesinden değil, her şeyden önce olması gerektiğidir.

    • Javascript dosyaları? Sayfada kullanılmazsa yüklemeyin.
    • Görüntüler? Resimlerinizi sayfa değil sayfa için planlayın – tüm senaryoları kapsayan bir site çapında resim çözümünüz yok, sayfayı sayfa olarak planlayın (veya sayfa şablonu ile sayfa şablonu) – mümkün olduğunca boyutunu bildirin.
    • Embeds? (Sosyal düğmeler gibi) Sayfadaki düğmeyi göstermiyorsanız, sayfadaki düğmeye ilişkin kod veya çağrı yok.

    Yukarıdaki şeyler sağduyuya benziyor ancak web üzerindeki hemen hemen her WordPress sitesi bunları yapıyor.

    Stil yeniden hesaplamalarını en aza indirgemek için o sayfada neler olduğunu bilmelisiniz. Sitenizin neye ihtiyacı olduğu önemli değildir, o sayfanın ihtiyaç duyduğu konularda önemlidir.

    İnsanlar sitelere bakmaz, sayfalara bakar.

  • Sitenizi tasarımcınız için daha kolay hale getirmek yerine, sayfayı kullanıcı için daha iyi yapın.

    8. Sadece GPU hızlandırılmış animasyonları çalıştırın

    Animasyon kullanımı giderek daha popüler ve yaygınlaşmaktadır. Animasyonlar söylesem, makalelerimin üstünde bulabileceğiniz gibi geniş hareketli görüntüleri düşünebilirsiniz. Gerçek şu ki animasyonlar, kullanıcı arabirimi onayları ve diğer şeyler için küçük şeyler için pek çok yerde kullanılır. Kısa süre önce yapılmış bir WordPress teması ederseniz, içinde büyük olasılıkla animasyonlar var.

    Animasyonlarımızın AMP dostu olmasını sağlamak için animasyonların GPU’ya aktarılmasını sağlamalıyız.

    GPU nedir?

    GPU, Grafik İşleme Birimi’nin kısaltmasıdır.

    CPU’nun (Merkezi İşlem Birimi) aksine, GPU, özellikle animasyonlar tarafından gerekli olan matematik için. Özel doğası gereği GPU, grafik animasyonları ile çok iyi ilişkiler içindedir.

    GPU animasyon matematiği yapabildiğinden CPU’nun tüm animasyon matematiği yapmak zorunda kalmadığı için sayfayı daha verimli bir şekilde işleyecek şekilde boşaltır, çünkü bu yarar daha da artar.

    Uzun öykü kısaysa, CPU ve GPU, tek başına CPU kullanıldığında olduğundan daha temiz ve hızlı animasyonlar oluşturabilir.

    AMP, animasyonların GPU’yu etkinleştirdiğinden nasıl emin oluyor?

    Maalesef sadece “Animasyonlar için GPU kullan” yazan basit bir komut yoktur.

    AMP’yi kullansanız da kullanmasanız da, animasyonları iki yöntemle kısıtlamak için ne yapılabilir …

    • dönüştürmek
    • opaklık

    AMP, animasyonları bu iki yöntemle sınırlar (çoğu animasyonun çalışması için kullanılabilir) ve elemanın canlandırılması için teşvik eder.

    Bunu AMP kullanmadan nasıl yaparım?

    AMP’nin yaptığı gibi.

    • Animasyonları dönüşüm ve opaklığa sınırlama
    • Animasyon elemanını tanıtmak

    Dönüştürme ve donukluğa yönelik kısıtlayıcı animasyonlar basit bir kavramdır; “teşvik” bölümü yeni görünebilir ve dikkatli davranıyor ve doğru kullanmayı planlıyor olabilir.

    Yöntemi açıklayan Google geliştirici sayfası , sürecin iyi bir genel görünümünü verir .

    9. Kaynak yüklemeye öncelik verme

    Sayfa kaynakları resim, reklam, gömülebilirlik vb. Olabilir.

    Tipik bir web sayfasında, bu kaynaklar genellikle aynı bant genişliği için savaşacakları şekilde yüklenir ve hangi kaynakların başka bir kaynaktan önce yükleneceğini bilmenin kolay bir yolu yoktur.

    Bazen iyi düşünülmüş sayfalar hala bu problemle karşılaşırlar.

    Gerçek şu ki çoğu sayfa iyi düşünülmüyor ve kaynak yükleme genel olarak sayfa hızı konusunda önemli ve yaygın bir sorundur.

    Bunun bir örneği, birkaç üçüncü parti komut dosyası yükleniyor olabilir ve önce yüklenmeleri gereken bazı şeyleri yükledikleri için değil ve kullanıcı başlangıçta görmeleri gerektiğini görmüyor olabilir.

    Yukarıdaki aynı problemi yazı tipi tetikleme bölümünde tartışmıştık. Aslında yazı tipleri sorunu iyi gösteriyor. Yazı tipi diğer kaynaklardan sonra yüklendiğinde, kullanıcının herhangi bir metni görmesini geciktirir. Yazı tipi çok büyük olduğu için değil, yazı tipi düzensiz yüklendiğinden değil.

    AMP bu konuda nasıl davranıyor?

    AMP belgelerinde şunlar bulunur:

    “AMP, tüm kaynak indirmelerini kontrol eder: kaynak yüklemeyi önceliklendirir, yalnızca ihtiyaç duyduğu şeyleri yükler ve tembel yüklü kaynakları düzenler.”

    Kaynakları yükleme şekli, sayfanın ne kadar hızlı yüklendiğinin anahtarıdır.

    Aynı içeriğe sahip, aynı resimleri, css dosyalarını, js dosyalarını ve tam olarak aynı fontu kullanan aynı web sayfası, bu kaynakların yüklenme sırasına bağlı olarak farklı hızlarda yüklenecektir.

    Sayfalarını üçüncü taraf betikleriyle aşırı dolduran birçok yeni şirket ve işyeriyle çalışıyorum ve sayfalarını ve kaynaklarının nasıl yüklendiğini temizliyorum ve genellikle 3 veya 4 saniye içinde on beş saniye sayfa yükleyebilir.

    Genellikle şaşırırlar.

    AMP, bu web siteleri ile yaptığım şeyi yapar, akıllıca kaynakları yükler.

    Üzerinde basitleştirilmiş bir örnek, javascript’den önce css yükleyen bir sayfanın, css’den önce javascript yükleyen bir sayfadan genellikle daha hızlı olması olabilir. Bu sayfa aynı zamanda katlamanın altındaki görüntüleri de önlerse, yalnızca katın altındaki ihtiyacı olan js’yi yok eder, saniyeler saniye sayfanın yüklenme süresinden kaldırılabilir.

    AMP esasen en iyi uygulamaları zorlar.

    AMP, tembel yüklü kaynakları önceden önleyerek daha ileri gitmeye çalışır.

    İlk başlarda garip gelebilir, neden açıkça tembel yüklenmiş bir kaynağı önceden hazırlardınız?

    Bunu resmi olmayan bir şekilde açıklayacağım: orada bir web sayfası yüklenirken bir tarayıcı yapıyor üç şey var …

    • Şeyler almak
    • Işi yapmak
    • Hiçbir şey yapmadan

    Bu ses kadar basit, akıllı kaynak yüklemede anahtardı.

    • Sayfa “şeyleri elde etmek” iken, kullanıcıya içerik görüntülemek için mümkün olduğunca az şey almalıydı.
    • Sayfa “şeyler yapıyor” iken, kullanıcıya içerik görüntülemek için mümkün olduğunca az yapmalıdır
    • “Hiçbir şey yapmıyor” olsa da yakında ihtiyaç duyulacak şeyler yapmak için harika bir zaman.

    Çoğu web sayfasıyla ilgili bugünkü sorun, her şeyin bir arada sıkıştırılması.

    Her şey aynı anda “şeyler edinmek” için çağrılır; bu demektir ki, bir kerede milyonlarca şey yapmak zorunda olduğu için “şeyler yapıyor” kısmı gerçekten komplikasyona uğratan bir kerede her şey alınıyor demektir.

    Ancak tarayıcı “hiçbir şey yapmadığında” büyük bir fırsat penceresi var.

    AMP, sayfanın verimli bir şekilde yüklenmesine izin verecek şekilde bu pencere zamanlarını akıllıca kullanır.

    Bunu AMP olmadan nasıl yaparım?

    Gerçek şu ki, kaynak yüklemeyi önceliklendirmek için AMP’ye veya başka bir şeye ihtiyacınız yok.

    Sayfalarınızın aynı kaynaklarla daha hızlı yüklenmesine yardımcı olacak, genel olarak takip edebileceğiniz bir süreç var.

    10. Sayfaları anında yükleyin

    AMP son derece hızlı (çok anında) yüklenen web sayfalarını elde etmek için önceden bağlantıyı kullanır.

    Bağlantı öncesi nedir?

    Resmen şu şekildedir :
    “Preconnect bağlantı ilişkisi türü, gerekli kaynakları getirmek için kullanılacak bir kökeni belirtmek için kullanılır. DNS aramasını, TCP el sıkışma ve isteğe bağlı TLS anlaşmasını içeren erken bir bağlantıyı başlatmak kullanıcı aracısının maskesini maskelemek için kullanılır Bir bağlantı kurmanın yüksek gecikme maliyeti. ”

    Biraz kıralım … preconnect tarayıcılara anlatmanın bir yoludur:

    “Merhaba, Kısa sürede bu kaynağa ihtiyaç duyacağımızı bilmelisin diye düşündüm, neden devam etmiyorsun ve bağlanmaya başlamıyorsun?”

    Bunu yaparak tarayıcılar, bu bağlantıyı yapmanın en uygun zamana karar verebilirler.

    Bu, kaynağın ihtiyaç duyulduğunda gitmeye hazır olmasını sağlar, çünkü tüm ağ ayrıntıları zaten yapılır (dns / handshake / ssl)

    Önceden tedarik nedir?

    Önceden hazırlama ile, aslında tarayıcıya html, kaynaklar indirerek, DOM oluşturarak, CSSOM’u ve düzenini indirerek bir web sayfası oluşturup sunarak hareket etmesini isteyeceksiniz .

    Bir sayfa ön provizyonlandığında, tarayıcı tüm işleri zaten yaptığından çoğu durumda kullanıcıya anında görünecektir.

    Preconnect, önceden hazırlama ve dns ön getirim gibi bazı diğer tarayıcı ipuçlarının hepsinde ortak bir sorun var.

    Genellikle yanlış kullanılırlar.

    Çok sağlam görünüyorlar! “Sadece her şeyi önceden verelim!” İnsanlar düşünüyor ancak … sorun şu ki sayfalarınızın daha yavaş yüklenmesine, daha fazla cpu / pil kaynağı kullanmasına ve ayrıca bu ipuçlarının kötüye kullanılması durumunda eşyalarınızı oldukça kötü hale getirebilirsiniz.

    Bu AMP’de nasıl kullanılır?

    AMP, önyükleme ve önizlemeyi daha akıllı bir şekilde kullanır.

    Her şeyi önceden sunmaktan ziyade, yalnızca içerik ve kaynakların üzerinde yer alır ve AMP sistemi öngörülebilir olduğundan, ön hazırlık öğesinin tamamı AMP vasıtasıyla daha iyi çalışır.

    AMP sayfaları, çok fazla CPU döngüsü, hatta üçüncü parti iframe’ler gibi çok fazla işlemci kullanan şeylerin önceden yüklenmesini reddetmek suretiyle bir adım daha ileri gidiyor.

    Bunu AMP olmadan nasıl başaracağım?

    Preconnect, dns-prefetch ve öngerekleme kullanımı AMP olmadan yapılabilir.

    Kaygan bir eğim buldum ve nadiren beni işe alanlar için yapıyorum.

    İnanılmaz fayda sağladıkları durumlarda var, ancak bu durum düşündüğünden çok daha nadir.

    Varvy’de “ön” bir şey kullanmıyorum. Bir sayfa gerçekten optimize edildiğinde, ön hazırlık yapmaya duyulan ihtiyacın ortadan kalktığını buldum.

    Bu makaleyi örnek olarak kullanmak için:

    • Yazı tipi inline edildi
    • CSS inline edilmiş
    • Sadece bir satır içi js kullanıyorum
    • Üstte, imajlar da gösterilir.

    Prefetre, render veya başka herhangi bir şey için kaynak yok çünkü bir tarayıcı html dosyasına sahip olduğu sürece, sayfayı görüntülemek için gereken her şeye sahiptir.

    Bunu, ön getirim veya önceden yükleyici gibi tarayıcı ipuçlarına olan ihtiyacımın yerini alan iyi bir strateji olarak görüyorum.

    Web sayfalarınız çok fazla kaynağa dayanıyorsa, kaynaklarınızın yüklenme biçimini azaltmanın veya en iyi duruma getirmenin, ön getirme veya yükleme kullandığınızdan çok daha iyi bir strateji olduğunu buldum.

    Sayfa yüklemenizi optimize etmek ve ince ayar yapmak için harcanan zaman, harcanması gereken zamandır ve sisteminizin tamamında yarar sağlar.

    AMP optimizasyonları yalnızca AMP için değildir

    Bu makale boyunca AMP optimizasyonlarının gerçekte AMP kullanan veya bulunmayan herkes tarafından kullanılabileceğini göstermeye çalıştım.

    AMP’ye adil olmak için …

    AMP ayrıca özel ön belleğe alma ve bunun arkasında Google tarafından desteklenen bir CDN’ye sahiptir.

    Bu, birçok yararı olan AMP’yi kullanmak için çok güçlü bir motivasyondur.

    AMP naylı çiftlerine adil olmak için ….

    Amp temelde AMP kullanmadan büyük bir kısmı elde edebilen belirli sayfa hız kurallarını zorlayan bir sistemdir.

    AMP sayfaları karmaşıklık katar ve öğrenilmelidir. Bazıları doğru şeyleri yapmak için doğru yolu öğrenmenin daha iyi olduğunu söylüyor.

    Şahsen AMP’yi ne diyeceğim (Hakan YERLİKAYA)?

    AMP bana fayda sağlamıyor çünkü sitem (şu an okuduğunuz) AMP olmadan daha hızlı yükleniyor.

    Bu şahsen benim için vaat sunmadığı anlamına geliyor.

    Ancak…

    Startuplar ve köklü işletmeler, sitelerini daha hızlı hale getirmek için beni kiralamaktadır.

    Çalıştığımız neredeyse her işte aynı sorunlar (formlar, seo araçları, analitik araçlar, pazarlama araçları gibi şeyler için üçüncü taraf betikleri) var ve özellikle AMP’nin gelecekteki olasılıkları konusunda mutluyum; Analitik veriler gibi şeyler için sistem.

    Ayrıca, AMP’nin aldığı dikkatin, kullanıcılarına performans göstermeyen bir kod sağlayan üçüncü parti tabutların tabutundaki bir başka çivi olduğunu da seviyorum.

    Son bir yıl içinde, web’deki en büyük isimlerden bazılarının büyük müşteriler kaybettiklerini gördüm çünkü kod seçenekleri çok zayıftı ve performansı öncelik olarak düşünmüyorlardı.

    AMP’den maksimum parayı alacak olan insanların, platformlarının bir parçası olarak diğer içeriklerle etkileşime girmesi gereken insanlar olacağına inanıyorum. Facebook’un gösterdiği makaleleri, Twitter, Pinterest’i düşünün; çünkü bu şirketlerin tümü çoğunlukla diğer kaynaklardan gelen diğer içerikleri paylaşmaya dayalıdır.

    Bu nedenle, AMP kendileri için mükemmel bir avantaj sağlar. AMP’den büyük fayda sağlayacak diğer şirketler grubu açık bir haber ve Facebook, Twitter, Pinterest, vb. Yerlere sahip olmak isteyen güncel olay yayıncıları verilerini kullanıyor.

    Daha hızlı sayfa

    Bununla birlikte, sayfalarınızı daha hızlı hale getirmek, daha memnun kullanıcı, daha fazla kazanç ve herkes için daha iyi bir internet anlamına geliyor.

Kısa Özet
Yayın Tarihi
Konunun Adı
Neden Google AMP Sayfaları o Kadar Hızlı
Verilen Puan
51star1star1star1star1star

Leave a Reply

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir