some long names.<\/li>\n<\/ul>\n\n\n\nThis reduces the size of the file.<\/p>\n\n\n\n
It is a good production practice, but these days the difference between a minified and a non-minified file, sent additionally with Brotli or GZIP compression, is often much smaller than it was a few years ago.<\/p>\n\n\n\n
A far bigger improvement can come from not sending unnecessary code at all<\/strong>.<\/p>\n\n\n\n<\/span>9. Keep an eye on the number of requests and the total transfer<\/span><\/h2>\n\n\n\nEvery additional resource means more work for the browser.<\/p>\n\n\n\n
This does not mean you absolutely have to merge all files into one. With HTTP\/2 and HTTP\/3 that strategy often no longer makes sense.<\/p>\n\n\n\n
It is still worth limiting resources that add nothing, though.<\/p>\n\n\n\n
Especially:<\/p>\n\n\n\n
\n- JavaScript libraries,<\/li>\n\n\n\n
- fonts,<\/li>\n\n\n\n
- trackers,<\/li>\n\n\n\n
- social media widgets,<\/li>\n\n\n\n
- iframes,<\/li>\n\n\n\n
- videos,<\/li>\n\n\n\n
- large images,<\/li>\n\n\n\n
- duplicated libraries.<\/li>\n<\/ul>\n\n\n\n
Optimization should be about reducing the amount of work performed<\/strong>, not merely the number shown in a report.<\/p>\n\n\n\n<\/span>10. Images are one of the biggest sources of savings<\/span><\/h2>\n\n\n\nA photo displayed on the page at 800 \u00d7 500 px should not be downloaded as a 5000 \u00d7 3000 px file.<\/p>\n\n\n\n
This is one of the easiest mistakes to detect.<\/p>\n\n\n\n
WordPress can generate different image sizes automatically, and the browser can pick the right version thanks to srcset<\/code> and sizes<\/code>.<\/p>\n\n\n\nIt is also worth using modern formats:<\/p>\n\n\n\n
\n- WebP,<\/li>\n\n\n\n
- AVIF.<\/li>\n<\/ul>\n\n\n\n
In many cases they let you significantly reduce transfer while keeping good image quality.<\/p>\n\n\n\n
You should not, however, mechanically convert everything to a single format. The result of the compression has to be judged on real material.<\/p>\n\n\n\n
<\/span>11. Do not use lazy loading for everything<\/span><\/h2>\n\n\n\nLazy loading is very useful for images located far below the first screen.<\/p>\n\n\n\n
An example:<\/p>\n\n\n\n
<img\n src=\"photo.webp\"\n loading=\"lazy\"\n width=\"800\"\n height=\"600\"\n alt=\"Photo description\"\n>\n<\/code><\/pre>\n\n\n\nToday’s browsers support native loading=\"lazy\"<\/code>, so in many cases an additional JavaScript library is no longer needed.<\/p>\n\n\n\nThere is one important exception, though.<\/p>\n\n\n\n
Do not lazy-load the main image above the fold<\/strong>, especially if it is the LCP element.<\/p>\n\n\n\nSuch an image should start loading as early as possible. Google explicitly recommends that images in the initial viewport, especially the LCP one, should not be lazy loaded.<\/p>\n\n\n\n
<\/span>12. Take care of the image responsible for LCP<\/span><\/h2>\n\n\n\nIf the largest element on the page is the main product photo or a hero banner, downloading it should start as early as possible.<\/p>\n\n\n\n
The problem appears when the image:<\/p>\n\n\n\n
\n- is set only as a
background-image<\/code> in CSS,<\/li>\n\n\n\n- is added only by JavaScript,<\/li>\n\n\n\n
- has lazy loading applied incorrectly,<\/li>\n\n\n\n
- is discovered by the browser too late.<\/li>\n<\/ul>\n\n\n\n
In specific situations you can use, among other things:<\/p>\n\n\n\n
fetchpriority=\"high\"\n<\/code><\/pre>\n\n\n\nor preloading the resource.<\/p>\n\n\n\n
You should not, however, preload a dozen or so graphics at once. If everything gets a high priority, priorities practically stop serving their purpose.<\/p>\n\n\n\n
<\/span>13. Set the dimensions of images and other elements<\/span><\/h2>\n\n\n\nElements should have dimensions the browser knows about.<\/p>\n\n\n\n
For images these can be:<\/p>\n\n\n\n
width=\"800\"\nheight=\"600\"\n<\/code><\/pre>\n\n\n\nThanks to this the browser can reserve the right amount of space before the file itself is downloaded.<\/p>\n\n\n\n
This reduces the risk of layout shifts, that is, of a worse CLS.<\/p>\n\n\n\n
A similar problem occurs with:<\/p>\n\n\n\n
\n- ads,<\/li>\n\n\n\n
- iframes,<\/li>\n\n\n\n
- embeds,<\/li>\n\n\n\n
- dynamic banners,<\/li>\n\n\n\n
- elements loaded by JavaScript.<\/li>\n<\/ul>\n\n\n\n
<\/span>14. Optimize fonts<\/span><\/h2>\n\n\n\nA web font is also a resource that has to be downloaded.<\/p>\n\n\n\n
A page that uses:<\/p>\n\n\n\n
\n- 4 font families,<\/li>\n\n\n\n
- 5 weights of each,<\/li>\n\n\n\n
- italics,<\/li>\n\n\n\n
- additional character sets,<\/li>\n<\/ul>\n\n\n\n
can download far more data than is needed.<\/p>\n\n\n\n
It is worth limiting the number of variants and using WOFF2.<\/p>\n\n\n\n
Another good practice is:<\/p>\n\n\n\n
font-display: swap;\n<\/code><\/pre>\n\n\n\nThanks to this the user can see the text in a fallback font before the target font is downloaded.<\/p>\n\n\n\n
For the most critical fonts a preload is sometimes justified.<\/p>\n\n\n\n
<\/span>15. Limit third-party scripts<\/span><\/h2>\n\n\n\nA page can be well optimized and still run slowly because of code coming from other services.<\/p>\n\n\n\n
Typical examples:<\/p>\n\n\n\n
\n- ad systems,<\/li>\n\n\n\n
- analytics,<\/li>\n\n\n\n
- chats,<\/li>\n\n\n\n
- heatmaps,<\/li>\n\n\n\n
- review widgets,<\/li>\n\n\n\n
- social media,<\/li>\n\n\n\n
- A\/B testing systems,<\/li>\n\n\n\n
- YouTube videos,<\/li>\n\n\n\n
- maps.<\/li>\n<\/ul>\n\n\n\n
Each such element can download its own JavaScript, set up event listeners and run code on the main thread.<\/p>\n\n\n\n
On Polish company websites and online stores the problem often builds up gradually: first analytics is added, then Meta Pixel, Google Ads, a chat, a marketing automation tool and further widgets. Each of them looks small on its own, but together they can become one of the main sources of performance problems.<\/p>\n\n\n\n
The solution can be:<\/p>\n\n\n\n
\n- removing services that are not needed,<\/li>\n\n\n\n
- delaying their start,<\/li>\n\n\n\n
- loading them only after an interaction,<\/li>\n\n\n\n
- using lightweight placeholders instead of heavy iframes.<\/li>\n<\/ul>\n\n\n\n
<\/span>16. Enable HTTP compression<\/span><\/h2>\n\n\n\nHTML, CSS, JavaScript, JSON, XML and other text formats compress very well.<\/p>\n\n\n\n
The server should therefore send them using, for example:<\/p>\n\n\n\n
\n- Brotli,<\/li>\n\n\n\n
- GZIP.<\/li>\n<\/ul>\n\n\n\n
This reduces the amount of data sent between the server and the browser.<\/p>\n\n\n\n
You should not, on the other hand, compress again formats that already have their own effective compression, for example most images or videos.<\/p>\n\n\n\n
<\/span>17. Set an appropriate browser cache<\/span><\/h2>\n\n\n\nStatic files that change rarely should not be downloaded again on every visit.<\/p>\n\n\n\n
This applies, among others, to:<\/p>\n\n\n\n
\n- CSS,<\/li>\n\n\n\n
- JavaScript,<\/li>\n\n\n\n
- images,<\/li>\n\n\n\n
- fonts.<\/li>\n<\/ul>\n\n\n\n
The right headers:<\/p>\n\n\n\n
Cache-Control\nExpires\nETag\n<\/code><\/pre>\n\n\n\nlet the browser reuse previously downloaded resources.<\/p>\n\n\n\n
For versioned files, for example:<\/p>\n\n\n\n
app.a87c913.js\n<\/code><\/pre>\n\n\n\nyou can use a very long cache lifetime, because a change of content produces a new file name.<\/p>\n\n\n\n
<\/span>18. Avoid unnecessary redirects<\/span><\/h2>\n\n\n\nEvery redirect means an additional request.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
http://example.com\n\u2193\nhttps:\/\/example.com\n\u2193\nhttps:\/\/www.example.com\n\u2193\nhttps:\/\/www.example.com\/pl\/\n<\/code><\/pre>\n\n\n\nmeans several operations before the user reaches the actual document.<\/p>\n\n\n\n
For a single user visit this need not be a disaster, but similar chains inside the site, in CSS, JavaScript or ads can generate unnecessary delays.<\/p>\n\n\n\n
Link directly to the target addresses.<\/p>\n\n\n\n
<\/span>19. Control the size of the DOM<\/span><\/h2>\n\n\n\nPage builders make it possible to create complicated layouts quickly, but they often generate very bloated HTML.<\/p>\n\n\n\n
A visually simple element can look like this in the code:<\/p>\n\n\n\n
<div>\n <div>\n <div>\n <div>\n <div>\n <span>Text<\/span>\n <\/div>\n <\/div>\n <\/div>\n <\/div>\n<\/div>\n<\/code><\/pre>\n\n\n\n