--- title: "WordPress Autoload Şişkinliği: Denetle ve Düzelt" url: https://bw.agency/blog/wordpress-autoload-siskinligi/ date: 2026-09-25 modified: 2026-09-25 lang: tr author: "bwa" description: "WordPress autoload şişkinliği her istekte wp_options'ı şişirir. Fazla veriyi iki SQL sorgusuyla bulun, güvenle kapatın ve 800 KB altına inin." categories: - "WordPress" image: https://img.poweredcache.net/bw.agency/wp-content/uploads/2026/09/wordpress-autoload-siskinligi.avif?rs=fit&w=793&h=500&ssl=1 word_count: 1462 --- # WordPress Autoload Şişkinliği: Denetle ve Düzelt ## Önemli Noktalar - Query Monitor eklentisi, WordPress sayfalarındaki yavaş sorguları incelemek için kullanılır. - wp_postmeta tablosundaki yavaş sorgular, meta_key ve meta_value sütunlarını kapsayan bileşik indexler ile hızlandırılır. - MySQL sorguları, ideal bir performans için 50 ms altında çalışmalı ve tipik bir sayfa toplam 200 ms altı veritabanı süresine sahip olmalıdır. WordPress her istekte tüm autoload setinizi `wp_options`'tan yükler. **Set şişmişse, bedelini her sayfa öder.** ## Autoload Verinizi Denetleyin: İki Sorgu Bunları phpMyAdmin, Adminer veya `wp db query`'ye yapıştırın. İlki toplam autoload boyutunu KB olarak verir. İkincisi, buna yol açan 25 seçeneği listeler. Prefix'iniz farklıysa `wp_` kısmını değiştirin. `-- Toplam autoload verisi (KB) + satır sayısı SELECT ROUND(SUM(LENGTH(option_value)) / 1024, 1) AS autoload_kb, COUNT(*) AS autoload_count FROM wp_options WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');` ``` -- En büyük 25 suçlu, en büyük önce SELECT option_name, ROUND(LENGTH(option_value) / 1024, 1) AS size_kb, autoload FROM wp_options WHERE autoload IN ('yes', 'on', 'auto', 'auto-on') ORDER BY LENGTH(option_value) DESC LIMIT 25; ``` **IN (...) listesi neden önemli:** WordPress 6.6+ klasik `'yes'` ve `'on'` yanında `'auto'` ve `'auto-on'` da yazar. Sadece `autoload = 'yes'`'e bakan bir sorgu gerçek boyutu eksik sayar. Bu yüzden birçok site kâğıt üstünde iyi görünür ama her istekte şişmiş bir set yükler. ## WordPress Autoloader ile Autoload Verisi Farkı "Autoloader" WordPress'te iki ayrı şey demektir ve arama ikisini de döndürür. Hangisine sahip olduğunuzu 30 saniyede kontrol edin. | İnsanların dediği | Gerçekte ne | Siteyi yavaşlatır mı? | | -------------------- | ------------ | ------------------------ | | **PHP sınıf autoloader'ı** (Composer, `spl_autoload_register`, PSR-4) | Bir sınıf ilk kullanıldığında dosyasını yükleyen fonksiyon; elle `require` yazmazsınız | Neredeyse hiç. Dosya sistemi araması, genelde OPcache'lenir | | **Autoload seçenekleri** (`wp_options`'taki `autoload` sütunu) | Kodunuz çalışmadan önce, her istekte belleğe çekilen satırlar | **Evet.** Size pahalıya patlayan bu; sayfanın konusu da bu | Host "autoloaded data" uyarısı verdiği için veya profilleyicide `alloptions` gördüğünüz için buradaysanız, ikincisini istiyorsunuz. `Class not found` hatası ayıklıyorsanız birincisini; o bir Composer/PSR-4 sorunudur. ## Autoload Verisi Nedir? WordPress'in her sayfa yüklemesinde, tema veya eklenti kodu çalışmadan önce koşan tek bir sorgusu vardır: `SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'` Bu, tüm "autoload" seçeneklerini tek seferde belleğe yükler. Çekirdek bu verinin ~100 KB'sine ihtiyaç duyar. Sorun, eklentilerin bunu kötüye kullanmasıdır. **Desen:** Bir eklentiyi kapatırsınız; verisi `autoload='yes'` olarak `wp_options`'ta kalır. 2 yılda 30 eklenti kurarsınız. Artık her istekte 5 MB veri yüklüyorsunuz; çoğu artık kullanmadığınız eklentilerden. TTFB'yi ara sıra zıplatan [yavaş sorguların](https://bw.agency/blog/yavas-wordpress-sorgulari/) aksine, autoload şişkinliği sabit bir vergidir. Önbellekli ya da değil, ön yüz ya da admin, her isteğe gecikme ekler. ## Sağlıklı Autoload Boyutu: wp_options Eşikleri Toplam autoload boyutunu bir bütçe olarak görün, gösteriş metriği değil. Denetim sorgusunu çalıştırın, sonucunuzu bu tabloya göre okuyun. | Autoload boyutu | Karar | Ne yapmalı | | --------------- | ----- | ----------- | | 300 KB altı | İyi | Hiçbir şey. Çekirdek tek başına ~100 KB ister; normal bölgedesiniz. Büyük kurulum veya taşıma sonrası tekrar bakın. | | 300–800 KB | İzle | Top-25 sorgusunu çalıştır. En büyük satırların hangi eklentiye ait olduğunu not et; büyümeden öksüz ve bayat cache'lerin autoload'unu kapat. | | 800 KB–1 MB | Harekete geç | Çoğu yönetilen hostun işaretlediği çizgiyi aştın. Bu hafta temizlik planla. Silmek yerine `autoload='no'` tercih et. | | 1 MB üstü | Acil | WordPress tüm seti tek `alloptions` anahtarında önbelleğe alır. Çoğu Redis/Memcached kurulumu tek değeri ~1 MB ile sınırlar; set sessizce önbelleğe alınamaz veya yük altında 502 olarak çıkar. | 3 MB üstü autoload verisi olan siteler yaygındır. 10 MB+ gördük; bu, WordPress sayfayı kurmaya başlamadan önce her istekte MySQL'den PHP'ye taşınan 10 MB demektir. ## WP Engine "Autoloaded Data" Uyarısı: Ne Yapmalı? WP Engine autoload verisini 800 KB'yi geçince işaretler; altını normal sayar. Bunu panel uyarısı olarak yüzeye çıkaran az sayıdaki hosttan biridir. Fiziği host-bağımsızdır; her istek tüm seti PHP'ye çeker. - **Önce kendiniz ölçün.** Yukarıdaki denetim sorgusunu çalıştırın. Host panelleri zamanlamayla örnekler; gördüğünüz sayı saatlerce eski olabilir. Bazı paneller hâlâ `autoload = 'yes'`'i test eder ve 6.6+ sürümde eksik sayar. - **Toplamı değil, suçluları bulun.** Toplam bir belirtidir. İlk 25 satırı `LENGTH(option_value)`'a göre listeleyin; yükün çoğunu genelde üç dört satır taşır. - **Her birini dokunma listesiyle kontrol edin.** Bir şey değiştirmeden önce aşağıdaki listeye bakın. Bazı büyük autoload seçenekleri büyük olmalıdır. - **Autoload'u kapatın, silmeyin.** `wp option set-autoload OPTION_NAME off` veriyi bozmadan geri alınabilir bırakır. Satır silmek bir eklentinin ayarlarını bozmanın yoludur. - **Yeniden ölçün ve panelin yetişmesini bekleyin.** Uyarı, WP Engine'in bir sonraki kontrolünde temizlenir, anında değil. Memcached'e özel bir uyarı: ~1 MB üstünde blob anahtar limitini aşabilir, sessizce önbelleğe alınamaz ve her istek veritabanına döner. Bu, [wp-admin'de yavaş sayfa](https://bw.agency/blog/wordpress-backend-performansi/) yerine rastgele 502 olarak görünür. ## WordPress Autoload Şişkinliğinin Nedenleri ### 1. Kapatılan Eklenti Artıkları Çoğu eklenti ardından temizlik yapmaz. Etkinleştirmede seçenek ekler ve kapatma/silme sonrası bile sonsuza dek bırakır. Bulun: `SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload = 'yes' ORDER BY size DESC LIMIT 20;` Artık kullanmadığınız eklentilere ait isimleri arayın. Bunları `autoload='no'` yapmak veya silmek güvenlidir. ### 2. Büyüyen Serileştirilmiş Diziler Bazı eklentiler büyüyen veriyi tek seçenekte tutar: kayıtlar, analitik anlık görüntüleri, cron zamanlamaları. Tek bir `option_value` 500 KB+ serileştirilmiş PHP olabilir. ### 3. Süresi Dolmuş Transient'ler Transient'ler `wp_options`'ta tutulan geçici cache değerleridir. Dış [nesne önbelleği](https://bw.agency/blog/wordpress-nesne-onbellegi/) yoksa dolanları birikir. WordPress bunları yalnızca tembel şekilde, bir sonraki erişimde temizler. `SELECT COUNT(*) FROM wp_options WHERE option_name LIKE '_transient_%' AND autoload = 'yes';` ### 4. Yanlış Yapılandırılmış Eklentiler Kullanıcı başı ayarları, büyük JSON yapılandırmaları veya önbelleklenmiş API yanıtlarını autoload seçeneğinde tutan eklentiler. Veri gerekli olabilir ama her istekte yüklenmesi gerekmez. ## wp_options'ta Autoload Verisi Nasıl Denetlenir? - **Toplam autoload boyutunu kontrol edin.** Yukarıdaki SQL'i çalıştırın. 1 MB üstü hemen inceleme gerektirir. - **En büyük suçluları bulun.** Seçenekleri `LENGTH(option_value)`'a göre sıralayın. İlk 10 genelde şişkinliğin %80'inden fazlasını oluşturur. - **Öksüz veriyi belirleyin.** İsimleri aktif eklentilerinizle karşılaştırın. Kapatılmış eklentilerden gelen seçeneklere dokunmak güvenlidir. - **Değiştirmeden önce test edin.** Tek seferde bir seçeneği `autoload='no'` yapın. Sitenin çalıştığını doğrulayın. Bazı seçenekler gerçekten autoload gerektirir. - **Dolmuş transient'leri temizleyin.** Zaman aşımını geçmiş transient'leri silin. Bu her zaman güvenlidir. ## Neyi KAPATMAMALI? `autoload`'u çevirmek geri alınabilir. Satır silmek değil. Bazı seçenekler sahibi aktifken autoload kalmalı, yoksa WordPress ve eklentiler bootstrap'ın başında bozulur. Hata da vermez, sessizce kötüleşir. Toplu değişiklikten önce bunu kontrol edin. | Autoload kalsın (kullanımdayken) | Genelde `autoload='no'` güvenli | | ---------------------------------- | -------------------------------- | | `cron` (tüm WP-Cron haritası); `active_plugins`, `template`, `stylesheet`; `siteurl`, `home`, `blogname`; `user_roles`, `permalink_structure`, `rewrite_rules`; aktif temanın `theme_mods_*`'ı; aktif eklentilerin çalışma ayarları (WooCommerce config, Yoast `wpseo_*`, güvenlik duvarı kuralları) | Silinen eklentilerden öksüz satırlar; bayat `_transient_*` ve `_site_transient_*` (tanım gereği cache); güncelleme artıkları `_site_transient_update_*`; kuyruk/telemetri kaydı `action_scheduler_*`, `wc_tracks_*`; aşırı büyük sayfa oluşturucu CSS/asset blobları (`_elementor_*` ve Divi sık tekrar eder) | Kural: eklenti aktifse ve seçenek her istekte okuduğu yapılandırmaysa autoload açık kalsın. Eklenti gittiyse ya da değer bir cache, kayıt veya kuyruk blob'uysa önce autoload'u kapatın; ancak hiçbir şeyin okumadığını doğruladıktan sonra silin. ### Yaygın Autoload Suçluları: Kapatmak Güvenli mi? Sürekli gördüğüm 20 prefix ve her biriyle ne yaptığım. "Dikkat", cevabın eklentinin hâlâ aktif olup olmamasına bağlı olduğu anlamına gelir; önce onu kontrol edin. | Seçenek / prefix | Kaynak | Autoload kapatmak güvenli mi? | | ----------------- | ------ | ------------------------------ | | `_transient_*` / `_site_transient_*` | Çekirdek + herhangi eklenti | Evet — tanım gereği cache; nesne önbellekli sitelerde zaten wp_options'ta durmamalı | | `action_scheduler_*` | Action Scheduler (WooCommerce vb.) | Evet — kuyruk kaydı, zamanlayıcı çalışınca talep üzerine yüklenir | | `wc_tracks_*` | WooCommerce (telemetri) | Evet — kullanım izleme; kullanıcıya dönük hiçbir şey buna bağlı değil | | `woocommerce_*` (ayarlar) | WooCommerce çekirdek | Hayır — para birimi, vergi, ödeme yapılandırması her istekte okunur | | `elementor_*` | Elementor (ayarlar) | Dikkat — aktifken gerekir; yalnızca Elementor kapatıldıysa güvenli | | `_elementor_*` | Elementor (iç/cache verisi) | Dikkat — bazısı CSS/asset cache (güvenli), bazısı çalışma durumu; satır satır denetle | | `jetpack_*` / `_jetpack_*` | Jetpack | Dikkat — bağlantı token'ları ve senkron durumu; yanlış olanı çevirmek bağlantıyı bozar | | `wpseo_*` | Yoast SEO | Aktifken Hayır — başlık, meta ve indexable ayarları her ön yüz isteğinde yüklenir. Kaldırıldıysa Evet | | `aioseo_*` | All in One SEO | Dikkat — çekirdek ayarlar aktifken kalır; aşırı büyük cache/log seçeneklerini çevirmek güvenli | | `rank_math_*` | Rank Math | Dikkat — çalışma ayarları Hayır, analitik/cache blobları Evet | | `wf*` / `wflogs` | Wordfence | Dikkat — aktifken güvenlik duvarı config'i her istekte okunur; log satırları ve kaldırma sonrası öksüzler kesin Evet | | `et_*` | Divi (Elegant Themes) | Dikkat — aktif tema ayarları Hayır; Divi'den geçtiyseniz tüm `et_*` ölü yük — Evet | | `fs_accounts` | Freemius SDK (birçok eklentide gömülü) | Dikkat — tüm Freemius tabanlı eklentilerin paylaştığı tek satır; biri aktifken çevirmek lisansı bozar | | `rewrite_rules` | Çekirdek | Dikkat — çoğu zaman en büyük seçenek ama WordPress URL yönlendirmek için ister. Asla silme; devasaysa şişiren eklentiyi bul | | `cron` | Çekirdek | Hayır — tüm WP-Cron programı burada; autoload'u kapatmak zamanlı görevleri bozar | ## WordPress'te Autoload Şişkinliği Nasıl Düzeltilir? ### Belirli Seçeneklerin Autoload'unu Kapatın `UPDATE wp_options SET autoload = 'no' WHERE option_name = 'old_plugin_settings';` ### Dolmuş Transient'leri Temizleyin ``` DELETE FROM wp_options WHERE option_name LIKE '_transient_timeout_%' AND option_value < UNIX_TIMESTAMP(); ``` ### Öksüz Eklenti Verisini Silin ``` -- Yalnızca eklentinin gittiğini doğruladıktan sonra: DELETE FROM wp_options WHERE option_name LIKE 'removed_plugin_%'; ``` Manuel çözümlerin sorunu: kalıcı olmazlar. Eklentiler veri eklemeye devam eder. Transient'ler yeniden birikir. Yeni eklentiler yeni autoload seçenekleri getirir. Kontrol altında tutmak için aylık denetim gerekir. ## Autoload Şişkinliği Neden Büyümeye Devam Eder? Autoload şişkinliği ilerleyicidir. 50 KB'lik adımlarla yavaşça büyür; siteniz belirgin yavaşlayana kadar görünmez. - Yeni eklenti kuruldu → 200 KB autoload yapılandırma seçeneği - Eklenti kapatıldı → veri kalır, hâlâ autoload'lanır - Transient cache miss → autoload'la yeni transient saklanır - Eklenti güncellemesi → geçiş yeni autoload satırları ekler WordPress yönetici paneliniz de yavaşladıysa, gizli neden çoğu zaman autoload şişkinliğidir. Sorun performansa dönüşmeden hangi seçeneğin bellek harcadığını gösteren sürekli izlemeye ihtiyacınız var. ## Autoload Şişkinliği SSS ### WordPress'te ne kadar autoload verisi fazladır? 300 KB altı sağlıklı, 300–800 KB izlenmeli, 800 KB üstü harekete geçmeli. 1 MB üstünde set tek anahtar limitini aşabilir, önbelleğe alınamaz ve 502 hatalarına yol açar. ### Autoload'u kapatmak veriyi siler mi? Hayır. `wp option set-autoload OPTION_NAME off` veriyi bozmadan bırakır ve geri alınabilir. Yalnızca her istekte belleğe yüklenmesini durdurur. Satır silmek ayrı ve geri dönüşü olmayan bir işlemdir. ### Denetim sorgum neden host paneliyle uyuşmuyor? Paneller zamanlamayla örnekler, bu yüzden sayı eski olabilir. Bazıları hâlâ yalnızca `autoload = 'yes'`'i test eder; WordPress 6.6+ ise `'on'`, `'auto'` ve `'auto-on'` da yazar. Dört değeri de sayın.