Website Development: Lessons from Improving twelvebit.io

Start with the task visitors need to complete

A website brief needs a clearer goal than ‘make it look modern’. Identify who is visiting, what they need to understand and the action they should take. For an agency website, those actions include finding the right service, reviewing relevant work and sending a project enquiry.

Our review of twelvebit.io exposed a gap between the services described on the homepage and the pages available to explain them. We added separate pages for web development, blockchain development and smart contract development. Each covers scope, process, technology choices and a portfolio reference. That gives visitors a route from a broad introduction to a specific project discussion.

Check mobile forms with real page measurements

A form can be technically functional while its main action is difficult to reach. On our contact page, the mobile layout put too much space above and around the fields. We reduced that spacing and the initial message-field height while retaining visible labels.

In the first check at a 390 by 844 pixel viewport, the revised Send Message button appeared between 551 and 601 pixels from the top of the page. The page had no horizontal overflow in that check. Follow-up testing on a shorter 320 by 568 pixel viewport showed that the button still fell below the fold, so we added a compact layout for short phone screens. In the final checks, the button appeared between 511 and 561 pixels on the short screen and between 571 and 621 pixels at 390 by 844. Across nineteen public pages at both phone sizes, all thirty-eight measurements had one H1 and no horizontal page overflow. A browser-only test also blocked the send request and confirmed that the error notification appeared, without delivering an enquiry. These checks are not evidence that every device or browser behaves identically. A release review should include keyboard use, validation feedback and additional screen sizes.

Make the important information available in the HTML

Content needed by a visitor or crawler should not depend on a delayed animation. Our homepage counters rendered zero in the server HTML, so we removed them rather than presenting an unverified number. We also changed the block-production page to render its account and ownership information on the server.

Heading structure matters alongside rendering. The homepage had more than one H1 because the portfolio section used the same heading level as the hero. We gave the page one main heading and used subordinate headings for the portfolio. This makes the document structure easier to follow without changing the purpose of the section.

Treat image and font delivery as part of the design

The website’s image directory originally occupied about 49 MB. Resizing and compressing raster assets, converting large portfolio images to WebP and resizing the header logos reduced it to about 9.4 MB in our local worktree. Four active Poppins font weights were converted to WOFF2 and loaded through next/font, replacing the remote Google Fonts CSS import. We then split frequently used characters into smaller preloaded files totalling 29.4 KB, while retaining 44.5 KB of extended fonts for characters outside that set. Accented text, currency and punctuation matched the retained fonts in browser checks at all four weights.

Smaller source assets are useful, but file size alone does not prove a fast page. Responsive image sizes need to match the displayed image, and visual quality must survive compression. Above-the-fold imagery may need an early loading hint; images farther down the page generally should not compete for that initial bandwidth.

Measure the result and state its limits

Our initial local mobile Lighthouse check scored the homepage at 79 with a 5.1-second Largest Contentful Paint. After the image, rendering and font-delivery changes, two checks of the final local production build scored 98 and 100, with Largest Contentful Paint of 2.40 and 1.87 seconds. These were Lighthouse 13.5.0 lab runs using its default simulated mobile throttling, not measurements of visitors using the deployed site.

Keeping both runs matters: performance changes with loading conditions, and one favourable result should not become a promise about every visit. We retained the earlier results alongside the final measurements. A release still needs checks against the deployed pages and, when available, field data. Local lab measurements do not establish search rankings, indexing or real-user interaction performance.

Verify metadata and links before calling the work complete

Our article canonicals contained a double slash and pointed to redirecting URLs. We normalised the public origin, removed unsupported language alternates and checked the resulting HTML. Unknown article slugs now return 404 rather than failing during rendering.

The expanded local checks covered nineteen public pages and ten private or utility routes. Each public page had a unique title, the expected canonical, one H1 and parseable structured data. The private-route checks covered noindex metadata and unauthenticated dashboard redirects. Those checks establish the behaviour of the local build. They do not prove that Google has indexed the pages or that the deployed mobile performance target has been reached.

What to include in a web-development brief

Share the site’s audience, the main visitor action, content that is already available, existing code or designs, required integrations and your target timeline. Identify who will maintain the site after delivery. Agree a verification plan for the pages, forms and journeys that matter before a release.

Use our web-development service page to explore the scope of an engagement, or contact twelvebit to discuss a new site or an existing application. We work through the specific requirements rather than assuming that every project needs the same stack or feature list.