DEV Community: Artclick

You Don't Need a CSS Framework in 2026 — the Platform Caught Up

Artclick — Mon, 03 Aug 2026 11:07:54 +0000

Here's the take: if you're reaching for a CSS framework in 2026 out of habit rather than a specific, named requirement, you're probably shipping more code than the problem needs. Not because frameworks got worse — because the platform quietly closed almost every gap they existed to patch.

This isn't "frameworks are bad." Bootstrap, Tailwind, and friends were the right call for most of the last decade, because CSS genuinely couldn't do the things they made easy. That's the part that's changed. Grid systems, component-level breakpoints, conditional styling, specificity control, color theming — these used to require a framework or a preprocessor because CSS itself had no answer. It has answers now, and most teams haven't gone back to check.

What frameworks were actually solving

To make the case fairly, it's worth naming what problem each piece of a typical framework was actually there for — because "just use vanilla CSS" has been bad advice for a decade, and I want to be specific about why it stopped being bad advice rather than just asserting it.

What you reached for	What it was actually working around
A 12-column grid system	CSS had no native concept of "columns that adapt to available space"
Sass nesting and variables	Flat CSS selectors got repetitive fast; no native scoping
Utility classes (`.mt-4`, `.flex`, `.text-center`)	Writing semantic class names for every one-off style was slow, and specificity was hard to manage at scale
A breakpoint mixin (`@include md { ... }`)	Media queries only ever knew the viewport, never the component's actual available space
A theme/color system	No native way to compute color variants (tints, shades, mixes) without precompiling every value
`.card:hover .card-title { ... }`-style JS toggles	CSS couldn't style a parent based on what's inside it

Every row in that table used to be true. None of them are anymore.

Grid and subgrid replace the 12-column system

CSS Grid has been supported everywhere for years, but the part that actually finished the job — subgrid — is what let go of the last reason to reach for a prebuilt column system. A grid of cards where each card's internal rows (image, title, meta, button) align across the whole row, not just within each card, used to need real work. Now it's a couple of lines:

.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
  gap: 1.5rem;
}

.card {
  display: grid;
  grid-template-rows: subgrid;
  grid-row: span 4;
}

That single auto-fit/minmax() line does the job of an entire responsive column system — it reflows the number of columns based on available width with zero media queries and zero JavaScript resize listeners.

Container queries replace component-level breakpoint hacks

This is the one that actually changes how you architect CSS, not just how you write it. A media query only ever knows the viewport. It has no idea if your card is in a wide main column or a narrow sidebar — which is exactly why component libraries ended up full of .card--compact modifier classes that had to be manually applied wherever a component landed in a tight space.

Container queries let the component ask about its own available space instead:

.card {
  container-type: inline-size;
}

@container (min-width: 380px) {
  .card__body {
    display: grid;
    grid-template-columns: 120px 1fr;
    gap: 1rem;
  }
}

Drop that same card into a sidebar, a modal, or a full-width section, and it adapts to whichever container it's actually sitting in — no modifier class, no JavaScript ResizeObserver, no knowledge of the page layout required at the component level at all. This is the single biggest reason a component library's "make it responsive" problem doesn't need a framework's help anymore.

`:has()` replaces a surprising amount of your JavaScript

:has() lets a parent's style depend on what's inside it — something CSS flatly couldn't do before, which is why so many small interactions ended up as JavaScript that toggled a class on a parent element whenever a child changed state.

/* Highlight a form field's wrapper only when it contains an invalid input */
.field:has(:invalid) {
  border-color: var(--color-danger);
}

/* Style a card differently if it happens to contain an image */
.card:has(img) {
  grid-template-rows: auto 1fr auto;
}

/* Style a fieldset's label based on a checkbox elsewhere in the same fieldset */
fieldset:has(input[type="checkbox"]:checked) legend {
  color: var(--color-accent);
}

Multiply that pattern across a real form or a component with a dozen conditional states, and :has() is quietly deleting hundreds of lines of state-toggling JavaScript that never needed to exist once CSS could ask the question directly.

Native nesting replaces the entire reason most teams installed Sass

If a project only used Sass for nesting and variables — which, honestly, describes most projects — there's no longer a reason to have a build step for it:

.nav {
  display: flex;

  ul {
    list-style: none;
    display: flex;
    gap: 1rem;

    li a {
      text-decoration: none;
      color: var(--color-text);

      &:hover {
        color: var(--color-accent);
      }
    }
  }
}

That's not a preprocessor output — it's what ships to the browser, unmodified. The CSS file structure mirrors the HTML structure, which was the actual appeal of Sass nesting the whole time. If your team's Sass usage is genuinely just this, the build step is now pure overhead: one more tool in the pipeline, one more thing that can break CI, for a feature the browser already has.

Cascade layers replace the specificity war utility classes were built to dodge

This is the one people miss. A big part of why utility-first frameworks feel necessary is that they sidestep CSS specificity entirely — every class has the same low specificity, so the last one written always wins, and you never fight .header .nav ul li a versus .nav-link.

@layer gives you that same guarantee without giving up semantic class names:

@layer reset, base, components, utilities;

@layer base {
  a { color: var(--color-text); }
}

@layer components {
  .card a { color: var(--color-accent); }
}

@layer utilities {
  .text-muted { color: var(--color-muted); }
}

Layers are resolved in the order they're declared, regardless of selector specificity or source order — a single class in utilities will always beat a deeply nested selector in components, on purpose, without an !important in sight. This was the actual argument for switching to utility classes: predictable override order. Cascade layers hand you that guarantee directly, so you can keep writing .card-title instead of .text-lg.font-bold.mb-2 and still win the specificity fight when you need to.

`color-mix()` and `oklch()` replace the theme-generation layer

Preprocessor color functions (darken(), lighten(), mix()) existed because plain CSS could only store a color, not compute a new one from it. That's gone too:

:root {
  --color-brand: oklch(58% 0.18 250);
}

.button:hover {
  background: color-mix(in oklch, var(--color-brand), white 15%);
}

.button:active {
  background: color-mix(in oklch, var(--color-brand), black 15%);
}

oklch() also happens to interpolate more predictably than hex or RGB — mixing two OKLCH colors doesn't produce the muddy, desaturated middle tones you get from mixing in RGB space, which was always the annoying part of building a tint/shade scale by hand.

`clamp()` replaces the typography-scale mixin

This one you may already be doing — it's the same technique from fluid typography with clamp(), but it's worth restating as part of the bigger case: a whole category of "responsive spacing/type scale" mixins collapses into single-property declarations:

h1 {
  font-size: clamp(2rem, 1.2rem + 3vw, 3.5rem);
}

.section {
  padding-block: clamp(2rem, 5vw, 6rem);
}

No breakpoint table, no mixin, no JavaScript recalculating on resize — the value scales continuously with the viewport and clamps at both ends.

Where a framework still earns its keep

None of this means frameworks are pointless now — it means their remaining justification is narrower and more specific than "CSS is hard," and worth naming honestly:

Prebuilt, accessible interactive components. A native <dialog> or <details> handles a lot, but a fully-featured date picker, combobox, or rich data table with proper ARIA behavior is still real work that a component library has already done correctly.
Enforced consistency across a large team. A design system with strict, enforced tokens (via a utility framework's config) can genuinely prevent drift better than a style guide people are supposed to remember to follow — this is a people problem as much as a technical one, and utility classes are a decent people-problem solution.
Faster prototyping under real time pressure. Reaching for known utility classes is still faster than making design decisions from scratch when you're throwing together an internal tool by Friday.
Legacy browser support. If your analytics show a meaningful slice of traffic on genuinely old browsers, several of the features above aren't available to them, and a framework's fallback behavior earns its cost.

If your actual situation is one of these, that's a real reason — not a rationalization. The point isn't "never use a framework." It's that "we've always used one" stopped being a technical reason sometime in the last two years, and it's worth checking which category your project is actually in.

A worked example: the thing frameworks were built for

Here's the classic case — a responsive card grid where cards need internal layout that adapts to available space, not just viewport width — built with nothing but the platform:

<section class="card-grid">
  <article class="card">
    <img src="thumb.jpg" alt="" />
    <div class="card__body">
      <h3>Card title</h3>
      <p>Supporting copy that might run long or short.</p>
    </div>
  </article>
  <!-- more cards -->
</section>

.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
  gap: 1.5rem;
}

.card {
  container-type: inline-size;
  border: 1px solid var(--color-border);
  border-radius: 0.75rem;
  overflow: clip;

  img {
    width: 100%;
    aspect-ratio: 16 / 9;
    object-fit: cover;
  }

  &:has(img) .card__body {
    padding-block-start: 1rem;
  }

  &__body {
    padding: 1rem 1.25rem;

    h3 {
      font-size: clamp(1.1rem, 1rem + 0.5vw, 1.35rem);
      margin: 0 0 0.5rem;
    }
  }
}

@container (min-width: 360px) {
  .card__body {
    display: grid;
    grid-template-columns: 1fr auto;
    align-items: start;
  }
}

No grid framework, no Sass, no JavaScript, and it responds to its own container rather than the viewport. Five years ago this genuinely required either a framework or a pile of custom code to get right; now it's the direct, obvious way to write it.

Why the habit outlasts the reason

If none of this is news to you, that's exactly the point — most of these features have been broadly supported for a year or more, and adoption still lags the capability by a wide margin. That's not a technical gap anymore, it's an inertia gap: framework choice gets made once at a project's start, rarely revisited, and "the team already knows Tailwind" is a perfectly good reason to keep using it on an existing codebase. It's a much weaker reason to reach for it by default on a new one.

The honest version of this take isn't "rip out your framework." It's: the next time you start a project and install one out of reflex, spend fifteen minutes checking whether the specific problem you're reaching for it to solve is actually still a problem. For a lot of projects in 2026, the answer is genuinely no.

Am I wrong about this? What's the actual dealbreaker keeping your team on a framework right now — I'd genuinely like to know what I'm missing.

At ArtClick, we build fast, scalable WordPress websites, company websites and custom web systems that balance design, performance and long-term maintainability. Whether you're starting from scratch or improving an existing platform, we'd love to help.

https://artclickdev.com/

Build a Modern Chat UI with Just CSS and JavaScript

Artclick — Mon, 03 Aug 2026 10:10:41 +0000

Chat interfaces are everywhere now — support widgets, team tools, AI assistants, in-app messaging. They all share the same underlying patterns, and none of them actually require a framework or a component library to get right. A well-built chat UI is mostly a handful of CSS decisions and a couple of small, deliberate JavaScript behaviors.

This walks through building one from scratch: the markup, the bubble styling, a typing indicator, smart auto-scrolling, message grouping, dark mode, and the accessibility details that are easy to miss.

What actually makes a chat UI feel right

Before touching code, it helps to name the specific things that separate a chat UI that feels considered from one that feels like a plain list of <div>s:

Sent vs. received is instantly visually distinct — usually via alignment and color, not color alone.
Consecutive messages from the same person are visually grouped, not repeated with a full avatar/timestamp every time.
New messages don't fight the user for scroll position. If someone has scrolled up to reread something, a new message shouldn't yank them back down.
A typing indicator communicates "still here" without being distracting.
Screen readers get told about new messages without interrupting whatever the user is currently doing.

Everything below is really just these five ideas turned into CSS and JS.

The markup

Keep it semantic — a list of messages, each one a list item, grouped inside a labeled region:

<section class="chat-window" aria-label="Conversation">
  <ul class="chat-log" id="chatLog" aria-live="polite">
    <li class="message message--received">
      <img class="avatar" src="avatar.jpg" alt="">
      <div class="bubble">
        <p>Hey, are we still on for the call at 3?</p>
        <time datetime="2026-08-03T14:58">2:58 PM</time>
      </div>
    </li>
    <li class="message message--sent">
      <div class="bubble">
        <p>Yep, I'll send the doc beforehand.</p>
        <time datetime="2026-08-03T14:59">2:59 PM</time>
      </div>
    </li>
  </ul>
</section>

Note the aria-live="polite" on the log itself — that one attribute does most of the accessibility work for announcing new messages, and it's easy to forget entirely.

Styling the bubbles

The core trick is flipping flex-direction for sent messages and shaving one corner off each bubble to fake a "tail" pointing toward its sender:

.chat-log {
  list-style: none;
  display: flex;
  flex-direction: column;
  gap: 0.75rem;
  padding: 1rem;
  margin: 0;
}

.message {
  display: flex;
  align-items: flex-end;
  gap: 0.5rem;
  max-width: 75%;
}

.message--sent {
  align-self: flex-end;
  flex-direction: row-reverse;
}

.bubble {
  background: var(--bubble-received, #eef0f3);
  color: var(--text-color, #1a1a1a);
  padding: 0.6rem 0.9rem;
  border-radius: 1.1rem;
}

.message--sent .bubble {
  background: var(--bubble-sent, #4b7bec);
  color: #fff;
  border-bottom-right-radius: 0.3rem;
}

.message--received .bubble {
  border-bottom-left-radius: 0.3rem;
}

.bubble time {
  display: block;
  margin-top: 0.25rem;
  font-size: 0.7rem;
  opacity: 0.65;
}

max-width: 75% keeps long messages from stretching edge-to-edge, which is what makes a chat window read as "a conversation" instead of "a document."

A typing indicator that doesn't feel janky

Three dots, staggered animation delays, done with pure CSS:

.typing {
  display: flex;
  gap: 4px;
  padding: 0.6rem 0.9rem;
}

.typing span {
  width: 6px;
  height: 6px;
  border-radius: 50%;
  background: currentColor;
  opacity: 0.4;
  animation: typing-bounce 1.2s infinite ease-in-out;
}

.typing span:nth-child(2) { animation-delay: 0.15s; }
.typing span:nth-child(3) { animation-delay: 0.3s; }

@keyframes typing-bounce {
  0%, 60%, 100% { transform: translateY(0); opacity: 0.4; }
  30% { transform: translateY(-4px); opacity: 1; }
}

Because this animates transform and opacity rather than top/height, it runs on the compositor thread — smooth even on a busy page, and it won't trigger layout on every frame.

Auto-scroll — but only when the user would want it

Don't force-scroll to the bottom on every new message — only do it if the user was already near the bottom:

const chatLog = document.getElementById('chatLog');

function isNearBottom() {
  const threshold = 120; // px
  return chatLog.scrollHeight - chatLog.scrollTop - chatLog.clientHeight < threshold;
}

function appendMessage(html) {
  const shouldStick = isNearBottom();
  chatLog.insertAdjacentHTML('beforeend', html);
  if (shouldStick) {
    chatLog.scrollTop = chatLog.scrollHeight;
  }
}

If someone has scrolled up to reread earlier messages, this leaves them exactly where they are instead of yanking them back down when a new message arrives.

Grouping consecutive messages

When the same person sends several messages in a row, repeating the avatar and timestamp on every single one adds visual noise. Group them if the sender matches and the gap is small:

function shouldGroup(current, previous) {
  if (!previous || current.sender !== previous.sender) return false;
  const gapMs = new Date(current.timestamp) - new Date(previous.timestamp);
  return gapMs < 2 * 60 * 1000; // 2 minutes
}

.message--grouped {
  margin-top: -0.4rem;
}

.message--grouped .avatar,
.message--grouped time {
  visibility: hidden;
}

Hiding rather than removing keeps the layout width consistent — the avatar still occupies its column, it just isn't drawn.

Dark mode, without duplicating every rule

Define the handful of colors that actually change as custom properties once, then swap them under a data-theme attribute:

:root {
  --bg: #ffffff;
  --text-color: #1a1a1a;
  --bubble-received: #eef0f3;
  --bubble-sent: #4b7bec;
}

[data-theme="dark"] {
  --bg: #14171c;
  --text-color: #e8eaed;
  --bubble-received: #262b33;
  --bubble-sent: #5b8dfc;
}

Toggle data-theme on <html> or <body> with a few lines of JS, and optionally default it from prefers-color-scheme on first load so the chat window matches the user's system setting before they've touched anything.

The accessibility details that get skipped

aria-live="polite" on the message log (already in the markup above) announces new messages without interrupting whatever the screen reader is currently reading.
Don't rely on color alone to distinguish sent from received — alignment already does most of that work here, which is exactly why it matters more than color.
Don't steal focus. A new incoming message shouldn't move keyboard focus away from wherever the user currently is, especially not away from an open text input.
Respect reduced motion for the typing indicator:

@media (prefers-reduced-motion: reduce) {
  .typing span {
    animation: none;
    opacity: 0.6;
  }
}

Keeping it fast as history grows

A chat log is one of the easiest UIs to accidentally make slow, because it's the one place where the DOM keeps growing indefinitely.

Don't keep unlimited history in the DOM. Virtualize (render only messages near the viewport) or paginate older messages behind a "load earlier messages" action.
Batch DOM writes when inserting many messages at once — build a DocumentFragment and insert it in one operation instead of appending message-by-message, which forces a reflow on every single insert.
Debounce scroll listeners if you're using scroll position to trigger loading older history — a raw scroll event fires far more often than you need it to.

Wrapping up

None of this requires a framework, a state management library, or a UI kit. A chat interface that feels genuinely well-made comes down to a small set of deliberate choices: clear sent/received distinction, message grouping, scroll that respects what the user is doing, an accessible live region, and a bit of care around performance as history grows. Get those right and the rest is just visual polish on top.

https://artclickdev.com/

How to Improve Website Performance Without Sacrificing Design

Artclick — Mon, 03 Aug 2026 06:08:03 +0000

There's a myth floating around every design review and dev standup: that you have to choose between a beautiful website and a fast one. Product wants the parallax hero. Design wants the custom typeface and the smooth scroll animations. Engineering wants a green Lighthouse score. Everyone assumes someone has to lose.

They don't. In almost every case where I've seen "performance vs. design" framed as a trade-off, the real problem wasn't the design intent — it was the implementation. A hero image can be visually stunning and load in under a second. A scroll animation can feel buttery and never touch the main thread. The tension usually comes from reaching for the heaviest tool available (a 300KB carousel library, an unoptimized 4K JPEG, five different font weights) instead of the lightest one that gets the same visual result.

TL;DR — Most performance problems aren't design problems. They're image, font, JavaScript, and third-party-script problems wearing a design costume. Below are 12 concrete places to fix the delivery layer without touching the design itself.

Why this matters more in 2026 than it used to

Google evaluates real-world page experience through three Core Web Vitals, measured from actual Chrome users in the field (not just your local Lighthouse run):

Metric	What it measures	"Good" threshold
LCP (Largest Contentful Paint)	How fast the main content appears	Under 2.5s
INP (Interaction to Next Paint)	How responsive the page feels to clicks/taps	Under 200ms
CLS (Cumulative Layout Shift)	How visually stable the page is while loading	Under 0.1

These are scored at the 75th percentile of real visitors over a rolling window, which means a fast dev laptop on fiber tells you almost nothing — you're being judged on the experience of your slowest quarter of visitors, usually on mid-range phones over patchy connections. INP in particular (which replaced First Input Delay back in March 2024) tends to be the hardest one to pass, because it's a direct tax on however much JavaScript you're shipping and executing.

The reason this matters beyond vanity metrics: slow, janky pages measurably cost conversions, session time, and organic visibility. The fix isn't "make it uglier." It's "make it lighter." Here's where to start.

1. Serve modern, correctly-sized image formats

Images are usually the largest chunk of a page's weight by far, and also the easiest place to claw back performance without touching the design at all. WebP and AVIF routinely cut file size by 30–60% over JPEG/PNG at visually identical quality. Use a <picture> element so you degrade gracefully for anything that doesn't support the newer format:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Product dashboard preview" width="1200" height="675">
</picture>

2. Ship the right image size for each viewport

A 2400px-wide image scaled down with CSS is still a 2400px-wide download. Use srcset and sizes so the browser picks the right file for the viewport instead of forcing everyone to download the desktop version:

<img
  src="card-800.jpg"
  srcset="card-400.jpg 400w, card-800.jpg 800w, card-1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, 50vw"
  alt="Feature card"
  loading="lazy"
>

3. Reserve layout space to kill Cumulative Layout Shift

Every image, video, and embed should have explicit dimensions or an aspect-ratio so the browser reserves space before the file loads. This alone eliminates most CLS issues, and it costs nothing visually:

.card-image {
  width: 100%;
  aspect-ratio: 16 / 9;
  object-fit: cover;
}

4. Lazy-load everything except what's above the fold

Add loading="lazy" to offscreen images, but do the opposite for your LCP element (usually the hero image) — load it eagerly and consider fetchpriority="high" so the browser prioritizes it in the request queue.

5. Use variable fonts and smart font-loading

Distinctive type is one of the fastest ways to make a site feel designed rather than templated — but five weights times two families times italics adds up to a lot of render-blocking font requests. A single variable font file can replace six or eight static weight files, with a smoother range of weights as a bonus. Pair it with:

font-display: swap so text renders in a fallback font immediately instead of staying invisible while the custom font downloads.
Preloading your critical font (usually body or headline) in the <head> so it starts downloading before CSS is even parsed.
Subsetting to the character sets you actually use — most Latin-only sites don't need Cyrillic or CJK glyphs bundled in.

6. Scale type fluidly instead of stacking breakpoints

Maintaining a dozen breakpoint-specific font sizes means more CSS, more overrides, and more specificity fights. A single clamp() value scales smoothly across viewport widths instead:

:root {
  --fs-headline: clamp(1.75rem, 1.1rem + 3vw, 3.25rem);
}

h1 { font-size: var(--fs-headline); }

Mixing a fixed rem floor, a vw-based fluid middle, and a fixed rem ceiling gives predictable scaling at the extremes and organic growth in between — no media query needed for the type scale itself.

7. Replace JS libraries with native HTML/CSS where you can

A huge amount of "we need this library" is actually solvable with a browser feature that's shipped for years:

Common JS solution	Native alternative
Accordion library	`<details><summary>`
Modal library	Native `<dialog>` element
Carousel plugin	CSS `scroll-snap-type` + `overflow-x: auto`
Sticky positioning via scroll listener	`position: sticky`
JS-calculated centering	`transform: translate(-50%, -50%)` or Grid/Flex centering
Responsive breakpoint grid libraries	CSS Grid with `auto-fit`/`minmax()`, or container queries

8. Animate transform and opacity, not layout properties

Animating top, left, width, or height forces the browser to recalculate layout on every frame. Animating transform and opacity instead runs on the compositor thread — smoother motion, zero layout thrashing, and it directly protects your INP score:

/* Avoid: triggers layout on every frame */
.card:hover { top: -8px; }

/* Prefer: GPU-accelerated, no reflow */
.card:hover { transform: translateY(-8px); }

Always pair this with a prefers-reduced-motion media query — one line, and it matters for both accessibility and perceived performance for users who've opted out of motion.

9. Code-split and defer JavaScript, then break up long tasks

Every dependency you ship has to be downloaded, parsed, compiled, and executed before it does anything useful — and on a mid-range phone that CPU cost is often far more expensive than the network cost. This is where most INP problems are born.

Code-split by route or component so users only download what the current page needs.
Defer or async non-critical scripts so they don't block the initial render.
Question every dependency. If you're importing a 40KB date-picker for a single form field, a native <input type="date"> might do 90% of the job for free.
Break up long tasks. If a single script keeps the main thread busy for 200ms+, every click during that window feels laggy — chunk the work or yield back to the browser between steps.

10. Audit and lazy-load third-party scripts

Chat widgets, analytics suites, marketing pixels, and embedded social widgets are frequently the single biggest chunk of unaccounted-for JavaScript on a page — and they're the easiest to forget because a developer didn't write them. Audit them regularly, lazy-load anything that isn't needed immediately (a chat widget doesn't need to load before the user has been on the page for a few seconds), and remove anything nobody's checked the dashboard for in six months.

11. Set a performance budget and bring it into design reviews

The most durable fix isn't a single optimization — it's a workflow that keeps performance from silently regressing as a site grows.

Set a performance budget up front — a total page-weight target or a JS budget — and treat it the same way you'd treat a design spec.
Prototype interactions in CSS first. Reach for JavaScript only once you've confirmed CSS genuinely can't do it.
Build a component library with performance baked in (optimized images, correct font-loading, GPU-friendly animations by default) so every new page inherits good defaults.
Bring performance into design reviews, not just code reviews. A designer who knows a full-bleed video hero has a measurable LCP cost can make an informed call about whether it's worth it.

12. If you're on WordPress, watch plugin and builder weight

WordPress powers a huge share of the web, and it's also where I see this trade-off get treated as unavoidable most often — usually because of accumulated plugin weight rather than WordPress itself.

Pick a lean, well-coded theme over a heavy all-in-one page builder. Builders that inject their own CSS/JS framework on every page add overhead even where it's unused.
Audit plugins ruthlessly. Each one is a potential render-blocking stylesheet or script, whether or not it's doing anything on the current page.
Use caching and image-optimization plugins as a supplement to fixing root causes, not a replacement — a caching layer can't fix a 4MB unoptimized hero image.
Prefer native Gutenberg blocks for layout where possible over a third-party builder's custom block library, which usually ships more CSS/JS than the native editor.

Measuring: don't guess, check the field data

Lab tools like Lighthouse and PageSpeed Insights are great for quick local iteration, but they're a simulation. The scores that actually count are field data — real Chrome users, captured in the Chrome UX Report (CrUX) and surfaced in Google Search Console. Field data updates on a rolling ~28-day window, so give a fix a few weeks before judging whether it worked. A practical loop:

Check Search Console's Core Web Vitals report to find pages in the "poor" or "needs improvement" band.
Run PageSpeed Insights on those specific URLs to get a diagnostic breakdown.
Use Chrome DevTools' Performance panel to find the actual bottleneck — a network waterfall for LCP, long tasks for INP, or the layout shift overlay for CLS.
Fix the metric furthest from "good" first. Don't spend time optimizing a metric that's already green.
Re-test, then wait for the CrUX window to confirm it in field data.

Quick reference checklist

Images served in WebP/AVIF with a JPEG/PNG fallback
srcset/sizes used so devices don't download oversized images
Every image/video has explicit dimensions or aspect-ratio
Offscreen images lazy-loaded; hero/LCP image loaded eagerly
Variable fonts used where possible, with font-display: swap
Critical font preloaded; unused character sets subsetted out
Fluid type scales (clamp()) instead of a dozen breakpoint overrides
Native HTML/CSS used before reaching for a JS library
Animations use transform/opacity, not layout-triggering properties
JS code-split, deferred/async, and audited for what's actually used
Third-party scripts audited and lazy-loaded where possible
Performance budget agreed with design/product up front
Field data (CrUX / Search Console) checked, not just lab scores

The real takeaway

Performance and design aren't opposing forces pulling a project in different directions — they're both just requirements. Once you stop treating speed as an afterthought bolted on at the end of a project, and start treating it as a design constraint from day one (the same way you'd treat accessibility or brand consistency), the "trade-off" mostly disappears. The sites that feel both fast and beautiful aren't the ones that compromised on design. They're the ones that were disciplined about implementation.

https://artclickdev.com/

DEV Community: Artclick

You Don't Need a CSS Framework in 2026 — the Platform Caught Up

What frameworks were actually solving

Grid and subgrid replace the 12-column system

Container queries replace component-level breakpoint hacks

:has() replaces a surprising amount of your JavaScript

Native nesting replaces the entire reason most teams installed Sass

Cascade layers replace the specificity war utility classes were built to dodge

color-mix() and oklch() replace the theme-generation layer

clamp() replaces the typography-scale mixin

Where a framework still earns its keep

A worked example: the thing frameworks were built for

Why the habit outlasts the reason

Build a Modern Chat UI with Just CSS and JavaScript

What actually makes a chat UI feel right

The markup

Styling the bubbles

A typing indicator that doesn't feel janky

Auto-scroll — but only when the user would want it

Grouping consecutive messages

Dark mode, without duplicating every rule

The accessibility details that get skipped

Keeping it fast as history grows

Wrapping up

How to Improve Website Performance Without Sacrificing Design

Why this matters more in 2026 than it used to

1. Serve modern, correctly-sized image formats

2. Ship the right image size for each viewport

3. Reserve layout space to kill Cumulative Layout Shift

4. Lazy-load everything except what's above the fold

5. Use variable fonts and smart font-loading

6. Scale type fluidly instead of stacking breakpoints

7. Replace JS libraries with native HTML/CSS where you can

8. Animate transform and opacity, not layout properties

9. Code-split and defer JavaScript, then break up long tasks

10. Audit and lazy-load third-party scripts

11. Set a performance budget and bring it into design reviews

12. If you're on WordPress, watch plugin and builder weight

Measuring: don't guess, check the field data

Quick reference checklist

The real takeaway

`:has()` replaces a surprising amount of your JavaScript

`color-mix()` and `oklch()` replace the theme-generation layer

`clamp()` replaces the typography-scale mixin