Why your website loads slowly
A slow site loses visitors quietly. Nobody writes to say "your site takes ages", they simply close the tab and move to the next result in the listing. There are many reasons for slow loading, but they are unevenly distributed, and it is almost always the same two or three things.
Images: the main reason for slow loading
The first and most common reason is images. A photo from a phone weighs several megabytes and is four thousand pixels wide. On the site it is shown in a block six hundred pixels wide, and the browser still downloads all of it. Eight such photos on a page mean someone on mobile internet waits half a minute.
The fix is not compressing the file before upload but re-encoding it on the site's side. The image is brought to the size actually needed, converted to a modern format such as webp and served to match the screen the visitor arrived on. On the article covers in this blog that conversion cut the weight of the feed roughly eightfold, with no visible difference.
Fonts and third-party scripts
The second reason is fonts. Every non-standard font is a separate file, and until it has downloaded the text is either invisible or jumps when it is substituted in. Three weights instead of one mean three files. The fix is limiting the set and subsetting the font to the alphabet you need, since Cyrillic has no use for Chinese characters, and the original file contains them.
The third reason is third-party scripts: analytics counters, support chats, social network widgets and advertising pixels. Each pulls its own code from someone else's server, and the page waits for all of them. It is particularly galling when a chat widget used by three people a month delays loading for every visitor. Such things are loaded lazily, after the page has been shown, rather than in the first lines.
The server and where the site is hosted
The fourth reason lies in the server itself. If the page is assembled anew on every visit, the assembly time adds to the transfer time. A heavy management system on a cheap plan easily spends a second and a half just getting round to answering. Caching finished pages, a more decent plan, or moving to static, where there is nothing to assemble, all help.
Sometimes the cause turns out to be not the site but how it is hosted. On one of our projects a commercial Laravel engine took fifteen seconds to open, and the code had nothing to do with it. The application, the database and the cache lived in one cramped environment and got in each other's way. After the move into an isolated container stack, loading came down to five seconds, without a single line changed in the application itself.
How to measure speed and where to start
All of this has to be measured with tools, not with impressions. PageSpeed Insights and the Network tab in the browser show exactly what loaded and how long it took. Look at the mobile version on a slow connection, because on office internet and a powerful laptop things are almost never bad. Pay attention not to the overall score but to the individual rows: which file turned out to be the heaviest and what delayed the text appearing.
The order that produces results fastest looks like this: images first, then third-party scripts, then fonts, and only after that everything else. In most cases the first two points cover the bulk of the problem, and fine-grained code optimisation never even comes up.
What you should definitely not do is chase the maximum PageSpeed score. The last few percent come expensive, and the visitor does not notice the difference between "fast" and "very fast". They notice the difference between "I can see it" and "it is still spinning", and that is won on the very first steps.