This week in caching: push CDN vs pull CDN

Older distinction, still decides your origin load:

— Pull (origin-pull): CDN fetches from your origin on first miss, caches, serves. Zero upload step, content auto-updates when origin does. The default for 95% of sites.
— Push: you upload assets to the CDN ahead of time; origin is never hit. Worth it for huge files (video, large downloads) where even one origin pull is expensive, or origins that can't take traffic spikes.
— The pull gotcha: a viral cold object triggers many simultaneous origin fetches before the cache fills — 'origin shielding' (a mid-tier cache) collapses that into one fetch. Turn it on if your CDN offers it.

Most people never need push; they need shielding turned on and a sane default TTL.

Bookmark: Cloudflare's 'origin shielding / Tiered Cache' docs — the fix for pull-CDN miss storms.

This week in caching: hard purge vs soft purge

A distinction that decides whether a purge causes a traffic spike on your origin:

— Hard purge: the object is deleted from cache instantly. Next request is a guaranteed miss → origin fetch. Purge a popular URL during peak and you've just shipped a mini load test to your backend.
— Soft purge: the object is marked stale, not removed. Next request serves it stale-while-revalidate and refreshes in the background — no latency cliff, no origin stampede.
— When you still want hard: legal/PII takedowns, or anything where serving stale even for a second is unacceptable.

Default to soft purge for content updates; reserve hard purge for 'this must vanish now'.

Bookmark: Fastly's soft-purge documentation — the canonical writeup of why stale-marking beats deletion for routine invalidation.

This week in caching: OPcache revalidate_freq vs full reset on deploy

How you ship PHP changes without serving half-old bytecode:

— validate_timestamps=1 + revalidate_freq=2: OPcache re-checks file mtimes every 2s. Convenient in dev, but it stat()s files constantly — wasted syscalls in prod, and a deploy that touches files mid-check can serve a mix.
— validate_timestamps=0 + explicit reset: prod gold. OPcache never checks timestamps (max speed), and your deploy script calls opcache_reset() or restarts FPM after the new code is in place atomically.
— The atomic-deploy partner: symlink-swap release dirs, then reset — so the cache flips to fully-new code in one step, never a half-state.

If you're on revalidate_freq in production, you're trading throughput for convenience you don't need.

Bookmark: the PHP opcache.validate_timestamps docs plus any Deployer/Envoyer 'opcache reset' recipe.

A few channels in the webmaster & site monetization space worth your feed:

— @RPMReceipts — Real monetization numbers from real sites: RPM, EPMV, fill rate and…
— @AdSenseTrenches — Field notes from running real AdSense accounts: placement tweaks that…
— @NetworkMythHQ — We pressure-test what Ezoic, Mediavine and Raptive actually pay…
— @BidStack101 — Header bidding explained without the AdTech jargon: what Prebid,…
Each runs its own angle. Worth a scroll.

В роликах Youtube теперь можно рекламировать товары Amazone

➡️ Читайте на сайте: https://aff.top/blog/v-rolikakh-youtube-teper-mozhno-reklamirovat-tovary-amazone

🧠 Ещё больше инсайтов → в канале AFF.top

This week in caching: WP transients vs a persistent object cache

A WordPress-specific comparison that quietly decides your DB load:

— Transients without a persistent object cache store in the wp_options table — so your 'cache' is extra DB rows, and autoloaded options bloat every page load. The opposite of fast.
— Drop in Redis/Memcached as a persistent object cache and transients (plus all of WP's internal wp_cache_* calls) move to RAM — that's the actual win, not the page cache.
— The order people get wrong: they add a page-cache plugin and skip object cache, so logged-in users (who bypass page cache) still hammer MySQL.

For any membership/WooCommerce site where logged-in traffic matters, persistent object cache beats page cache for the users that count.

Bookmark: the Redis Object Cache plugin readme + WP's Transients API docs, read side by side.

Google выпустил Gemini Omni 1.1 Flash

Google обновил Gemini Omni для генерации видео: модель умеет продолжать сцены с учётом до 10 секунд контекста и собирать ролик до 40 секунд, работать по референсу и делать переходы между кадрами. Главный вывод — инструмент стал практичнее для продакшена, а посекундная цена делает его заметно доступнее для тестов и рабочих задач.

➡️ Читайте на сайте: https://aff.top/blog/google-vypustil-gemini-omni-1-1-flash

🧠 Ещё больше инсайтов → в канале AFF.top

Топ 5 PWA-сервисов для залива дейтинга

Статья показывает, что PWA выгодны не только для гемблы: в дейтинге они дают пуш-базу, больше траста и помогают маскировать оффер под бренд. Главный выбор зависит от цены инсталлов и теста GEO: для старта лучше бесплатные или дешёвые решения, а Progressier выделяется как самый практичный вариант для залива дейтинга.

➡️ Читайте на сайте: https://aff.top/blog/top-5-pwa-servisov-dlia-zaliva-deitinga

🧠 Ещё больше инсайтов → в канале AFF.top

🔥 Новый участник НеТОПа на AffPapa!
https://affpapa.org/netop

🏆 НеТОП на AffPapa — https://affpapa.org/netop/go/27?src=broadcast
Платный рейтинг индустрии: плати больше — стоишь выше. Займи место в топе за USDT.
💰 Ставка: $100 · сейчас #1 в рейтинге

This week in caching: negative caching vs just not caching errors

What to do when the origin returns a 404 or 500:

— No negative caching: every request for a missing/erroring URL hits the origin. A bad bot hammering 10k non-existent URLs becomes 10k origin requests — a cheap DoS on yourself.
— Negative caching: cache the 404 for a short TTL (say 30-60s) so repeat misses are absorbed at the edge. Big relief during scan/attack traffic.
— The danger: caching a transient 500 too long pins an outage in place after you've fixed it. Keep error TTLs tiny and pair with stale-if-error so a blip serves the last good copy instead of a cached failure.

Rule: short positive TTL on 404s, near-zero on 5xx, and never cache a 5xx longer than your deploy/rollback window.

Bookmark: Nginx's proxy_cache_valid docs — note you can set per-status-code TTLs, which is exactly the knob for this.

🔥 justbrand_create — новый участник рейтинга НеТОП на AffPapa!

🏆 Своё место в топе честно купил justbrand_create: https://affpapa.org/netop/go/28?src=broadcast

💰 Ставка: $111 · сейчас #1 в рейтинге

Весь рейтинг → https://affpapa.org/netop

This week in caching: in-process cache vs distributed cache

The layer people forget exists above Redis:

— In-process (APCu / array cache / local memory): lives in the PHP worker or app process — nanosecond reads, zero network hop. Unbeatable for tiny, hot, read-mostly data (config, feature flags, computed constants).
— Distributed (Redis/Memcached): shared across all servers, survives a worker restart, but every read is a network round-trip (sub-ms, but not free).
— The two-tier pattern: check APCu first, fall back to Redis, fall back to DB. Hottest keys never leave the process; shared state stays consistent across the fleet.
— The trap: putting per-server-mutable data in APCu and expecting consistency — each server has its own copy, so invalidation must hit all of them.

Use in-process for things that rarely change and are read constantly; Redis for everything shared.

Bookmark: Symfony's Cache component docs on chained adapters — clean reference for layering APCu over Redis.