Website Speed: Images, Fonts and Third-Party Scripts

Most of a page's total weight usually comes from images. Take a product gallery for a flooring manufacturer: a fifty-megabyte page means several seconds of waiting, depending on the visitor's device and connection. That weight does not disappear unless the image is served at the right size and in the right format.

The fix has two steps. First, an image is cropped to the size it will actually appear at; an image that shows at four hundred pixels wide on a phone should not be sent at two thousand pixels. Second, the format is chosen: AVIF and WebP produce far smaller files than older JPEGs at comparable quality (web.dev, Optimise LCP). A framework such as Next.js automates this, so a developer does not have to prepare several versions by hand.

A custom font is part of a brand's identity, but loaded the wrong way it delays the page becoming visible. If the browser hides text until the font file has downloaded, a visitor sees a blank screen for a second or two; this is known as flash of invisible text.

The font-display: swap setting removes that wait: the browser shows the text in a system font immediately, then swaps in the custom font once it arrives (web.dev, Best practices for fonts). A spa chain's booking page might only need two weights, regular and bold, yet the design file often carries five or six across to the live site; every extra weight is a separate download.

Analytics tools, live chat widgets, ad pixels, social media embeds: each one adds an external JavaScript file to the page. These accumulate quietly; a site with five or six different tools added over a year is common.

The problem is that these scripts occupy the browser's main thread; while that code runs, the browser cannot respond to a visitor's click, which directly worsens INP (web.dev, INP). Reviewing the list of tools in use every few months and removing an analytics panel nobody checks any more, or a chat widget nobody uses, is worth the ten minutes it takes.

All three sources do not need fixing at once; the order makes the job easier.

• Measure the current state with PageSpeed Insights or Search Console
• Bring the largest above-the-fold images to the right size and format
• Cut the number of font weights and add font-display: swap
• Remove unused third-party scripts, load the rest only when needed
• Measure again with the same tool after the change

Speed is also a marketing decision, because it is the visitor's first contact with the site. If a generator manufacturer's emergency-callout page loads slowly, the visitor goes back to the search result and tries the next firm; that loss happens quietly, without a complaint or a bounce report anyone reads.

Speed work is not a one-off project; it belongs in ongoing maintenance. The same discipline applies whenever a new tool is added or a new image goes up.

Next.js 16 and React 19, now mainstream in 2026, push server components further: most of a page is prepared on the server and sent to the browser already finished, cutting down how much JavaScript the browser has to download. That is an architectural choice that directly improves INP.

For a manufacturer's catalogue running to hundreds of pages, the difference is concrete: under an older React setup every page gets re-rendered in the browser, under the newer architecture the page arrives ready-made and the browser only takes over the interactive parts, a filter, an add-to-basket button. When weighing a move like this, that architectural difference belongs in the speed budget, not just the visual refresh.

A page generated once and held in cache for a set period, rather than rebuilt from scratch on every visit, reaches later visitors far faster. That is a gain worth taking for any page whose content does not change often, an about page, a service description.

An event calendar on a trade association's site, updated often, needs a short cache duration; a static corporate page can sit on the same cached version for hours or even days. The right duration comes from how often the content actually changes.

Caching set up wrong causes its own problems: an old price staying cached and showing for a while after an update, for instance. That is why when and how the cache clears after an update needs planning from the start.