WordPress Siteniz Neden Bu Kadar Yavaş Ve İşleri Hızlandırmak İçin Kullanışlı Bir Kılavuz

Bu gönderiye, bunun yalnızca başka bir genel “WordPress Nasıl Hızlandırılır” makalesi OLMADIĞINI bildirerek başlamak istedim.

Web'de zaten bulunabilecek hiçbir şeyi kusmayacağım. Size bir önbellek eklentisi kurmanız, sıkıştırmayı etkinleştirmeniz, css/js'nizi küçültmeniz vb. gerektiğini söylemeyeceğim.

Sonuçta, bunları nasıl yapacağınızı zaten biliyor olmalısınız. Ve eğer yapmazsanız, bu genel bilgiyi yüzlerce başka blogda bulabilirsiniz.

Bunun yerine, bu makale, kendi WordPress blogumu hızlandırmak ve temelde hileli erişimlerin sunucumu çökertmesini önlemek için geçen ay içinde uyguladığım özel/yarı özel her şeyi içeriyor.

Ve bunun “az bilinmesinin” nedeni, birazdan anlatacağım tekniklerin, gördüğünüz trafik kalıplarına bağlı olarak kendi blogunuza çok özel olacağıdır.

Not: Yavaş bir blogunuz varsa ve bir web sitesini hızlandırmanın teknik yönlerinden herhangi biriyle gerçekten uğraşmak istemiyorsanız, muhtemelen WP Engine gibi bir hizmete kaydolmalısınız .

Bu adamlar WordPress barındırma konusunda uzmandır ve blogunuzun olabildiğince hızlı çalışmasını sağlar. Ama doğal olarak, bunun bir bedeli var. Bu yazı kafanızı aşıyorsa onlara bir göz atmalısınız :)

Her neyse, size bloguma yaptığım şeyi nasıl ve neden yaptığımı açıklamadan önce, aşağıda anlatacağım WordPress ve önbelleğe alma ile ilgili birkaç temel kavramı anlamalısınız.

Bazı İlginç WordPress Gerçekleri

Diyelim ki WordPress'i nasıl hızlandıracağınızla ilgili tüm yönergeleri zaten takip ettiniz. Blogunuz hareketli hissediyor. Webpagetest.org, blogunuzun cehennem kadar hızlı olduğunu söyler. Her şey yolunda değil mi? Mutlaka değil .

Ben de blogum için tam olarak aynı şekilde hissediyordum. Sonuçta, standart hızlandırma protokollerinin çoğunu takip ediyorum. Çok az eklenti çalıştırıyorum ve bir insan okuyucunun bakış açısından blogum normal kullanımda oldukça hızlı hissediyor (Blogumu yavaşlatan şey reklam ağlarıdır, bu yüzden reklamları en son ben yüklerim).

Ancak daha sonra CPU kullanım grafiklerimi analiz etmeye başladım ve düşük ila orta trafik seviyelerine rağmen genellikle yüksek sunucu yükü dönemleri fark ettim. Bazen sunucum uzun süreler boyunca kullanılamaz veya yanıt vermez hale geliyordu.

Dikkat edin, bu istatistiklere dikkat etmeye başlamamın tek nedeni, bir süre önce çevrimiçi mağazamı blogumla aynı sunucuda çalıştırıyor olmamdı. Ve periyodik olarak müşterilerin mağazanın aşırı yavaş olduğundan şikayet etmesini sağlardım. Sonunda biraz araştırma yaptığımda, optimize edilmiş, tamamen önbelleğe alınmış WordPress blogumun sunucumu dize getirdiğini gördüm!

Hikayeden çıkarılacak ders? Bir hız testinin size blogunuzun hızlı olduğunu söylemesi, her şeyin iyi olduğu anlamına gelmez.

İşte WordPress ve WP Super Cache ve W3 Total Cache gibi önbelleğe alma eklentileri hakkında bilmeniz gereken bazı eğlenceli gerçekler.

• WordPress 404 yanıtları yavaş . Blogunuz var olmayan bir sayfaya her erişim sağladığında, zayıf sunucunuzun WordPress'i yüklemesi, bir sürü php kodu çalıştırması, bir sürü MySQL sorgusu yapması ve ardından özel WordPress 404 sayfanızı tükürmesi gerekir. Bu çok kaynak yoğun bir görevdir ve önbelleğe alma yardımcı olmayacaktır.
• URL'de GET parametreleri olduğunda önbelleğe alma eklentiniz çok iyi çalışmıyor. Örneğin, e-posta listeme bir patlama gönderdiğimde blogumun yavaşladığını fark ederdim. Statik dosya önbelleğe alma ile teorik olarak, sunucum yenilmez olmalıdır.

  Ancak Aweber URL'ye izleme parametreleri eklediğinden, dosyalarımın hiçbiri süper önbelleğe alınmadı. Sonuç olarak, WordPress'in yepyeni bir önbellek dosyası oluşturması (zaten mevcut olmasına rağmen), onu sıkıştırması ve her seferinde göndermesi gerekir. En kötü yanı, bu önbelleğe alınmış dosyaların yalnızca bir kez kullanılmasıdır ve bu da onu sunucu kaynaklarının israfına neden olur.

• Hileli erişimler yavaştır. Hileli erişimler WordPress'in varsayılan olarak yüklenmesini gerektirdiğinden, sitenizi kötü isteklerle spam yapmaya karar veren kötü bir bot veya tarayıcı blogunuzu oldukça kolay bir şekilde kapatabilir.
• Önbelleğe alma eklentinizde bir hata veya blogunuzu kurma şeklinizle uyumsuzluk olabilir . Örneğin, 3 yıl boyunca günlüklerimi izlemeye başlayana ve kodda bir hata fark edene kadar WP Super Cache'in doğru şeyi yaptığını düşündüm. İşleri kurma şeklim nedeniyle, WP Super Cache'in önbelleğimi çok sık boşalttığı bir sorunla karşılaştım.

Yukarıdaki madde işaretleriyle yapmaya çalıştığım kilit nokta , blogunuzda standart olmayan bir erişim olduğunda, WordPress blog kurulumunuz nasıl olursa olsun , çok fazla sunucu kaynağı kullanmasıdır . Ve sunucunuzu diz çöktürecek olan şey, normal trafik değil, bu tür erişimlerdir.

Hileli Erişimleri Algılama

WordPress blogunuzu optimize etmenin ilk anahtarı, blogunuzun aldığı trafik modellerini anlamaktır. WordPress kullanıcılarının %99'unun bunu yapmadığına bahse girerim. Bunun yerine, çeşitli eklentileri körü körüne takip edip yüklerler ve her şeyin düzgün çalıştığını varsayarlar. Kusura bakmayın bende aynı durumdaydım.

Yani ilk adım, neler olup bittiğini bulmak. Bunu yapmanın birçok yolu vardır, ancak en kolay yol, WP SuperCache eklentisinin sağladığı hata ayıklama modunu kullanmaktır. Bu mod ne işe yarar? Temel olarak, bir erişim doğrudan WordPress tarafından işlendiğinde (kaynak yoğun), WP Süper Önbellek günlüğünde görünecektir. Bu modu nasıl etkinleştireceğiniz aşağıda açıklanmıştır.

WP Süper Önbellek Eklentinizin hata ayıklama sekmesi altında, "Hata Ayıklama Etkin" onay kutusuna tıklamanız yeterlidir ve hazırsınız!

Günlüğe kaydetme etkinleştirildiğinde, sizi WordPress trafiğinizi ayrıntılandıran bir dosyaya yönlendirecek olan “günlük dosyası” bağlantısını tıklayabilirsiniz. Aşağıdaki metne benzer görünecektir.

15:03:46 /?utm_source=fwisp.com supercache dir:
15:03:46 /?utm_source=fwisp.com No wp-cache file exists. Must generate a new one.
15:03:46 /?utm_source=fwisp.com In WP Cache Phase 2
15:03:46 /?utm_source=fwisp.com Setting up WordPress actions
15:03:46 /?utm_source=fwisp.com Supercache caching disabled. Only using wp-cache. Non empty GET request.
15:03:46 /?utm_source=fwisp.com USER AGENT (Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)) rejected. Not Caching

Unutulmaması gereken önemli nokta, bu günlükte herhangi bir şey gördüğünüzde bunun kötü bir şey olduğudur çünkü bu WordPress'in çalışması gerektiği anlamına gelir. Ve WordPress bir kaynak domuzu olduğundan, mümkün olduğunca az iş yapmasını istersiniz.

Günlüklerde Neler Aranır?

WP Super Cache günlükleri harika çünkü size olan biten her şeyi anlatıyorlar. Ancak, ne arayacağınızı bilmiyorsanız, çok miktarda bilgi çok zor olabilir. İşte bu günlüklerde dikkat etmeniz gerekenler.

• 404 Hataları – Temel olarak bunlar, blogunuzda bulunmayan sayfalara erişimlerdir. WordPress tarafından işlenen her 404 erişim, çok fazla sunucu kaynağı kaplar, bu nedenle mümkünse bunları tomurcukta kesmek istersiniz.
• Tek Seferlik Erişim – Bunlar, sunucunuzun yalnızca bir kez kullanılacak sayfaları önbelleğe almasına ve sıkıştırmasına neden olan isteklerdir (bundan sonra daha fazlası)
• Garip Trafik Patlamaları – Bunlar genellikle blogunuzu aynı anda etkileyen botlardır.
• Garip Önbelleğe Alma Davranışı - Önbellekleriniz gerektiğinde temizleniyor mu? Her koşulda her şey düzgün şekilde önbelleğe alınıyor mu?

2 haftalık bir süre boyunca blog trafiğimin kaydını tuttuktan sonra, aşağıda anlatacağım pek çok verimsizlik keşfettim.

Botlar Arşivlerimi Çekiyordu

Yaptığım ilk şey, yüksek CPU yükü dönemleri için sunucu günlüklerime bakmaktı. Daha sonra, komik bir iş olup olmadığını görmek için aynı dönemlerde süper önbellek günlüklerimi analiz ettim. Görünüşe göre iki günde bir, bir grup robot aynı anda blogumun tüm arşiv sayfalarını dövecekti!

Bu arşiv sayfaları varsayılan olarak önbelleğe alınmadığından, sunucu yükümü hızlandırmak için bir dizi eşzamanlı erişim yeterliydi ve işleri son derece yavaşlattı. Ve bazen sunucumun çökmesine bile neden oldu.

Bu yüzden HTML çıktıma daha yakından baktım ve WordPress başlığımın bir parçası olarak bir sürü arşiv bağlantısına sahip olduğumu fark ettim. Bu nedenle, botlar ve diğer web tarayıcıları gelip arşivlere göz atmaya çalışacaktı.

Büyük bir Googling'den sonra, birkaç başka web yöneticisinin de benzer sorunlar yaşadığını gördüm.

Sitenizde birçok kez yükleme sorunları gördüğümüzde, proxy sunucu IP'leri için çok sayıda isabet vardır ve teori, bu proxy'lerin sitenizi önbelleğe alması ve tüm bu arşiv bağlantılarına isabet etmesidir. Sitenizin yükleme sorunlarına neden olduğunu gördüğümüz IP'lerin çoğu, biri siteye eriştiğinde içeriği önceden getiriyor gibi görünen kurumsal, eğitim ve Devlet/Askeri proxy IP'leridir.

Çözüm: Blogunuzun başlık kodunda “wp_get_archives” php ifadesinin olup olmadığını kontrol edin ve kaldırın. Bu küçük pasajı sildikten sonra tüm arşiv erişimlerim kayboldu.

Botlar Var Olmayan Dosyalara Erişiyordu

Fark ettiğim ikinci önemli şey, sunucumda var olmayan dosyalara erişen bir grup bot olduğuydu. Sorun şu ki, bir dosya erişimi her gerçekleştiğinde, sunucunuzun WordPress'i yüklemesi, bir sürü PHP kodu çalıştırması ve ardından bir 404 sayfası yayınlaması gerekiyor.

Bu sorunun çözümü .htaccess(ne olduğunu bilmiyorsanız Google bunu) dosyasını düzenleyip aşağıdaki satırları eklemektir.

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !(robotlar\.txt|site haritası\.xml(\.gz)?)
RewriteCond %{REQUEST_FILENAME} \.(css|js|html|htm|rtf|rtx|svg
|svgz|txt|xsd|xsl|xml|asf|asx|balmumu|wmv|wmx|avi|bmp|sınıf|divx|doc
|docx|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|mdb|mid|midi|mov|qt|mp3|
m4a|mp4|m4v|mpeg|mpg|mpe|mpp|odb|odc|odf|odg|odp|ods|odt|ogg|pdf
|png|pot|pps|ppt|pptx|ra|ram|rar|swf|tar|tif|tiff|wav|wma|wri|
xla|xls|xlsx|xlt|xlw|zip)$ [NC]
RewriteRule .* – [L]

Bu satırlar .htaccess dosyanıza eklendikten sonra, web sunucunuz önce bir dosyanın olup olmadığını kontrol edecektir. Değilse, WordPress'i YÜKLEMEDEN bir 404 yanıtı verecektir.

Botlar Var Olmayan URL'lere Erişiyordu

WordPress'in yazılma şekli hakkında talihsiz olan şey, veritabanınızda olmayan bir makaleye erişim varsa, sunucunuzun WordPress'i yüklemesi, bir sürü PHP kodu çalıştırması ve bir dizi MySQL araması yapması gerekecek. 404 yanıtı.

Günlüklerinize dikkatlice bakarsanız, muhtemelen WordPress'e ulaşmadan önce hariç tutabileceğiniz belirli erişim kalıplarını fark edeceksiniz.

Örneğin, bir grup botun siteme www.mywifequitherjob.com/some-article/www.facebook.com/like.php/… URL'siyle eriştiğini fark ettim. Ve her seferinde sunucum WordPress'i yükler ve bir 404 yanıtı verir.

Bu istekleri WordPress'e yaptırmak yerine, .htaccess dosyama aşağıdaki satırları ekledim.

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} www\.facebook\.com/plugins [NC]
RewriteRule .* 404.html [L,R=404]

Yukarıdaki satırlarda, web sunucumun URL'de “www.facebook.com/plugins” aramasını ve WordPress'i yüklemeden hemen 404 yanıtı vermesini sağlıyorum. Günlüklerinizi incelerken, yukarıda anlattığım gibi birçok hileli erişim bulacaksınız. Her biri için bir .htaccess kuralı yazın ve bu erişimler artık sunucunuza yüklenmeyecektir.

Botlar Yorum Bağlantılarımı Çekiyordu

GET parametreli URL'lerin önbelleğe alma eklentiniz tarafından farklı şekilde ele alındığını söylediğimi hatırlıyor musunuz? "Yorumu yanıtla" parametre seti ile makalelerime vuran bir sürü bot olduğunu keşfettim.

Bu olduğunda (önbelleğe alma ayarlarınıza bağlı olarak), wordpress yüklenir ve muhtemelen bir daha asla erişilemeyecek olsa da önbelleğe alınmış/zip dosyası sunulur. Bu bir kaynak israfıdır.

Günlüğümden Alınan Örnek
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 No wp-cache file exists. Must generate a new one.
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 Gzipping buffer.

Çözüm, bu GET parametreleriyle tüm botları ve tarayıcıları ana makale sayfasına yönlendirmektir. İşte .htaccess dosyama eklediğim kod.

RewriteCond %{QUERY_STRING} answertocom
RewriteCond %{HTTP_USER_AGENT} ^(.*)(bot|tarama|örümcek|slurp) [NC]
RewriteRule .* https://mywifequitherjob.com%{REQUEST_URI}? [L]

Bu kod, "replytocom" GET parametresini arar ve ardından WordPress'e erişimi sunmadan önce bu parametreyi nihai URL'den kaldırır.

Tarayıcılar, Sonda Bir Eğik Çizgi Olmadan Gönderilere Erişiyordu

Durumun neden böyle olduğundan emin değilim, ancak blogumdaki makalelere URL'de bir eğik çizgi olmadan yasal olarak erişmeye çalışan bir grup web tarayıcısı fark ettim.

Eğer yoksa farkında olmayabilir gibi, http://yourblog.com/article/ gibi yazılır URL http://yourblog.com/article gibi yazılmış bir URL'ye göre daha farklıdır.

Sonuç olarak, sonunda eğik çizgi olmayan bir URL ile karşılaşıldığında, WordPress devreye girmeli, bir grup PHP kodu çalıştırmalı ve ardından sondaki eğik çizgi ile makaleye 301 yönlendirmesi yapmalıdır. WordPress'i resimden çıkarmak için aşağıdaki kuralı .htaccess dosyanıza eklemeniz yeterlidir.

# Sonuna eğik çizgi ekle
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteCond %{QUERY_STRING} !.*=.*
RewriteRule ^(.*)$ $1/ [L,R=301]

Sonuna bir eğik çizgi ekleyerek, 301 yönlendirmesini WordPress'e yapmadan önce doğru URL'ye gönderirsiniz, bu da CPU kaynaklarından tasarruf sağlar.

WP Super Cache'de Bir Hata Buldum

Çoğu insanın aksine, WordPress blogum public_html dizinimin kök dizinine kurulu değil. Ayrıca blogumun ön sayfası da “yazılar” sayfam değil. Blogunuzu benim yaptığım gibi yapılandırdığınızda, WP Super Cache'de önbelleğinizi önceden yükleseniz bile tüm önbellek dosyalarınızın zamanından önce silinebileceği bir hata var.

Eklentinin yazarının bu sorunun farkında olup olmadığından emin değilim, ancak temelde bloguma bir spam yorumu gönderildiğinde, tüm önbelleğimin yanlışlıkla temizlendiğini gördüm. Her zaman yorum ve geri izleme spam'ı aldığımdan, önbelleğim sürekli boşalıyordu ve bu da önbelleğe almayı çok daha az verimli hale getiriyordu.

Bu yüzden bu sorunda hata ayıklamak için bir hafta sonu geçirdim ve sonunda bir geçici çözüm geliştirdim. Herhangi biriniz aynı sorunları yaşıyorsa, bana bildirin ve size düzeltmemi göstereyim. Buradaki hikayenin ahlaki, önbelleğe alma eklentinizin sadece çalıştığını asla varsaymamaktır. Günlüklere bakmanız gerekiyor!

CPU Yoğun Eklentileri Devre Dışı Bırak

Yukarıdaki tüm adımları izlemiş olsanız bile, tüm hileli erişimleri WordPress blogunuza ulaşmadan önce filtrelemeniz imkansızdır.

Bu nedenle, sitenize her zaman verimli bir şekilde ele alınmayacak isabetler alacaksınız. Etrafında bir yol yok.

Ama önemli olan şu ki, büyük ihtimalle bant genişliği sorununuz olmayacak, CPU sorununuz olacak.

Sonuç olarak (ve bu mantıksız olabilir), aslında sayfalarınızı anında “küçültmek” veya “sıkıştırmak” gibi CPU yoğun bir şey yapmak istemezsiniz. Küçültme ve sıkıştırma, CPU kullanımı pahasına bant genişliğine yardımcı olur.

Yapmak isteyeceğiniz son şey, hileli erişimleri küçültmek ve önbelleğe almaktır. Aslında, URL'leri GET parametreleriyle küçültmemeyi veya sıkıştırmamayı da düşünmelisiniz.

En önemlisi, sitenizde CPU yoğun eklentiler çalıştırmamalısınız. WP-Engine, muhtemelen kaçınmaya çalışmanız gereken harika bir CPU yoğun eklenti listesine sahiptir.

Eklenti listemi incelerken, “benzer gönderiler” eklentisi kullandığımı fark ettim. Kaynak koduna bir göz attığımda, eklentinin büyük bir CPU tüketimi olan ve ölçeklenebilir olmayan benzer makaleleri bulmak için tam metin karşılaştırmaları yaptığını keşfetmek beni dehşete düşürdü.

Uygun bir yedek bulduğum anda, bu eklenti kesinlikle çöpe gidiyor.

Hikayeden çıkarılacak ders

Sırf bir çevrimiçi hız testinin size blogunuzun hızlı olduğunu söylemesi, büyük şemada gerçekten çok fazla bir şey ifade etmiyor.

Beni yanlış anlama. Sayfa yükleme hızı, arama motorları ve düzenli müşterileriniz için önemlidir, ancak önbelleğinizi atlayabilecek ve sunucunuzu diz çöktürebilecek hileli erişimleri de hesaba katmanız gerekir.

Bu yüzden önbelleğe alma ve diğer hızlandırma eklentilerinizi körü körüne kurmayın. Trafiğinizi analiz etmek için biraz zaman ayırın ve WordPress'in yapması gereken işi en aza indirmek için mümkün olduğunca çok .htaccess kuralı yazın. İyi şanlar!