DEV Community

Cover image for 11 Things every frontend developer should learn, and I mean it
Muhammad Usman
Muhammad Usman

Posted on • Originally published at Medium

11 Things every frontend developer should learn, and I mean it

#frontend #webdev #html #performance

This is not another recycled list. These are things I have seen developers skip, ignore, or just never bother learning, and it shows in their work. If you are serious about frontend, actually read this.

1. Semantic HTML structure

Semantic HTML structure

Most developers just throw divs everywhere and call it a day. That is wrong. Semantic HTML is not just for SEO, it is for accessibility, readability, and long-term maintainability.

Use the right tag for the right job. Use <header>, <main>, <footer>, <section>, and <article> instead of generic <div> soup. Use <nav> for navigation, <aside> for sidebars, and <figure> for images with captions. Screen readers and search engines both depend on this structure to understand your page.

Bad:

<div class="header">
<div class="nav">...</div>
</div>
Enter fullscreen mode Exit fullscreen mode

Good:

<header>
<nav>...</nav>
</header>
Enter fullscreen mode Exit fullscreen mode

2. Know when to use a heading tag and when not to

Heading tags have meaning. They tell search engines and screen readers what is important on your page. Misusing them breaks that hierarchy.

Here is a real example. ==Every website has that one CTA section with a big line like “Ready to get started?” and a button. A lot of developers slap an ====<h2>==== on it. Do not do that. That line is presentational, not structural. Use a ====<span>==== and style it to look big.==

Wrong:

<h2>Ready to get started?</h2>
Enter fullscreen mode Exit fullscreen mode

Right:

<span class="cta-heading">Ready to get started?</span>
Enter fullscreen mode Exit fullscreen mode

Save heading tags for content that actually structures the page. Use one <h1> per page, and be deliberate with <h2> and below.

3. Image optimization

Image optimization

No image on your website should exceed 100kb. That is a rule, not a suggestion. Unoptimized images are one of the biggest performance killers and most developers do not think twice about it.

What you should be doing:

  • Use WebP format. It is smaller than JPEG and PNG with no visible quality loss.
  • Use tools like Squoosh or Sharp (Node.js) to compress before shipping.
  • Always define width and height attributes on your images to prevent layout shift.
  • Use srcset to serve different sizes based on the device. 
<img
  src="hero.webp"
  srcset="hero-480.webp 480w, hero-800.webp 800w"
  sizes="(max-width: 600px) 480px, 800px"
  width="800"
  height="400"
  alt="Hero image"
/>
Enter fullscreen mode Exit fullscreen mode

4. Lazy loading and fetch priority

Lazy loading and fetch priority

Not everything needs to load at once. Lazy loading images and iframes below the fold is one of the easiest wins you can get for performance, and it takes literally one attribute.

But here is the part people miss. Your hero image should never be lazy loaded. It is above the fold, it is the first thing users see, and you want it loading as fast as possible. Use fetchpriority="high" on it.

<img src="hero.webp" fetchpriority="high" alt="Hero" />
Enter fullscreen mode Exit fullscreen mode

These two attributes together can make a measurable difference in your Largest Contentful Paint score.

5. Host Google Fonts locally

Everyone reaches for the Google Fonts CDN link without thinking about it. The problem is that is an extra DNS lookup, an extra connection, and an extra request on every page load. You are adding latency for no reason.

As you can see, the side effects of using Google fonts locally.

Performance improvement using local fonts and custom SVG icons

The fix is simple. Download the font files and serve them yourself.

@font-face {  font-family: "Inter";  src: url("/fonts/inter.woff2") format("woff2");  font-display: swap;}
Enter fullscreen mode Exit fullscreen mode

Use font-display: swap so your text stays visible while the font loads. Use woff2 format since every modern browser supports it and it is the smallest format available. You can use google-webfonts-helper to download the exact files you need with the right CSS already written for you.

6. Ditch Font Awesome CDN, use custom SVG icons

Font Awesome CDN loads hundreds of kilobytes of icons. You are probably using fifteen of them. That is a terrible trade-off for your performance.

Instead, use inline SVG icons. AI is genuinely good at generating clean SVG icon code. Ask it for exactly what you need and paste it in. You get the icon, nothing more.

<!-- Instead of loading Font Awesome for a simple arrow icon -->
<svg
  xmlns="http://www.w3.org/2000/svg"
  width="20"
  height="20"
  viewBox="0 0 24 24"
  fill="none"
  stroke="currentColor"
  stroke-width="2"
  stroke-linecap="round"
  stroke-linejoin="round"
>
  <line x1="5" y1="12" x2="19" y2="12" />
  <polyline points="12 5 19 12 12 19" />
</svg>
Enter fullscreen mode Exit fullscreen mode

SVG icons scale perfectly on any screen, support currentColor for easy theming, and add zero extra HTTP requests.

7. Build a design system, not a random collection of styles

Your spacing, sizing, colors, and fonts should follow a system. Not vibes. When every developer on a project makes up their own margin values, you end up with a codebase where nothing aligns and nothing is consistent.

Define your tokens once and use them everywhere:

:root {
  --color-primary: #2563eb;
  --color-text: #111827;
  --color-muted: #6b7280;
  --space-xs: 4px;
  --space-sm: 8px;
  --space-md: 16px;
  --space-lg: 32px;
  --space-xl: 64px;
  --text-sm: 0.875rem;
  --text-base: 1rem;
  --text-lg: 1.25rem;
  --text-xl: 1.5rem;
}
Enter fullscreen mode Exit fullscreen mode

Once you have this, every decision across the project becomes faster and more consistent. You stop debating whether to use 14px or 15px and just use --text-sm.

8. Write custom CSS instead of relying on third-party libraries

Write custom CSS

Tailwind, Bootstrap, and similar libraries are not evil, but leaning on them for everything bloats your project and creates a dependency you have to maintain. More importantly, it holds back your actual understanding of CSS.

When you write your own CSS, you know exactly what is on the page and why. Use the modern features that are available to you natively:

  • Use clamp() for fluid typography instead of hardcoded breakpoints.
  • Use grid and flex natively. You do not need a library for layout.
  • Use container queries to make components responsive based on their own size, not the viewport. 
/* Fluid font size without a single media query */
h1 {
font-size: clamp(1.5rem, 4vw, 3rem);
}
Enter fullscreen mode Exit fullscreen mode 
/* Container query example */
@container (min-width: 400px) {
.card {
flex-direction: row;
}
}
Enter fullscreen mode Exit fullscreen mode

9. ==Accessibility is not optional==

Accessibility

Semantic HTML gets you halfway there, but there is more to it. If a user cannot navigate your site with a keyboard, you have a broken website. It is that simple.

The basics you should always have covered:

  • Every interactive element must be reachable with Tab and operable with Enter or Space.
  • Never remove the focus outline without replacing it with something visible.
  • Use aria-label on icon buttons that have no visible text.
  • Ensure color contrast meets WCAG AA, which is a 4.5:1 ratio for normal text. 
<!-- Icon button with no visible label, always add aria-label --><button aria-label="Close menu">
<svg>...</svg>
</button>
Enter fullscreen mode Exit fullscreen mode

10. Know your Core Web Vitals

You should understand what LCP, CLS, and INP mean and how your decisions affect them. Not because Google says so, but because they measure things that actually matter to real users.

The final result

  • LCP (Largest Contentful Paint): how fast your main content appears. Optimize your hero image and server response time.
  • CLS (Cumulative Layout Shift): how much the page jumps around while loading. Always set image dimensions. Never inject content above existing content.
  • INP (Interaction to Next Paint): how fast the page responds to user input. Avoid long tasks on the main thread.

Open Chrome DevTools, run a Lighthouse audit, and actually look at what it tells you. This is how you verify that everything else on this list is actually working.

11. Sharpen your design eye

Sharpen your design eye

As AI gets better at writing code, the thing that will separate good frontend developers from the rest is design judgment. Knowing how to build something is no longer enough. You need to know how to make it look right.

This does not mean you need to become a full designer. It means you should study spacing and why things feel off when it is inconsistent. Learn basic typography rules like line height, line length, and font pairing. Look at sites you admire and ask yourself why they feel good. Practice in Figma or even just in the browser.

Having only one skill will not get you far. The frontend developers who are building things that actually stand out are the ones who can think about both the code and the result on the screen.

None of this is hard to learn. It is all just discipline. The developers who do these things consistently are the ones whose work looks and performs better than everyone else’s. Start with one, make it a habit, then move to the next.

Did you learn something good today as a developer?
Then show some love.
© Muhammad Usman
WordPress Developer | Website Strategist | SEO Specialist
Don’t forget to subscribe to Developer’s Journey to show your support.
Developer's Journey

Top comments (0)