Meta ограничивает расходы на токены для сотрудников

Meta ввела внутренние лимиты на использование ИИ из-за резкого роста расходов: в 2026 году только на сотрудников заложены миллиарды долларов, а общий бюджет на ИИ-инфраструктуру оценивается в 130–145 млрд. Вывод простой: даже у Big Tech ИИ перестал быть бесплатной игрушкой и требует жёсткого контроля затрат.

➡️ Читайте на сайте: https://aff.top/blog/meta-ogranichivaet-raskhody-na-tokeny-dlia-sotrudnikov

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

One Bricks query loop replaced 3 paid Elementor addons

A directory site ran Elementor Pro plus JetEngine, Crocoblock listings, and a filter addon, ~$300/year combined. We rebuilt the listing in native Bricks query loops with a custom filter.

Measured after switch:
— Three addon plugins removed entirely
— Listing page JS down 410KB
— Filtered query response time 820ms to 240ms

Pros:
— Killed recurring addon costs and update conflicts
— Native loops are far lighter than addon iframes

Cons:
— Custom filter took ~8 hours to hand-build
— No fancy addon UI; you write the markup

Best for: directory and listing sites drowning in addon plugins where native query loops can do the same job lighter.

Checklist: QA-ing responsive breakpoints before a builder page goes live

The builder's preview lies — test on real widths.
— Check the three default breakpoints, then add the gaps: 360px (small phones) and ~820px (tablet portrait), where layouts usually snap.
— Verify font sizes use fluid clamp/responsive units, not fixed per-breakpoint values you'll forget to update.
— Hunt for horizontal scroll: a single full-width element overflowing is the classic culprit.
— Test tap targets at 44px minimum; builder buttons often shrink below it on mobile.
— Confirm hidden-on-mobile elements aren't still loading (display:none still downloads images).

Pros:
— Catches the breakpoints the builder doesn't show by default.
— Prevents the most common mobile bug reports.

Cons:
— Manual; emulators miss real-device quirks.

Best for: any page before launch, especially template-driven layouts reused at scale.

Claude Cowork, Claude Design объединили в один Claude

➡️ Читайте на сайте: https://aff.top/blog/claude-cowork-claude-design-obedinili-v-odin-claude

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

Microsoft планирует вставлять рекламу в игры

➡️ Читайте на сайте: https://aff.top/blog/microsoft-planiruet-vstavliat-reklamu-v-igry

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

Playbook: cleanly removing an old builder after you've migrated off it

Deactivating isn't removing — the residue stays in your database.
— Confirm every URL is rebuilt and no live page still renders the old builder's output (search post_content for its shortcodes).
— Export/back up the DB before touching anything.
— Deactivate, then scan for orphaned shortcodes left in post_content and clean them.
— Drop the builder's custom meta keys and unused tables only after verifying they're not referenced.
— Re-crawl the site for broken layouts and 404s; check Search Console after a week.

Pros:
— Reclaims DB bloat and removes a security/update surface.
— Faster admin and cleaner exports going forward.

Cons:
— Irreversible if you miss a still-active page.
— Meta/table cleanup needs care to avoid data loss.

Best for: post-migration sites finishing the job instead of leaving a dormant plugin.

A template kit cut new-client onboarding from 3 weeks to 8 days

An agency rebuilt every new site from scratch. We packaged their common structure into one Elementor template kit: 9 page templates, a theme-builder set, and a global kit.

Tracked across the next 6 onboardings:
— Time-to-first-draft: ~15 working days to 6
— Revisions dropped because clients saw structure early
— One global-kit change rebranded a whole demo instantly

Pros:
— Faster cash flow; projects close sooner
— Consistent starting point reduced scope creep

Cons:
— ~30 hours to build and document the kit
— Templates can make every client site feel samey

Best for: agencies with a repeatable site shape that want to compress onboarding without hand-coding each start.

Myth: "Disable Google Fonts and your builder is lean again"

The advice everyone repeats: flip off Elementor's Google Fonts and you've fixed the page-weight problem. You haven't. Fonts are 30-80KB. The real weight is the DOM and CSS the builder ships on every page.

Pros of killing remote fonts:
— Removes one third-party request, helps privacy compliance
— Saves a DNS lookup

Cons / what it doesn't touch:
— Elementor 3.x still loads frontend.min.css, swiper, eicons regardless
— The nested div soup stays, that's your real layout-shift source
— Self-hosting fonts is the actual fix, not disabling

Verdict: a 50KB tweak sold as a performance cure. Real wins come from cutting widget CSS and unused global styles.

Best for: people who want a measurable but minor gain, not a bloat solution.

Template kits vs building from scratch
Import a kit or build clean? The tradeoff is speed vs bloat.

Template kit (Envato/builder library):
— Pros: full site live in an hour, designed sections, great for fast client mockups and pitches
— Cons: imports unused global styles, drags demo CSS/images, often 2-3x the DOM nodes you actually need

Build from scratch:
— Pros: only the markup you use, predictable page weight, no orphan CSS to debug later
— Cons: slow, you're re-solving solved layouts, easy to skip accessibility states

Best for: kits when speed-to-pitch wins and you'll prune after; scratch builds when the site must hit Core Web Vitals targets long-term.