Checklist · Stacks and tools
Web Performance Checklist
Opens with creditsA release checklist for fast websites, organised around the three Core Web Vitals and the guidance on web.dev. Each check says how much it matters and exactly how to confirm it, from field data and server response time to the LCP image, long tasks, layout shifts, fonts, the back/forward cache and monitoring after release.
Written by Tauseef Fayyaz8 chapters, 35 checksAbout 22 minReviewed 13 October 2026What you will learn
8 chapters · about 22 min
1Measure before you optimiseKnow which metric is failing for real users before you change anything. These checks set up field data, lab tools and the right targets.4 checks · 3 min
2Server response and TTFBEvery millisecond before the first byte delays everything after it. These checks keep the server, redirects and caching from eating the LCP budget.4 checks · 2 min
- LCP and imagesThe largest element on screen is usually an image or a heading. These checks get it discovered, fetched and painted as early as possible.6 checks · 4 minOpens with credits
- JavaScript and INPResponsiveness is about keeping the main thread free. These checks break up long tasks, slim event handlers and keep rendering cheap.6 checks · 4 minOpens with credits
- CLS and layout stabilityContent that jumps makes people tap the wrong thing. These checks reserve space before content arrives and animate without moving layout.4 checks · 2 minOpens with credits
- Fonts and CSSWeb fonts and stylesheets block text and cause late reflows. These checks load them early and keep the fallback close to the final look.3 checks · 2 minOpens with credits
- Caching, delivery and the back/forward cacheRepeat visits and back navigations should be close to instant. These checks cover HTTP caching, compression, code splitting and keeping pages eligible for the back/forward cache.5 checks · 3 minOpens with credits
- Monitoring and budgetsPerformance regresses one small change at a time. These checks make regressions visible before users notice them.3 checks · 2 minOpens with credits
About this checklist
This web performance checklist is what you go through before a release, or when a page feels slow and you need to find out why. It is built on Core Web Vitals, the three metrics Google uses to describe real user experience: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness and Cumulative Layout Shift (CLS) for visual stability. Every threshold and technique here comes from the guidance published on web.dev.
The targets are simple to state. LCP should be 2.5 seconds or less, INP 200 milliseconds or less and CLS 0.1 or less, measured at the 75th percentile of real page loads, separately for mobile and desktop. A page passes only when all three meet the target at that percentile. That is why the first chapter is about measuring real users, not just running a lab test on a fast laptop.
Every check has a severity. A must is something that is very likely hurting your users today, a should closes a common gap, and a nice adds polish once the basics are in place. Every check also says how to verify it: a panel in Chrome DevTools, a Lighthouse audit, a field report, a header to read with curl. Ticking a box without that evidence is how a site ends up with a perfect lab score and slow pages for real visitors.
Work through it with your site deployed somewhere close to production and DevTools open. Start with field data so you know which metric is failing, then jump to that chapter first.
Common questions
What are good Core Web Vitals scores?
LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less. They are measured at the 75th percentile of real page loads, separately for mobile and desktop, and a page passes only when all three are good at that percentile.
Why is my Lighthouse score good but Core Web Vitals failing?
Lighthouse is a lab test on one simulated device, while Core Web Vitals come from real users on their own phones and networks. Lighthouse also cannot measure INP because it does not interact with the page; it reports Total Blocking Time instead. Trust field data from CrUX, PageSpeed Insights or your own web-vitals collection for the verdict, and use lab tools to find causes.
What replaced First Input Delay?
Interaction to Next Paint (INP) is the Core Web Vital for responsiveness. It measures the time from a user interaction to the next frame the browser paints, across input delay, processing and presentation delay. Above 500 milliseconds is considered poor.
Should I lazy-load all images?
No. Lazy-load images below the fold, but never the LCP image, because lazy loading always adds delay to it. Give the LCP image fetchpriority="high" and make sure it is in the initial HTML.
What is a long task?
Any task on the main thread that runs longer than 50 milliseconds. While it runs the browser cannot respond to input, so long tasks raise INP. Break them up and yield to the main thread with scheduler.yield(), falling back to setTimeout where it is not supported.
Sources (8)
Checked against these, last on 13 October 2026.
- Web Vitals, web.devweb.dev/articles/vitals
- Optimize Largest Contentful Paint, web.devweb.dev/articles/optimize-lcp
- Interaction to Next Paint (INP), web.devweb.dev/articles/inp
- Optimize Interaction to Next Paint, web.devweb.dev/articles/optimize-inp
- Optimize long tasks, web.devweb.dev/articles/optimize-long-tasks
- Optimize Cumulative Layout Shift, web.devweb.dev/articles/optimize-cls
- Time to First Byte (TTFB), web.devweb.dev/articles/ttfb
- Back/forward cache, web.devweb.dev/articles/bfcache
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See allBest practices
See all- TypeScript Best PracticesModern TypeScript best practices for 2026: strict settings, TypeScript 7, modeling data with unions, safe narrowing, runtime validation, generics and typed linting.
- Next.js App Router Best PracticesNext.js 16 App Router best practices: Server Components, Cache Components and use cache, secure Server Actions, proxy.ts, metadata and images.
- React Best PracticesModern React best practices for 2026: pure components, lean state, fewer effects, React Compiler, form actions, accessibility and testing.
Checklists
See all- Web Accessibility ChecklistA practical web accessibility checklist built on WCAG 2.2 level AA, with a severity and a concrete way to verify every check.
- Web Application Security ChecklistA practical web application security checklist built on the OWASP Top 10:2025 and ASVS 5.0, with a severity and a way to verify every check.
- Developer Portfolio Website ChecklistCheck your developer portfolio site end to end: clear intro, 3 to 5 strong projects, live demos and code, speed, accessibility, SEO basics, custom domain, contact, analytics and upkeep.
Project structures
See all- MERN (MongoDB, Express, React, Node) project structureOne repository with a React app built by Vite in client/, an Express API with Mongoose in server/, and a tiny shared/ package that both import for request shapes and types. npm workspaces give you one install and one command to run both, and one example feature (clinic appointments) runs through every folder so you can see how a request travels from a form to MongoDB and back, and what tests, security and operations a real team adds around it.
- Next.js full stack (database and auth) project structureOne Next.js app that is both your frontend and your backend: pages render on the server, forms call Server Actions, and Route Handlers serve the few real HTTP endpoints (auth, webhooks, jobs, health). PostgreSQL through Prisma ORM, sign-in through Better Auth, background jobs with Inngest, and every database read goes through a small Data Access Layer that checks who is asking. The example features are invoices and clients for freelancers.
- .NET with Angular project structureThe common enterprise pairing: an ASP.NET Core Web API and an Angular app as two projects in one solution, exactly as the Visual Studio template lays them out. In development the Angular dev server proxies API calls to .NET; in production the API serves the built Angular files from one origin, so cookie sign-in with ASP.NET Core Identity just works. The Angular API client is generated from the API's OpenAPI document, so both sides always agree. The example features are orders and products.
Career questions
See all- What should I learn to become a web developer, and in what order?Learn the web platform first (HTML, CSS, JavaScript, how HTTP works), then one frontend framework, then a backend with a database, and build a real project at each stage. If you already know WordPress, you are not starting over: your HTML, CSS and PHP experience transfers.
- How do I choose between frontend, backend, mobile, cloud, cybersecurity, data and AI without trying them all for years?Do not try to pick the best field; pick the one whose daily problems you can tolerate on a bad day. Run a short, cheap experiment in two or three candidates, compare what you enjoyed doing rather than what sounded exciting, check the local job market, and commit for six to nine months.
- Should I become an AI engineer or stay a full stack developer?For most full stack developers this is not an either/or. AI engineering is largely full stack engineering plus models, evaluation and data. Keep your full stack strength, add AI features to real work, and move titles only when you have shipped AI work you can point to.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com