Speed is a web development outcome, not a hosting upgrade
When a site feels slow, the first instinct is to blame the server and buy a bigger one. That almost never helps, because the delay a visitor experiences on a phone is mostly created in the browser: images larger than the space they occupy, fonts that block the first paint, scripts that must be downloaded and executed before anything is readable, and layout that jumps as late arriving elements push the content around. Those are web development decisions made during the build, which means speed is something you specify and buy rather than something you fix afterwards.
Melbourne buyers have an additional reason to care. A large share of local traffic arrives on mobile connections while people are moving around, and the gap between a site that appears in a second and one that appears in four is the difference between a lead and a back button. Ask for the current numbers before the project starts so that improvement can be demonstrated rather than asserted.
Set a performance budget before the design is approved
A performance budget is a ceiling agreed in advance: how much a page may weigh, how many separate requests it may make, how long it may take to become readable and interactive on a mid range handset. It is the one line in a web development brief that survives contact with stakeholders, and it is checked at each milestone. Without one, every stakeholder adds something reasonable, each addition is small, and the finished page is enormous with nobody responsible.
The budget also disciplines design. A hero video, a carousel of high resolution photographs, three typefaces in six weights and an animation library all have a cost that is invisible on a designer's screen and obvious on a train. Agreeing the ceiling early means the trade offs are discussed while they are still cheap to make. Any competent web development team will welcome this, because it gives them something to point at when the fourth typeface is requested.
Where the weight actually comes from
In most web development projects the answer is images, fonts and scripts, in that order. Images should be delivered at the size they are displayed, in a modern format, with dimensions declared so the page does not shift while they load, and with anything below the fold deferred. The image that appears first should not be deferred, which is a mistake so common it is worth naming in the brief.
Fonts are the quiet offender. Self hosting them, limiting the weights, and choosing how text behaves while they load are small pieces of work with a visible effect. Scripts are the largest variable, because a component library chosen for convenience can outweigh everything else on the page. Ask each supplier what the front end is built with and why, and ask what a page looks like before any script has run. If the answer is a blank screen, you have learned something important about how the site will behave for a visitor on a poor connection.
Third party tags are added by people who are not developers
Six months after launch, a tag manager will contain a chat widget, two analytics tools, a heat map recorder, a review badge and a remarketing pixel, none of which the development team chose. Each one runs code on every page. This is how a fast site becomes a slow one without anybody changing the site.
Decide now who may add tags, and agree a simple rule: anything added is measured against the same budget, and anything that cannot justify its weight comes back out. Ask the supplier to load non essential tags after the page is usable rather than before, and to leave behind a short note explaining how. This is ordinary work, it takes very little time during the build, and it is nearly impossible to retrofit once the marketing team has become attached to its tools.
Measuring after launch on the devices your visitors hold
Laboratory scores produced on a fast office connection are a web development tool, not evidence. What matters is field data gathered from real visits, which is why the metrics that describe loading, responsiveness and visual stability are worth tracking monthly rather than once. Agree who reports them, in what format, and what happens if they drift.
Build the review into the support arrangement. A quarterly page weight report is a modest ask and it keeps the question alive after the excitement of launch has passed. It also gives you a fair basis for a conversation when the site slows down, because you will be able to see which month it happened in and what was added that month.
Getting comparable answers from Melbourne suppliers
This is a deep market with everything from two person shops to substantial firms with separate front end and back end teams, and the proposals will look very different from one another. Force comparability by asking each candidate the same things: what performance targets they will commit to, how they will prove them, what the front end is built with, how images and fonts are handled, and what the site does before scripts execute.
Ask for a live client site you can test yourself on your own phone rather than a screenshot of a score. Then test it. Ten minutes of that is worth more than any case study, and it is the fastest way to tell which web development companies measure their own work.
If the requirement is really a new visual identity, begin with a design led studio, and if it is an internal application rather than a public site, compare software firms. Verified web development companies are listed on Edvido alongside search specialists who will care about these numbers and application developers for work that belongs in a store, and buyers willing to hire outside the city can review the national pool. When the brief is ready, send it to several firms at once and score the answers against targets you set first.