A website can look premium and still feel slow. Large images, heavy JavaScript, shifting layouts, third-party widgets and blocking effects make simple tasks harder than they should be. Performance work begins by identifying what the visitor experiences, then removing the biggest causes of delay and instability.
This is a practical guide, not a claim that one framework guarantees speed. Measure important templates, test real devices, and prioritise changes based on evidence.
Key takeaways
- Measure key templates before changing code.
- Resize and compress images and use responsive assets.
- Reserve space for media and third-party widgets.
Core Web Vitals: current good-experience thresholds
| Metric | What it measures | Good threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | How quickly the main useful content appears. | 2.5 seconds or less |
| Interaction to Next Paint (INP) | How quickly a page responds across user interactions. | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | Unexpected visual movement during loading and interaction. | 0.1 or less |
Evaluate these metrics at the 75th percentile of real page loads, segmented by mobile and desktop where possible. The lab result for a single test is helpful for diagnosis but is not the same as field performance.
Measure the actual page journey
Start with the pages that matter: home, service, project detail, article and contact. Review loading, visual stability, main-thread work and whether the primary action becomes available quickly. A homepage score is not enough if an article template or image gallery behaves differently. Use lab tools to investigate bottlenecks and real-user data where available to see variation. A score is a diagnostic signal, not the business result. Record the baseline and compare after meaningful changes rather than chasing a perfect number without context.
Size images for their display
A photo uploaded straight from a phone may be several megabytes while appearing inside a small card. Resize sources to appropriate dimensions, compress them and use suitable formats. Generate responsive sizes so mobile users do not download desktop assets unnecessarily. Do not blindly lazy-load the first prominent image, because delaying it can worsen perceived loading. Conversely, eagerly loading every below-the-fold image wastes bandwidth. Choose a loading strategy based on placement, priority and the way visitors use the page.
Keep the visible screen stable
Layout shifts happen when an image, font, ad or widget arrives without reserved space. Set dimensions or aspect ratios for media and avoid inserting large blocks above content after initial rendering. A visitor should not lose their place because a late-loading element pushes the page down. Reserve room for chat widgets and dynamic content when possible. Test third-party UI on narrow screens and make sure it does not cover a primary action. Stability is part of usability, not merely a dashboard metric.
Use JavaScript intentionally
Every additional package creates work for the browser and the maintainer. Use a library when it materially improves the experience, and avoid several tools that solve the same problem. A simple hover state or accordion may not need a full animation framework. Keep client-side work contained and avoid hydrating large portions of editorial pages without need. Static article text should remain easy to read and render. Use client components for real interactions such as filters and form state, not as a default for every component.
Animate without blocking the task
Motion can add rhythm, but visitors should not wait for every section to animate before reading or navigating. Trigger effects as elements enter view, keep durations reasonable and avoid expensive blur or filter operations on weaker devices. Respect reduced-motion preferences and provide a complete experience without parallax or cursor tracking. Test touch devices where hover is absent. If motion becomes a core interaction rather than decoration, make the control and expected result obvious. Visual polish should never hide content or slow down a customer task.
Load third-party scripts later
Analytics, chat, video embeds and social widgets can add network requests and main-thread work. Audit which scripts are essential everywhere and which can load only on relevant pages or after the main content is ready. Third-party performance can change without notice, so retest after provider updates and have a plan if a widget becomes unavailable. Preserve direct contact options instead of making the whole site depend on a chatbot or embedded service. The best integration is the one that gives enough value to justify its cost.
Make forms fast and forgiving
Contact forms need clear labels, sensible required fields, helpful validation and visible submission status. Do not clear user input before the server confirms success. If a provider fails, explain what happened and show a fallback such as email. Keep validation focused and do not send private data to a service you have not reviewed. A lean form with four useful fields can outperform a complex multi-step component when the user simply wants to ask a question. Test with mobile keyboards and slower connections.
Audit fonts and responsive layout
Fonts affect identity and page geometry. Limit unnecessary families and weights, define reasonable fallbacks, and ensure text remains readable if a preferred font loads late or fails. Use fluid sizing and test long titles, long project names, translated text and error states rather than only ideal mock content. Responsive design must survive real content variation. Avoid hard-coded heights that cut off paragraphs, and make sure focus outlines and buttons remain visible on different backgrounds.
Keep semantic HTML and accessibility in the plan
Use a real button for an action, an anchor for navigation, headings in logical order and labelled form controls. Do not rely on click handlers on decorative divs for core navigation. Accessibility checks often reveal practical UX problems too: controls that are hard to tap, content that appears only after animation, or forms that do not announce errors. Treat accessibility as a continuing quality check rather than a final polish item. A semantically sound page is easier to navigate and more robust.
Make performance a repeatable habit
Performance can regress when project cards, article images, analytics tools or animations are added. Keep a lightweight checklist for image weight, client-side bundle, layout stability, reduced-motion behaviour and contact testing. Revisit key templates after substantial changes. Prioritise fixes with visible impact instead of tuning details nobody experiences. The target is a fast, stable and understandable page for the actual audience. Measure before and after, then verify that the change improved the experience rather than assuming that the optimisation worked.
Prioritise fixes by impact and effort
A useful performance backlog compares the size of the problem, the number of visitors affected and the cost of a fix. If the largest image dominates the first screen, compressing and serving a responsive version may deliver more value than rewriting a small component. If a chat widget blocks interaction, defer it or make it optional before tuning a minor CSS selector. Write down the expected effect, ship one meaningful change and remeasure the same journey. This avoids busywork and creates a repeatable way to decide which improvements are worth the engineering time.
Create a repeatable performance budget
A performance budget gives the team a practical limit to review when new assets or dependencies are introduced. It can define image-size expectations, font count, initial JavaScript, third-party scripts and the number of critical requests, rather than relying on a vague requirement that the site should feel fast. Measure representative pages: a homepage, an article, a project detail and an interactive form may have very different bottlenecks. Record the test conditions, device profile, network settings and deployment version so comparisons are meaningful. When performance worsens, inspect what changed before adding a broad optimization plugin. Check whether the largest image is sized appropriately, whether a font blocks rendering, whether client-side code is needed for the initial view and whether a third-party widget delays interaction. Reserve width and height for images and dynamic content to reduce layout shift. Defer nonessential work only when doing so does not make the page confusing or remove access to a key action. Retest after deployment because local development and production delivery can behave differently. Lab measurements help isolate causes, while field data describes actual visitors over time; neither alone tells the full story. A budget is not a promise of one universal score. It is a way to catch regressions early and ensure each new visual effect earns the cost it adds to loading and interaction.
Practical checklist
- Measure key templates before changing code.
- Resize and compress images and use responsive assets.
- Reserve space for media and third-party widgets.
- Audit client-side libraries and defer non-critical scripts.
- Respect reduced-motion settings and test real mobile devices.
Frequently asked questions
Does using Next.js guarantee a fast website?
No. The framework offers useful rendering options, but performance still depends on code, images, fonts, third-party scripts and implementation decisions. Measure important templates on mobile and compare the same user journeys after each change to judge real impact.
Should every image use lazy loading?
No. Lazy loading helps below-the-fold images, while a prominent first-screen image may need higher priority. Choose based on placement and test the result. Reserve space for images and dynamic content so late loading does not move controls beneath the visitor’s pointer.
Can GSAP make a website slow?
Any animation work can affect performance if excessive or poorly implemented. Use motion purposefully, animate efficient properties, and keep reduced-motion behaviour. Measure important templates on mobile and compare the same user journeys after each change to judge real impact.
What should I optimise first?
Start with the biggest observed bottleneck on an important page, often oversized images, unnecessary scripts, layout shifts or expensive client-side work. Reserve space for images and dynamic content so late loading does not move controls beneath the visitor’s pointer.
Sources & references
Documentation and references used to check the technical and practical guidance in this article.
A performant website results from many small decisions: image sizes, rendering boundaries, script loading, layout stability, form feedback and motion restraint. Measure real page journeys, fix meaningful bottlenecks and repeat the process as the site grows.
Have a related project or need a second opinion? Share the context and start a conversation .
