How was this measured

A cold load of the résumé builder in a headless browser, with every response body weighed rather than its header believed. 51 requests, about 3 MB of uncompressed bytes, and 803 ms to network idle against a local server.

Because the development server we measured sends no compression. The largest file, the application itself, is 1 048 KiB raw and 299 KiB gzipped, so a server that compresses moves far less.

What costs bandwidth after the first load

Importing a file, the ATS check, a letter draft and the PDF export. Typing, editing, reordering and changing design do not.

Will it work on a slow connection

The first load will be slow in proportion to the connection. Once it is loaded, the editor is code running in your browser and responds at the speed of the device.

Does it use less on a phone

The same application is loaded. The layout changes with the width; the payload does not change with the device.

Blog · Devices

What this product costs to load, and what it costs after that

One expensive moment and then very little. We weighed every response on a cold load and wrote down where the weight is.

ConxfolioPublished 2026-09-13

— measure the first load, then stop worrying about the rest.

The Conxfolio résumé builder after a cold load, with the two starting doors on screen — The page the measurement describes: one cold load of the résumé builder, everything weighed.

Advice about slow connections is usually written by people who have never been on one. This page is a weighing instead. Every response on a cold load of the résumé builder was measured, by reading the body rather than trusting the header, and here is where the bytes are.

The cold load, weighed

What	Measured
Requests	51
Total, uncompressed	about 3 016 KiB
Stylesheets	1 685 KiB
Scripts	1 171 KiB
Fonts	137 KiB
The HTML itself	23 KiB
Time to network idle, local server	803 ms

That is a real number rather than a flattering one. Most of it is two files: the application script at 1 048 KiB and the main stylesheet at 377 KiB.

Uncompressed is the word doing the work

The server we measured sends no compression at all, so those are raw bytes on the wire. Compressed, the application script is 299 KiB rather than 1 048. A production server that serves gzip or brotli moves a fraction of the figure above, and the honest way to report this is the number we actually saw with the caveat attached rather than the flattering one on its own.

The important part: what comes after

The résumé builder after a cold load — Once this is on screen, the writing is local. The network is needed again for four things only.

Typing, editing, reordering sections, switching design and rendering the preview all happen inside the page. Four actions go back to the network: importing a file, the ATS check, a letter draft and the PDF export. That list was confirmed by cutting the connection during a real edit, which is written up in applying offline.

How to work on a bad connection

Load the page when you have signal and leave the tab open. Do the writing, which is the long part, without touching the network. Then run the check and the export together while you have a bar. If the connection drops in the middle of the writing, nothing you have typed is lost, because your work is written into the browser rather than posted to a server.

The exports have different costs

The DOCX is assembled in the browser and takes no server call at all. The PDF takes exactly one, a render request, and the file comes back. On a connection you do not trust, the DOCX is the export with fewer ways to fail. The rest of that trade-off is in PDF or DOCX, which to send.

On mobile data

The same résumé builder at 390 pixels wide — The same application at 390. The layout changes with the width; the payload does not change with the device.

A phone on mobile data pays the same first load as a laptop, which is worth knowing if you are counting megabytes. Everything measured about the phone layout itself is in writing a résumé on a phone, and the tablet equivalent in applying from a tablet.

Reading the figure honestly

Three megabytes uncompressed across 51 requests is a real number and it is not a flattering one. Two files carry most of it, and both are the application rather than your content: the script at 1 048 KiB and the main stylesheet at 377 KiB. The 803 milliseconds measured alongside them says nothing about your connection, because the server was on the same machine as the browser; it is a measure of the work the browser does once the bytes have arrived. On a slow link the arrival is the part you will feel, and it happens once per visit rather than once per action, which is the only reassurance this page can honestly offer.

What this page does not claim

That this is a light page. Three megabytes uncompressed is not light, and the honest description is one heavy load followed by a product that costs nothing to use. It also does not claim a speed: 803 milliseconds was measured against a server on the same machine, which tells you the work the browser does and nothing at all about your connection.

One last practical note for anyone rationing data. The design galleries render live previews of the 37 résumé designs, so browsing all of them costs more than choosing from the shortlist the builder offers on the way through. Picking a design inside the flow and changing it later is the cheaper order, and choosing between two designs covers how to decide without opening all of them.

For anybody genuinely counting megabytes, one habit saves most of the cost across a week. Keep the tab open rather than closing and reopening it, because the expensive load happens per visit and the work in between is local. If the tab has to be closed, a browser that has cached the assets will fetch far less on the second visit, which is ordinary browser behaviour rather than anything this product does. What it will not do is work with no connection at all, and that limit is measured separately in applying offline.

Load it once and keep the tab

The writing happens in the page. After the first load, only the check, the draft and the PDF need the network again.

Open the résumé builder What survives a lost connection

Questions

How was this measured: A cold load of the résumé builder in a headless browser, with every response body weighed rather than its header believed. 51 requests, about 3 MB of uncompressed bytes, and 803 ms to network idle against a local server.
Why say uncompressed: Because the development server we measured sends no compression. The largest file, the application itself, is 1 048 KiB raw and 299 KiB gzipped, so a server that compresses moves far less.
What costs bandwidth after the first load: Importing a file, the ATS check, a letter draft and the PDF export. Typing, editing, reordering and changing design do not.
Will it work on a slow connection: The first load will be slow in proportion to the connection. Once it is loaded, the editor is code running in your browser and responds at the speed of the device.
Does it use less on a phone: The same application is loaded. The layout changes with the width; the payload does not change with the device.

Conxfolio is a free set of four career tools: a résumé builder with 37 rendered layouts, an ATS résumé checker that prints its own arithmetic, a cover letter builder that traces every proof paragraph back to the line it came from, and a portfolio builder with 20 authored designs. There is no account to create, nothing is held back for a paid plan, and no language model is used anywhere in the product, so the readers, the score and the letter are deterministic code you can check.