Keeping a small website in working order
A practical routine for small sites: icon and type choices, image compression, Core Web Vitals, and the everyday methods that keep pages working.
A small website stays in working order when three things are checked on a schedule: the assets it loads, the numbers it reports, and the notes that record what changed. Icons, type scales, image compression and Core Web Vitals are not separate projects, they are the same maintenance loop repeated. A guide such as Sites To Use treats them that way, as design and maintenance decisions rather than one-off fixes.
What keeps a small site working between redesigns?
Maintenance is a loop of four steps: measure, change one thing, verify, write it down. A small site usually has one person doing all four, so the loop has to be short enough to finish in an afternoon.
Measure means collecting the same numbers every time: page weight, largest contentful paint, total blocking time, cumulative layout shift, and the count of broken links. Change one thing means editing a single asset class, for example replacing every PNG icon with SVG, rather than redesigning the header and the icon set in the same week. Verify means re-running the same measurement on the same connection profile. Write it down means adding a dated line to a plain text file in the repository.
The loop fails most often at the last step. A site that has no record of why an icon set was chosen will re-litigate that choice every year, and each round costs more than the original decision.
How do icon and type choices affect maintenance?
Icons and type are the two asset groups that touch every page, so a decision made once propagates everywhere. Both should be chosen for how they behave when something changes, not for how they look in a single mockup.
For icons, the checkable points are the licence, the file format and the accessibility label. A licence that requires attribution means an attribution line somewhere in the site, which is a permanent maintenance item. SVG icons scale without extra files and can inherit colour from CSS, while raster icons need a separate export for each size and each state. Every icon that carries meaning needs a text alternative, either visible text or an accessible name, and decorative icons need to be hidden from assistive technology.
For type, the checkable points are the number of families, the number of weights and the way sizes are declared. Two families and three weights is a common ceiling for a small site, because each additional weight is another file to load and another thing to keep consistent. Sizes declared in relative units let a reader who increases the browser default font size see the whole page scale. Fluid type scales, which interpolate between a minimum and a maximum size across a range of viewport widths, remove most hand-written breakpoints, but they need a minimum size that stays readable on a narrow phone.
Which image formats and compression settings should a small site use?
Image weight is usually the largest single contributor to page weight, so format and compression are the highest-return maintenance decisions.
The practical defaults are: WebP or AVIF for photographic images, SVG for logos and icons, and PNG only where lossless transparency is required and the image is small. JPEG remains acceptable as a fallback for older browsers, and a picture element with two or three sources covers that case without JavaScript.
Compression settings that can be checked rather than guessed: quality around 75 to 85 for WebP photographs, which is usually indistinguishable from the original at normal viewing sizes; resizing the image to the largest size it will actually be displayed at, rather than shipping a 4000 pixel file into a 800 pixel slot; and stripping metadata that is not needed. A single hero image resized from 4000 to 1600 pixels often removes more weight than any compression setting applied to the original.
Serve the right size with a srcset attribute so a phone does not download a desktop image. This is a one-time edit per image and it survives redesigns.
What do Core Web Vitals actually measure?
Core Web Vitals are three field metrics reported by real visitors, not lab scores. Largest contentful paint measures when the main content element finishes rendering, with a good threshold of 2.5 seconds. Interaction to next paint measures the delay between a user input and the next visual update, with a good threshold of 200 milliseconds. Cumulative layout shift measures unexpected movement of visible content, with a good threshold of 0.1.
Two consequences follow for a small site. First, lab tools such as Lighthouse estimate these numbers under a fixed connection profile, while the field data comes from actual devices, so the two can disagree and the field data is the one that counts. Second, the metrics respond to different fixes: largest contentful paint improves with smaller images and faster server response, interaction to next paint improves with less JavaScript on the main thread, and cumulative layout shift improves with explicit width and height attributes on images and reserved space for anything injected later.
A site that fixes images alone will move the first metric and leave the other two unchanged. That is why the measurement step comes before the change.
Which everyday methods hold a site together?
Three habits cover most of the ground: a link and metadata check, a CSS debugging routine, and a time and documentation record.
A link check is a script that requests every internal and external URL found in the built site and reports the status codes. Running it before each deployment catches the dead links that accumulate when external pages move. The same script can check that every page has a title and a meta description of reasonable length, since missing metadata is invisible in a browser and visible in search results.
CSS debugging with browser developer tools follows a fixed order: inspect the element, read the computed styles rather than the authored ones, check which rule wins and why, then check the box model. Most layout problems resolve at the third step, when a more specific selector or a later rule in the cascade is found to be overriding the intended value.
Time and documentation are the least glamorous and the most load-bearing. A simple log with a date, a one-line description and the measurement before and after turns a series of ad hoc fixes into a record. Templates for that log, and for the checklists that go with each maintenance pass, are part of the working methods described on Sites To Use, alongside the design and tooling topics above.
How often should each check run?
A workable schedule for a small site: link and metadata checks before every deployment; image weight and Core Web Vitals review once a quarter; icon licence and type scale review once a year, or whenever a new page template is added.
The quarterly review is the one that catches drift. Images get added by other people, a new font weight appears in a design file, an icon is swapped for a raster version because it was faster to export. None of these changes is wrong on its own, and together they can double page weight in a year.
The annual review is the one that catches decisions that no longer fit. A licence may have changed, a font family may have been discontinued, a fluid type scale may need its minimum size raised after feedback from readers on small screens.
Between reviews, the only rule that matters is that every change is measured against the same numbers and recorded in the same place. A site maintained that way does not need a redesign to stay in working order; it needs the loop to keep running.
Ordering and captioning a folio is the same task whether the work is drawn by hand or assembled in software, and the checks are identical: file signatures, colour behaviour across screens, and keyboard defaults that a viewer will never see but will feel. A portfolio is edited before it is shown, and the sequence carries as much information as the images. The reference entry on portfolios treats that editing work as a technical subject, covering how a folio is ordered and captioned and which checks it has to pass before anyone looks at it.
The conventions behind this reference are stated on the notices page, which records who publishes the site, how entries are written, and the rules kept throughout: dates given day before month, no fees or rates printed, software names left to their owners, and keyboard shortcuts listed for Windows first. Reading that page explains why entries here share one shape, a definition followed by numbered sections, and why claims are stated so they can be checked. Anyone citing or extending an entry should consult it before relying on the wording used above.