Lazy loading экономит вес страницы, но легко режет конверсию, если вешать его на всё подряд

Lazy loading нужен там, где контент ниже первого экрана и не влияет на первый клик: картинки в ленте, отзывы, похожие товары, iframe с картами и видео. Для этого ставьте loading="lazy" или IntersectionObserver, но только после проверки: элемент не должен быть нужен для LCP, CLS или первого CTA.

Где ломает CR:
— hero-картинка и главный оффер: если они грузятся лениво, пользователь видит пустоту и уходит
— логотип, меню, форма заявки, кнопка оплаты: это должно быть доступно сразу
— блоки, которые двигают верстку: поздняя подгрузка без размеров создает скачки и бьет по довериям

На лендингах и прелендах правило простое: лениво грузим только «второй экран и ниже». Все, что помогает понять оффер за 2–3 секунды, должно быть в HTML или в приоритете загрузки. Для картинок задавайте width/height или aspect-ratio, иначе lazy loading превращается в CLS-генератор.

Если нужен быстрый чек: откройте страницу с отключенным кэшем, посмотрите, что видно без скролла, и сравните с тем, что реально отрисовано первым. Все важное — не lazy, все второстепенное — lazy.

ByteDance анонсировала новую версию SeeDance версии 2.5

ByteDance готовит релиз Seedance 2.5 — видеогенератора нового уровня. Главное улучшение: модель сможет создавать 30-секундные видео за один прогон без склеек, вместо нынешних 15 секунд. Добавили локальный монтаж отдельных кадров, поддержку 3D-болванок для управления камерой, возможность использовать до 50 референсов и генерацию в 4К сразу. Закрытый бета-тест идёт сейчас, открытый релиз ожидается в начале июля. Технологически это шаг вперёд, но д…

➡️ Читайте на сайте: https://aff.top/blog/bytedance-anonsirovala-novuiu-versiiu-seedance-versii-2-5

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

Codex уничтожит твой SSD за год

Разработчик обнаружил критический баг в Codex CLI от OpenAI: агент непрерывно записывает логи в локальную SQLite-базу, перезаписывая за 21 день 37 ТБ данных. При таком темпе типичный SSD объёмом 1 ТБ (рассчитанный на 600 ТБ перезаписей) выходит из строя менее чем за год. OpenAI осведомлена о проблеме, но пока не исправляет её. Пользователям остаётся либо ждать обновления, либо переключиться на альтернативные CLI-инструменты без подобных недостат…

➡️ Читайте на сайте: https://aff.top/blog/codex-unichtozhit-tvoi-ssd-za-god

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

Cloudflare Workers для лендингов: когда это реально работает, а когда мешает

Workers хорошо заходят, если лендинг должен быстро отвечать, резать гео/UA-ветку и не тащить тяжёлый backend. Типовой кейс: один HTML, несколько вариантов контента, A/B по cookie, редиректы, пререндер для ботов, защита формы от мусора.

Но как только на лендинге начинается логика уровня «корзина, личный кабинет, сложная авторизация, много запросов к БД» — Workers уже не основа, а тонкий слой перед основным приложением. Иначе получите удобную точку для роутинга, но боль в отладке и лимитах.

Где Workers полезнее всего:
— гео-роутинг без серверной геолокации;
— подмена UTM/параметров перед отдачей страницы;
— антибот на простых формах;
— быстрые 301/302 и каноникализация URL;
— cache key для разных сегментов аудитории.

Что проверить до запуска:
— не генерируете ли вы лишний JS на клиенте;
— не ломается ли кеш из-за cookie и query string;
— не уводите ли всю страницу в no-cache из-за одной динамической вставки;
— есть ли fallback, если Worker не отработал как задумано.

Главное правило: Workers должны сокращать путь до HTML, а не превращать лендинг в мини-приложение. Если задача укладывается в маршрутизацию, фильтрацию и лёгкую персонализацию — это их зона. Если нужна тяжёлая бизнес-логика, выносите её наружу.

DNS-провайдер выбирают не по бренду, а по задержке, API и удобству смены NS

DNS — это не «просто где лежат записи». Для рабочей сетки важны 3 вещи: скорость ответа авторитативных серверов, стабильность API для массовых правок и то, как быстро вы переживёте миграцию без косяков с TTL.

Cloudflare удобно брать, если нужен быстрый старт, нормальный UI и защита на уровне DNS-зоны. Плюс — любые записи правятся за минуту, есть жёсткие лимиты и понятная логика. Минус — когда у вас десятки зон и нестандартная автоматизация, интерфейс быстро упирается в ручную работу.

Route53 сильнее там, где DNS — часть инфраструктуры, а не отдельный сервис. Хороший вариант для IaC, шаблонов, автоматического создания зон и аккуратной работы с большим количеством доменов. Минус — интерфейс сухой, а лишний вызов API или кривой импорт зоны сразу виден в поддержке.

Альтернативы вроде Bunny DNS, DNSMadeEasy, NS1 или Hetzner DNS обычно берут ради простой панели, низкой цены или удачного геораспределения. Но перед переездом проверьте: SOA, NS, A/AAAA, MX, TXT для SPF/DKIM/DMARC, CAA и TTL. Самая частая авария — не провайдер, а забытая запись для почты или слишком высокий TTL.

Если нужен универсальный выбор: Cloudflare — для простоты и скорости, Route53 — для автоматизации и больших сеток, остальные — когда важны цена или узкая задача. Переносите зону только после полного экспорта и с пониженным TTL, иначе «экономия на DNS» легко превращается в простой сайта.

Google ужесточает модерацию финансовой вертикали

Google ужесточает модерацию финансовых офферов в ЕС и ЕЭЗ, введя двухэтапную верификацию через G2 Risk Solutions и Google Ads. Проверка затронет 24 страны, включая Австрию, Польшу, Нидерланды и другие члены союза. На прохождение модерации отводится 30 дней — за это время некоторые связки успеют отработать до вступления требований в силу. Для арбитражников это означает необходимость подготовиться к усложнению процесса запуска финансовых кампаний …

➡️ Читайте на сайте: https://aff.top/blog/google-uzhestochaet-moderaciiu-finansovoi-vertikali

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

Uptime-мониторинг для affiliate-сетки: 5 точек, которые надо проверять первыми

Если мониторить только главную — можно не увидеть падение преленда, API или редиректа. Для affiliate-инфраструктуры важны не «сайт жив», а цепочка: DNS → CDN → лендинг → postback → трекер → форма.

Держите минимум 5 проверок:
— HTTP 200 на главную и ключевой преленд
— ответ редирект-цепочки без лишних 3xx
— доступность postback URL
— валидность SSL и отсутствие просрочки
— скорость ответа, а не только факт ответа

Лучше ставить проверки из разных локаций и с интервалом 1–5 минут. Если один чекер падает, а остальные нет — это часто локальная сеть или фильтр, а не реальный даун. Для арбитража полезно отдельно мониторить cookie-баннер, формы и сервер трекера: они ломаются раньше, чем общий сайт.

Алерт должен идти туда, где его увидят сразу: Telegram, почта, SMS для критичных точек. И не ставьте авто-перезапуск на всё подряд: сначала лог, потом причина, потом действие.

Вывод простой: мониторьте не «сайт», а путь конверсии. Тогда падение преленда или postback вы поймаете раньше, чем оно съест трафик.

TLS termination не всегда должен жить на одном сервере с приложением

Если сайт маленький и стек простой, TLS termination можно держать прямо на Nginx/Apache рядом с app. Меньше звеньев, проще отладка, меньше точек отказа.

Если есть CDN или reverse proxy, часто разумнее завершать TLS на edge. Тогда до origin идёт уже обычный HTTP внутри защищённого контура, а сертификаты на приложении не нужны. Это упрощает ротацию и снижает нагрузку на backend.

Когда трафик растёт или есть несколько сервисов, termination лучше выносить на отдельный балансировщик или ingress. Так проще централизовать:
— сертификаты и renewals;
— HSTS, redirects, ciphers;
— mTLS между сервисами;
— аудит логов и доступов.

Не тащите TLS глубоко в каждый микросервис без причины. Чем больше мест, где живёт сертификат и приватный ключ, тем больше риск ошибок в конфиге и утечек. Если нужна внутренняя шифрация, включайте её точечно: между edge и origin, между балансировщиком и backend, между сервисами, которым это реально нужно.

Базовое правило простое: termination ставьте там, где заканчивается контроль над трафиком. На edge — для публичного сайта. На origin — если нужен end-to-end контроль. На отдельном прокси — если важны масштабирование и единая политика безопасности.

Fable 5 скоро вернётся в публичный доступ

В исходном коде Claude Code обнаружены упоминания о возвращении модели Fable 5 в публичный доступ с изменённой моделью распространения — её больше не потребуется покупать отдельно, вместо этого будет применяться недельный лимит как для других моделей. Если информация подтвердится, пользователи платных тарифов смогут использовать Fable 5 в рамках своих подписок. Причины снятия ограничений по национальной безопасности остаются неясными. Хотя это п…

➡️ Читайте на сайте: https://aff.top/blog/fable-5-skoro-vernetsia-v-publichnyi-dostup

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

Varnish, Cloudflare или NGINX: какую кэш-цепочку ставить, чтобы не ловить лишний TTFB

Если сайт на WordPress, лендингах или контентных страницах, кэш лучше строить слоями: браузер → CDN → reverse proxy → приложение. Ошибка — включить всё сразу без правил инвалидации: получаются «битые» корзины, старые цены и вечный bypass для авторизованных.

Cloudflare хорош как внешний щит и edge-cache для статики. Он снимает часть нагрузки, режет ботов, даёт правила по URL и cookies. Но как основной HTML-кэш он удобен не всегда: если логика сайта зависит от куки, гео или A/B-тестов, легко получить сложное исключение и трудно отлаживать очистку.

Varnish — сильный вариант для HTML-кэша перед NGINX или приложением. Он быстрый, прозрачно работает с cache hit/miss и удобно управляется по заголовкам. Минус один: сам по себе не защищает от мусорного трафика на уровне CDN и требует аккуратной purge-логики. NGINX cache проще в поддержке, если стек уже на одном сервере, но он хуже масштабируется как отдельный слой и чаще упирается в правила ключей.

Рабочая схема для большинства сайтов: Cloudflare держит статику, WAF и bot-filtering, Varnish кэширует HTML, NGINX отдаёт origin и служит fallback. Если команда маленькая, начните с NGINX cache; если много трафика и частые публикации — добавляйте Varnish; если нужен edge и защита — ставьте Cloudflare первым слоем.

Вывод: не выбирайте «один кэш на всё» — выбирайте роль каждого слоя и заранее продумайте purge, bypass и cache key.

Cloudflare Workers для лендингов: когда это экономит сервер, а когда только усложняет стек

Workers хороши там, где лендинг должен быть быстрым, простым и почти статичным: редиректы, A/B-логика на edge, подмена заголовков, гео-роутинг, выдача HTML из KV/R2, защита формы от мусора. Для прелендов и тестовых сеток это часто удобнее, чем держать отдельный VPS под каждый микроленд.

Но для обычного «одна страница + форма» Workers не всегда оправданы. Если на сайте только hero-блок, UTM-метки и отправка лида, проще держать статику на CDN, а обработку формы вынести в отдельный endpoint. Иначе получаешь ещё один слой логики, который надо дебажить.

На что смотреть перед переносом:
— нет ли тяжёлых библиотек и серверного рендеринга;
— не нужен ли долгий state на стороне сервера;
— укладывается ли код в ограничения платформы;
— можно ли без боли логировать ошибки и лиды;
— не завязан ли лендинг на сложные cookie-сценарии.

Хороший кейс для Workers — когда нужен edge-контроль до загрузки страницы: скрыть тестовый преленд от ботов, сделать простую маршрутизацию по странам, отдать разный CTA под сегменты трафика.

Плохой кейс — когда Worker превращают в «мини-бэкенд» с базой, очередями и кучей интеграций. Тогда проще и дешевле поднять нормальный API на VPS и оставить Workers только на перехват запросов и защиту.

Chat GPT-5.6 будут выдавать лишь избранным

США ограничивают публичный доступ к новым ИИ-моделям: теперь его выдают только проверенным пользователям после обязательной 30-дневной процедуры верификации. Сэм Альтман называет это самым быстрым путём к публичному релизу. Эффективность меры вызывает сомнения — китайские разработчики традиционно копируют модели в течение суток после выхода.

➡️ Читайте на сайте: https://aff.top/blog/chat-gpt-5-6-budut-vydavat-lish-izbrannym

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

Vk удалили из App store: что дальше?

Удаление VK из App Store заблокировало доступ для владельцев iPhone в России, но проблема решаема. Арбитражники теряют один канал, но не аудиторию — 20–30 млн пользователей iOS остались на месте. Вместо VK стоит переориентироваться на альтернативные источники: Telegram Ads с таргетингом на iOS, push-сети типа AdProfex, MTS Ads и Beeline Ads. VK может последовать примеру Max и запустить PWA-приложение для восстановления уведомлений. Главный вывод…

➡️ Читайте на сайте: https://aff.top/blog/vk-udalili-iz-app-store-chto-dalshe

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

DNS-провайдер — это не «где купить домен», а где ваш сайт отвечает быстрее и переживает сбои

У DNS важны три вещи: скорость ответа, удобство массовых правок и надёжность на пиках. Для небольшого проекта разница между провайдерами часто не в миллисекундах, а в том, сколько шагов нужно до рабочего record change, есть ли API и как быстро отрабатывает failover.

Cloudflare обычно берут за удобство и экосистему: быстрый UI, API, проксирование, WAF рядом с DNS. Но если вам нужен только DNS, не путайте «удобно» с «обязательно лучше». Route53 силён там, где нужны шаблоны, health checks, геораспределение и автоматизация через AWS. Для инфраструктуры в AWS это часто самый прямой путь без лишних костылей.

Из альтернатив чаще смотрят на Bunny DNS, NS1, DNSimple, Hetzner DNS. Смысл выбора такой:
— нужен простой и быстрый DNS для пары доменов — берите тот, где меньше лишних настроек;
— много зон и автодеплой — смотрите на API, Terraform, rate limits;
— нужен failover — проверяйте health checks и время переключения, а не только красивую панель.

Ошибка, которую вижу чаще всего: DNS живёт отдельно, а CDN, SSL и почта настроены «как-нибудь потом». В итоге меняют A-запись, ломают MX, забывают SPF/DKIM, получают долгий TTL и ждут обновления часами. Правильный порядок простой: сначала схема записей, потом TTL, потом автоматизация изменений.

Если доменов немного — выбирайте по удобству и качеству панели. Если инфраструктура растёт — DNS должен дружить с API, Terraform и мониторингом, иначе он станет узким местом.