Ürün listeniz büyüdükçe sayfa yavaşlıyor. Elli kayıt gösteriyorsunuz ama sayfa açılması saniyeler alıyor — sorun gösterdiğiniz kayıt sayısında değil, nasıl gösterdiğinizde.
Bu yazı, büyük listelerin hosting kaynaklarını nasıl tükettiğini ve doğru sayfalama yöntemlerini ele alıyor.
En Yaygın Hata
Sayfalama denince akla ilk gelen yöntem şudur: tüm kayıtları çek, sonra istenen kısmı göster.
Bu yaklaşımın sorunu, işi yanlış katmanda yapmasıdır: on bin kaydı veritabanından çekip PHP tarafında yirmisini göstermek, on bin kaydın tamamını belleğe almak demektir.
- Bellek limiti aşılır. Paylaşımlı hostingde hızlıca.
- Veritabanı gereksiz iş yapar.
- Ağ üzerinden fazla veri taşınır.
- Süre limiti aşılabilir.
Doğrusu, sınırlamayı veritabanına yaptırmaktır — yalnızca gereken kayıtlar getirilir, gerisi hiç okunmaz.
Toplam Sayı Sorunu
Sayfalama arayüzü genellikle "toplam 1.240 sonuç, 62 sayfa" der. Bu bilgi için ayrı bir sayım sorgusu gerekir ve maliyeti yüksektir:
- Ana sorgu yalnızca 20 kayıt getirir — hızlıdır
- Sayım sorgusu ise tüm eşleşmeleri sayar — yavaştır
- Filtreli aramalarda bu maliyet daha da artar
- Toplam sayı çoğu kullanıcı için önemsizdir
Dördüncü madde önemli bir tasarım fırsatı sunar: kullanıcı genellikle toplam sayfa sayısını değil, bir sonraki sayfayı merak eder.
Bu durumda sayım sorgusundan tamamen vazgeçilebilir. Bir kayıt fazlasını çekip "daha fazlası var mı" sorusunu yanıtlamak yeterlidir — yani 20 kayıt gösterecekseniz 21 kayıt isteyin.
Derin Sayfalama Tuzağı
Klasik sayfalama, sayfa numarası büyüdükçe yavaşlar:
| Sayfa | Veritabanının yaptığı iş |
|---|---|
| 1. sayfa | İlk 20 kaydı bul |
| 10. sayfa | 200 kayıt tara, son 20'sini ver |
| 500. sayfa | 10.000 kayıt tara, son 20'sini ver |
Sorun şudur: atlanacak kayıtlar da okunmak zorundadır — veritabanı 9.980 kaydı okuyup atar, sonra 20 kayıt döner.
Bu yüzden derin sayfalarda süre doğrusal olarak artar. Kullanıcılar 500. sayfaya nadiren gider ama arama motoru botları bu sayfaları düzenli olarak tarar ve sunucunuzu meşgul eder.
İmleç Tabanlı Sayfalama
Derin sayfalama sorununun çözümü, sayfa numarası yerine konum işareti kullanmaktır:
- Son gösterilen kaydın kimliğini saklayın.
- Sonraki sayfada "bundan sonrakiler" diye sorun.
- Veritabanı indeksten devam eder. Atlama yapmaz.
- Süre sayfa numarasından bağımsız kalır.
Üçüncü madde performans farkının kaynağıdır: indeks üzerinde belirli bir noktadan devam etmek, o noktaya kadar olan kayıtları okumayı gerektirmez.
Yöntemin kısıtı, rastgele sayfaya atlamaya izin vermemesidir. "Sonraki" ve "önceki" çalışır, ancak doğrudan 50. sayfaya gidilemez. Sonsuz kaydırma ve "daha fazla yükle" düğmeleri için ideal bir yapıdır.
İndeks Gereksinimi
Hangi yöntemi kullanırsanız kullanın, sıralama alanının indeksli olması şarttır:
- Sıraladığınız sütun indeksli olmalıdır.
- Filtre alanları da indekslenmelidir.
- Birleşik indeksler sıra önemlidir. Filtre önce, sıralama sonra.
- Sıralama yönü tutarlı olmalıdır.
İkinci ve üçüncü maddeler birlikte çalışır: kategoriye göre filtreleyip tarihe göre sıralıyorsanız, ikisini birden içeren bir indeks tek başına her ikisinden çok daha etkilidir.
İndeks olmadığında veritabanı, sıralamayı bellekte yapmak için tüm eşleşen kayıtları toplar — bu, paylaşımlı hostingde kaynak limitlerini doğrudan tüketir. Kaynak kullanımını izleyebildiğiniz hosting paketleri üzerinde bu tür sorguların etkisi kontrol panelindeki kaynak raporlarında görünür.
Arayüz Kararları
Sayfalama arayüzünün seçimi de yükü etkiler:
| Yaklaşım | Uygunluk |
|---|---|
| Numaralı sayfalar | Az kayıtta, gezinme önemliyse |
| Sonraki / önceki | Çok kayıtta, hafif |
| Daha fazla yükle | Mobilde iyi çalışır |
| Sonsuz kaydırma | Keşif odaklı listelerde |
Dördüncü satırın gizli bir maliyeti vardır: sonsuz kaydırma, alt bilgi alanına ulaşmayı imkânsız hâle getirir ve arama motorlarının içeriği keşfetmesini zorlaştırır.
Bu yüzden ürün listeleri gibi taranması istenen sayfalarda, sonsuz kaydırma kullanılsa bile arka planda gerçek sayfa adresleri sunulmalıdır.
Arama Motoru Tarafı
Sayfalanmış listelerin taranmasında dikkat edilecekler:
- Her sayfanın kendi adresi olmalıdır. Tarayıcı adres çubuğundan erişilebilir.
- Filtre kombinasyonlarını sınırlayın. Sonsuz adres üretmeyin.
- Derin sayfaları tarama dışı bırakabilirsiniz.
- Sıralama parametreleri ayrı sayfa saymamalıdır.
İkinci madde ciddi bir kaynak tüketimi kaynağıdır: beş filtre alanı ve dört sıralama seçeneği, binlerce farklı adres kombinasyonu üretir ve botlar bunların hepsini taramaya çalışır.
Bu, paylaşımlı hosting hesaplarında kaynak limiti aşımının en sık görülen sebeplerinden biridir. Hangi kombinasyonların taranabilir olduğunu açıkça sınırlamak gerekir.
Sonuç
Sayfalamada en pahalı hata, sınırlamayı yanlış katmanda yapmaktır: tüm kayıtları çekip PHP tarafında bir kısmını göstermek, hepsini belleğe almak demektir. Sınırlamayı veritabanına yaptırın. Toplam sayı için ayrı sayım sorgusundan çoğu durumda vazgeçebilirsiniz — bir kayıt fazlasını çekip "devamı var mı" sorusunu yanıtlamak yeterlidir. Derin sayfalarda ise atlanacak kayıtlar da okunmak zorundadır; imleç tabanlı yaklaşım bu maliyeti tamamen kaldırır. Ve filtre kombinasyonlarını sınırlayın: bot taramaları kaynak limitinizi tüketir.
Sıkça Sorulan Sorular (SSS)
Liste sayfam bellek hatası veriyor, neden?
Büyük olasılıkla tüm kayıtları çekip PHP tarafında kısıtlıyorsunuz. Sınırlamayı veritabanı sorgusunda yapın — yalnızca gösterilecek kayıtlar getirilsin. On bin kaydı çekip yirmisini göstermek, on bininin de belleğe alınması demektir.
Sayfa numarası büyüdükçe neden yavaşlıyor?
Çünkü atlanacak kayıtlar da okunmak zorundadır. 500. sayfa için veritabanı yaklaşık on bin kaydı okuyup atar, sonra yirmi kayıt döner. Çözüm, sayfa numarası yerine son gösterilen kaydın konumundan devam eden imleç tabanlı sayfalamadır.
Toplam sonuç sayısını göstermek zorunda mıyım?
Değilsiniz ve genellikle göstermemek daha iyidir. Sayım sorgusu tüm eşleşmeleri saymak zorunda olduğu için pahalıdır. Kullanıcı çoğunlukla toplam sayfa sayısını değil bir sonraki sayfayı merak eder — bir kayıt fazlasını çekmek bu soruyu ücretsiz yanıtlar.
Bot taramaları kaynak limitimi tüketiyor?
Filtre ve sıralama kombinasyonlarınız muhtemelen çok fazla adres üretiyor. Beş filtre ve dört sıralama seçeneği binlerce farklı adres demektir ve botlar hepsini taramaya çalışır. Hangi kombinasyonların taranabilir olduğunu açıkça sınırlayın ve derin sayfaları tarama dışı bırakın.
