A lighter website starts with fewer moving parts.
Before adding another optimization tool, take a closer look at what your pages actually need to load.
Begin with the reader's task
A personal website or publication usually needs to deliver a small set of things well: readable text, useful navigation, and relevant images. Make a list of what the reader needs to do on a page. Anything outside that list should earn its place. An animated introduction may look appealing, but consider whether it helps someone get to the article.
Look at the largest assets first
Open the network panel in your browser's developer tools and reload a representative page. Sort requests by transferred size. If an image is much larger than its displayed dimensions require, resize and compress it before uploading. Set its width and height so the browser can reserve space while it loads.
Treat scripts as a budget
Each additional script can add downloading, parsing, and execution work. Start with built-in browser features and add JavaScript for interactions that need it. For example, ordinary navigation links do not need a client-side application framework. Search and menu controls can often be implemented with a small amount of code.
Use typography deliberately
A system font stack avoids a separate font download. If a custom font is important to the design, choose only the styles and character sets you use. Check the layout while the font is unavailable as well as after it loads; a readable fallback is part of the design.
Measure a real reading journey
Check the homepage, an article, and a category page on a narrow screen and a slower connection. Test links, text size, and layout movement. Static HTML gives you a straightforward starting point, but images, third-party embeds, hosting, and caching still affect the result. Compare measurements after each meaningful change instead of assuming that a particular platform guarantees speed.
Make a before-and-after asset note
For a single representative page, record the image filenames, transferred sizes, and displayed dimensions. Suppose a hypothetical homepage downloads four images at 2 MB each: that is 8 MB of images before the rest of the page. Reducing each to 200 KB would bring that part of the transfer to roughly 800 KB. These are arithmetic examples, not measurements from a product test. Measure the actual files on your own site and check whether the compressed versions still look acceptable.
Reserve space for the photograph
An image can have HTML width and height attributes while CSS controls its displayed size. This lets the browser understand its proportions before it finishes loading. Use dimensions that match the actual asset. If a thumbnail is deliberately cropped, test that crop separately from the full article image. A crop that works for a landscape may cut off the important part of a person or diagram.
Load the right image at the right time
Google’s web.dev image guidance covers sizing, formats, and loading behavior. As a starting point, avoid lazy-loading the important image readers see immediately, while considering lazy loading for images much further down the page. Verify the result on the real layout. Applying the same loading attribute everywhere can trade one problem for another. The aim is to prioritize the content needed now and reduce work that is not needed yet.
A small image-loading example
This illustrative markup assumes the file itself is 1200 × 800 pixels. Match the dimensions and description to your actual asset; use lazy loading for a below-the-fold image.
<img src="/images/garden.jpg"
alt="A shaded path through a community garden"
width="1200" height="800"
loading="lazy" decoding="async">
<style>
img { display: block; max-width: 100%; height: auto; }
</style>