ZZZ Kod Sitemi Flask’ı Kaldırarak Nasıl 100 Kat Hızlandırdım?

ZZZ Kod Sitemi Flask’ı Kaldırarak Nasıl 100 Kat Hızlandırdım?

Web sitelerinin performansı, kullanıcı deneyimi ve SEO için hayati öneme sahiptir. ZZZ Kod adlı kişisel kod blogum, başlangıçta Flask ile geliştirilmişti ancak zamanla ciddi yavaşlık sorunları yaşamaya başladı. Bu makalede, Flask tabanlı mimariden tamamen vazgeçerek sitemi nasıl 100 kata kadar hızlandırdığımı, bu dönüşüm sürecinde izlediğim adımları, karşılaştığım zorlukları ve uyguladığım çözümleri detaylıca ele alacağız.

1. Flask Neden Bir Darboğaz Haline Geldi?

Projemin ilk aşamalarında Flask, hızlı prototipleme ve esnek yapısıyla harika bir seçimdi. Ancak zamanla siteye eklenen içerik ve artan ziyaretçi trafiğiyle birlikte performans sorunları baş göstermeye başladı. Her isteğin sunucu tarafında işlenmesi, kaynak tüketimini artırıyor ve yanıt sürelerini uzatıyordu.

Flask’ın Getirdiği Genel Yükler

Flask gibi Python tabanlı web çerçeveleri, her ne kadar hafif olsalar da, bir dizi doğal yükle gelirler. Her istek için bir Python yorumlayıcısının çalışması, WSGI (Web Server Gateway Interface) sunucusunun (Gunicorn, uWSGI gibi) istekleri yönetmesi ve bağımlılıkların yüklenmesi, özellikle düşük kaynaklı sunucularda veya yüksek trafik altında ciddi gecikmelere neden olabilir.

Veritabanı ve ORM Kullanımı

ZZZ Kod sitemde blog yazıları, projeler ve diğer dinamik içerikler için bir PostgreSQL veritabanı ve SQLAlchemy ORM (Object-Relational Mapper) kullanıyordum. Her sayfa yüklemesinde veritabanı bağlantısı kurulması, sorguların çalıştırılması ve ORM’in Python nesnelerine dönüştürme işlemleri, sayfa oluşturma süresine önemli bir ek yük getiriyordu. Basit bir blog yazısı bile birkaç milisaniye yerine onlarca milisaniyede yükleniyordu.

Şablon Motorları ve Dinamik İçerik Oluşturma

Flask ile birlikte Jinja2 gibi şablon motorları, dinamik HTML sayfaları oluşturmak için kullanılır. Her istekte şablonların derlenmesi, değişkenlerin yerleştirilmesi ve nihai HTML çıktısının oluşturulması, özellikle karmaşık şablon yapılarına sahip sayfalarda performansı olumsuz etkileyen bir başka faktördü. İçerik değişmediği halde her seferinde yeniden render etmek gereksiz bir iş yükü yaratıyordu.

Sunucu Kaynak Tüketimi

Bir Flask uygulamasını çalıştıran sunucu (örneğin bir VPS), her eşzamanlı istek için belirli bir miktar RAM ve CPU kaynağı tüketir. ZZZ Kod gibi genellikle statik veya yarı statik içerik sunan bir site için, bu kaynak tüketimi gereksiz ve maliyetliydi. Yüksek trafik anlarında sunucunun darboğaza girmesi, sitenin tamamen yanıt vermemesine bile yol açabiliyordu.

2. Hız Arayışında Alternatif Teknolojiler ve Karar Süreci

Flask’ın yarattığı darboğazı fark ettikten sonra, sitemi hızlandırmak için farklı mimari yaklaşımları araştırmaya başladım. Amacım, performansı artırırken aynı zamanda bakım kolaylığı ve maliyet etkinliğini de sağlamaktı.

Statik Site Jeneratörleri (SSG)

İlk ve en cazip seçeneklerden biri statik site jeneratörleriydi. Hugo, Jekyll, Gatsby veya Next.js’in statik export özelliği gibi araçlar, içeriği önceden HTML, CSS ve JavaScript dosyalarına dönüştürerek sunucu tarafında herhangi bir işleme gerek kalmadan doğrudan sunulmasını sağlıyor. Bu, performansı teorik olarak en üst düzeye çıkarıyordu.

Sunucusuz Mimariler (Serverless)

AWS Lambda, Cloudflare Workers veya Google Cloud Functions gibi sunucusuz fonksiyonlar, yalnızca ihtiyaç duyulduğunda çalışan ve kaynak tüketen bir başka modern yaklaşımdı. Dinamik ihtiyaçlar için ideal olsalar da, ZZZ Kod’un büyük ölçüde statik içeriğe sahip olması nedeniyle tam bir çözüm olarak görünmediler.

Daha Hafif Web Çerçeveleri

Python ekosisteminde FastAPI gibi daha modern ve asenkron çerçeveler veya Node.js ekosistemindeki Express.js gibi seçenekler de değerlendirildi. Bunlar Flask’tan daha hızlı olsalar da, yine de bir sunucuya ve çalışma zamanına ihtiyaç duyuyorlardı, bu da statik site jeneratörlerinin sunduğu performansı yakalayamayacakları anlamına geliyordu.

Neden Statik Site Jeneratörü Seçildi?

Kapsamlı bir değerlendirme sonucunda, ZZZ Kod’un ihtiyaçları için en uygun çözümün statik site jeneratörleri olduğuna karar verdim. Bunun başlıca nedenleri şunlardı:

• Performans: Statik dosyalar, sunucu tarafında işlem gerektirmediği için en hızlı şekilde sunulabilir.
• Maliyet: Statik dosyaları barındırmak, dinamik bir sunucu çalıştırmaktan çok daha ucuzdur.
• Güvenlik: Sunucu tarafında kod çalışmadığı için güvenlik açığı riski önemli ölçüde azalır.
• Bakım Kolaylığı: Sunucu ve veritabanı yönetimi gibi operasyonel yükler ortadan kalkar.
• Ölçeklenebilirlik: CDN’ler aracılığıyla kolayca ölçeklenebilir.

Bu kategoride ise, derleme hızı ve esnekliği nedeniyle Hugo’yu tercih ettim. Markdown tabanlı içeriği kolayca yönetebilmesi ve çok hızlı derleme süreleri sunması, kararımı etkileyen önemli faktörlerdendi.

3. Yeni Mimarinin Detayları: Hugo ve S3/CDN İkilisi

Flask’tan statik site mimarisine geçiş, sitemin tüm altyapısını baştan aşağı değiştirmeyi gerektirdi. Bu dönüşümün temelini Hugo, AWS S3 ve Cloudflare oluşturdu.

Hugo ile İçerik Yönetimi

Tüm blog yazılarımı ve proje sayfalarımı Flask’ın veritabanından Markdown formatına dönüştürdüm. Hugo, bu Markdown dosyalarını kullanarak statik HTML sayfaları, CSS ve JavaScript dosyaları üretiyor. Hugo’nun temaları sayesinde sitenin görünümünü kolayca özelleştirebildim ve geliştirme süreci oldukça hızlandı. İçerik eklemek veya düzenlemek artık sadece bir Markdown dosyasını değiştirmek ve Hugo’yu yeniden derlemek anlamına geliyordu.

---
title: "ZZZ Kod Hızlandırma Macerası"
date: 2023-10-27T10:00:00+03:00
draft: false
tags: ["flask", "hızlandırma", "hugo", "web geliştirme"]
---

Bu blog yazısı, Flask'tan Hugo'ya geçiş sürecimi anlatıyor...

AWS S3 ile Yüksek Erişilebilirlik ve Depolama

Hugo tarafından üretilen tüm statik dosyalar (HTML, CSS, JS, resimler vb.), Amazon S3 (Simple Storage Service) üzerinde bir "bucket" içinde barındırılıyor. S3, yüksek erişilebilirlik, dayanıklılık ve sınırsız ölçeklenebilirlik sunan bir nesne depolama hizmetidir. Statik web sitesi barındırma özelliği sayesinde, bir web sunucusuna ihtiyaç duymadan doğrudan S3 üzerinden sitenin içeriğini sunmak mümkün oldu. Bu, sunucu maliyetlerini sıfıra indirdi.

Cloudflare ile CDN ve Ek Optimizasyonlar

S3'ten doğrudan içerik sunmak mümkün olsa da, global bir kitleye ulaşmak ve performansı daha da artırmak için Cloudflare'ı devreye soktum. Cloudflare, bir CDN (Content Delivery Network) olarak görev yaparak site içeriğini dünya genelindeki sunucularına önbellekler. Bu sayede ziyaretçiler, kendilerine en yakın sunucudan içeriği alarak çok daha hızlı yükleme süreleri deneyimlerler. Ayrıca Cloudflare, otomatik sıkıştırma (Brotli), resim optimizasyonu, DDoS koruması ve SSL/TLS şifrelemesi gibi ek performans ve güvenlik özellikleri de sunuyor.

Otomatik Dağıtım Süreci (CI/CD)

Yeni içerik eklediğimde veya mevcut bir içeriği güncellediğimde, sitenin otomatik olarak yeniden derlenip S3'e yüklenmesi ve Cloudflare önbelleğinin temizlenmesi için bir CI/CD (Sürekli Entegrasyon/Sürekli Dağıtım) hattı kurdum. GitHub Actions kullanarak, her "main" branch'e yapılan push işleminde Hugo'yu çalıştırıp çıktıları S3'e senkronize eden ve Cloudflare'ı güncelleyen bir iş akışı oluşturdum. Bu, yayınlama sürecini tamamen otomatikleştirerek geliştirici deneyimini büyük ölçüde iyileştirdi.

4. Performans Optimizasyonları ve Ölçülebilir Sonuçlar

Flask'ı kaldırmak ve statik mimariye geçmek, performans açısından muazzam bir sıçrama sağladı. Ancak sadece mimari değişikliğiyle yetinmeyip, ek optimizasyonlarla da bu hız kazanımlarını pekiştirdim.

Flask Öncesi Durum

Flask tabanlı ZZZ Kod sitemin ortalama yüklenme süreleri, PageSpeed Insights ve GTmetrix gibi araçlarda genellikle 3-5 saniye civarındaydı. Özellikle ilk bayt süresi (TTFB - Time To First Byte) yüksek çıkıyor, bu da sunucu tarafındaki işleme yükünü gösteriyordu. Lighthouse skorları ise genellikle mobil için 40-60, masaüstü için 60-80 aralığındaydı.

Flask Sonrası Durum

Yeni mimariyle birlikte, sitenin yüklenme süreleri ortalama 0.3-0.8 saniyeye kadar düştü. Bu, bazı sayfalarda 100 kattan daha fazla bir hızlanmaya denk geliyordu. İlk bayt süresi 20-50 ms aralığına indi, bu da içeriğin neredeyse anında sunulduğu anlamına geliyordu. Lighthouse skorları ise mobil ve masaüstü için istikrarlı bir şekilde 95-100 aralığında seyrediyordu.

Ek Optimizasyonlar

Bu muazzam hız kazanımına ek olarak, bazı ek optimizasyonlar da uyguladım:

• Resim Sıkıştırma ve WebP Dönüşümü: Tüm resimleri sıkıştırıp WebP formatına dönüştürerek dosya boyutlarını ciddi şekilde azalttım.
• Tarayıcı Önbellekleme: HTTP başlıklarını doğru yapılandırarak tarayıcıların statik dosyaları daha uzun süre önbellekte tutmasını sağladım.
• Kritik CSS/JS: Sayfa yüklenirken görünen ilk içeriğin (above-the-fold) CSS'ini inline olarak HTML'e ekleyerek render bloklamasını azalttım.
• Asenkron Yükleme: Kritik olmayan JavaScript dosyalarını async veya defer nitelikleriyle yükleyerek sayfa render sürecini engellemesini önledim.

Hız Testi Araçları ve Metrikler

Google Lighthouse, GTmetrix ve WebPageTest gibi araçlarla düzenli olarak performans testleri yaparak elde edilen kazanımları doğruladım. Özellikle Largest Contentful Paint (LCP) ve Cumulative Layout Shift (CLS) gibi Core Web Vitals metriklerinde önemli iyileşmeler gözlemledim. Bu iyileşmeler, sadece rakamsal olarak değil, aynı zamanda kullanıcı deneyimi açısından da somut bir fark yarattı.

5. Geçiş Süreci: Zorluklar ve Çözümler

Flask'tan statik bir mimariye geçiş, kulağa basit gelse de, bazı zorlukları da beraberinde getirdi. Ancak her zorluğun üstesinden gelmek için uygun çözümler buldum.

Dinamik İçeriğin Statikleştirilmesi

ZZZ Kod sitemde yorumlar, arama fonksiyonu ve iletişim formu gibi bazı dinamik özellikler bulunuyordu. Statik bir sitede bu tür özellikler doğrudan çalışmaz. Çözüm olarak:

• Yorumlar: Disqus gibi üçüncü taraf bir yorum sistemine geçiş yaptım. Bu, sunucu tarafında yorumları yönetme yükünü ortadan kaldırdı.
• Arama Fonksiyonu: Algolia veya Lunr.js gibi client-side arama kütüphanelerini kullanarak statik site üzerinde arama yapmayı mümkün kıldım.
• İletişim Formu: Formspree veya Netlify Forms gibi hizmetleri kullanarak sunucu tarafında kod yazmadan form gönderimlerini yönettim.

URL Yapısının Korunması

SEO açısından kritik olan bir diğer konu da mevcut URL yapısını korumaktı. Flask'tan Hugo'ya geçerken URL'lerin değişmesi, arama motoru sıralamalarını olumsuz etkileyebilirdi. Bu nedenle, Hugo'nun permalink yapılandırmasını Flask'taki URL şemasına uygun hale getirdim. Eğer bazı URL'ler kaçınılmaz olarak değiştiyse, S3'ün yönlendirme kurallarını veya Cloudflare'ın sayfa kurallarını kullanarak 301 yönlendirmeleri oluşturdum.

Geliştirici Deneyimi ve İş Akışı

Yeni bir teknoloji yığınına geçiş, geliştirici deneyiminde başlangıçta bazı adaptasyon süreçleri gerektirdi. Flask'ın alışıldık Python ortamından, Markdown ve Go tabanlı Hugo'ya geçmek farklı bir düşünce yapısı gerektiriyordu. Ancak zamanla, Hugo'nun hızlı derleme süreleri ve Markdown'ın basitliği sayesinde içerik oluşturma ve yayınlama süreci çok daha verimli hale geldi.

Maliyet Analizi

Flask uygulamasını çalıştıran bir VPS'in aylık maliyeti (genellikle 5-20 dolar arası), S3 ve Cloudflare'ın maliyetleriyle karşılaştırıldığında önemli bir düşüş yaşandı. S3 depolama ve veri transferi maliyetleri genellikle çok düşüktür (aylık birkaç sentten birkaç dolara kadar). Cloudflare'ın ücretsiz planı çoğu küçük site için yeterli olup, daha fazla özellik için uygun fiyatlı planlar sunar. Genel olarak, operasyonel maliyetlerimi %90'ın üzerinde azalttım.

6. Sonuçlar, Kazanımlar ve Gelecek Planları

Flask'ı ZZZ Kod sitemden kaldırmak, sadece bir teknoloji değişikliği değil, aynı zamanda projenin geleceği için stratejik bir karardı. Elde ettiğim sonuçlar, bu kararın ne kadar doğru olduğunu kanıtladı.

Elde Edilen Hız ve Kullanıcı Deneyimi

Sitenin 100 kata kadar hızlanması, kullanıcı deneyimini kökten değiştirdi. Sayfalar anında yükleniyor, gezinme akıcı hale geldi. Bu durum, ziyaretçilerin sitede daha uzun süre kalmasına, daha fazla sayfa görüntülemesine ve genel olarak daha olumlu bir etkileşim kurmasına yol açtı. Hız, aynı zamanda arama motoru sıralamalarında da pozitif bir etki yaratarak sitenin organik trafiğini artırdı.

Maliyet ve Bakım Kolaylığı

Dinamik bir sunucu ve veritabanı yönetme yükünden kurtulmak, hem operasyonel maliyetleri sıfıra indirdi hem de bakım için harcadığım zamanı büyük ölçüde azalttı. Artık sunucu güncellemeleri, güvenlik yamaları veya veritabanı yedeklemeleri gibi konularla uğraşmak zorunda değilim. Bu, bana içerik üretmeye ve yeni projelere odaklanmak için daha fazla zaman bıraktı.

Geliştirici Verimliliği

Otomatik CI/CD süreci ve Markdown tabanlı içerik yönetimi sayesinde, yeni bir blog yazısı yayınlamak veya mevcut bir içeriği güncellemek artık dakikalar içinde tamamlanabiliyor. Bu, geliştirici verimliliğini artırırken, içerik yayınlama döngüsünü de hızlandırdı.

Gelecek Adımlar

ZZZ Kod sitesinin geleceği için planlarım arasında, daha fazla içerik üretmek, Hugo temamı daha da özelleştirmek ve belki de bazı dinamik özellikler için (örneğin e-posta bülten aboneliği) sunucusuz fonksiyonları (Cloudflare Workers gibi) entegre etmek yer alıyor. Ancak bu entegrasyonlar, sitenin temel statik yapısını bozmadan, sadece gerektiğinde devreye girecek şekilde tasarlanacak.

SSS (Sık Sorulan Sorular)

Neden Flask yerine başka bir Python framework'ü seçmediniz?

Amacım, sunucu tarafında Python çalıştırma ihtiyacını tamamen ortadan kaldırmaktı. FastAPI gibi diğer Python framework'leri de sunucu tarafında çalışır ve statik sitelerin sunduğu performansı ve maliyet avantajlarını sağlayamazdı.

Dinamik özelliklere ne oldu (yorumlar, kullanıcı girişi vb.)?

Yorumlar için Disqus gibi üçüncü taraf hizmetlere geçtim. Kullanıcı girişi gerektiren bir özellik sitemde bulunmuyordu. İletişim formları için ise Formspree gibi sunucusuz form hizmetlerini kullandım. Bu tür ihtiyaçlar için genellikle üçüncü taraf entegrasyonlar veya sunucusuz fonksiyonlar iyi birer çözümdür.

Bu geçiş ne kadar sürdü?

Mevcut içeriği Markdown'a dönüştürme, Hugo temasını kurma ve özelleştirme, dağıtım hattını ayarlama dahil olmak üzere yaklaşık 2-3 hafta sürdü. Projenin büyüklüğüne ve dinamik özelliklerin karmaşıklığına göre bu süre değişebilir.

Maliyetleriniz gerçekten düştü mü?

Kesinlikle. Flask uygulamasını barındırdığım VPS'in aylık maliyeti ortadan kalktı. AWS S3 ve Cloudflare'ın ücretsiz katmanları veya çok düşük maliyetli seçenekleri sayesinde, aylık maliyetim neredeyse sıfıra indi.

Her site Flask'ı kaldırmalı mı?

Hayır, bu her site için geçerli bir durum değildir. Eğer siteniz yoğun kullanıcı etkileşimi, kişiselleştirilmiş içerik, gerçek zamanlı veri işleme veya karmaşık veritabanı işlemleri gerektiriyorsa, dinamik bir framework (Flask, Django, Laravel vb.) kullanmak kaçınılmazdır. Ancak ZZZ Kod gibi büyük ölçüde statik içerik sunan bloglar, portföy siteleri veya dokümantasyon siteleri için statik site jeneratörleri çok daha uygun ve performanslı bir çözümdür.