Barcodes have been generated for decades on low-resource embedded devices. Even what would have been a modest-to-low-end machine 25 years ago would have no problem handling the compute needed for this job.
On this end, it just looks like the user has to deal with the penalty of dealing with 1 MB of resources when hitting the main page.
The version string isn't needed these days, nor the XML header or the doctype.
The code/url/page title can go in the SVG title, to make it show on mouseover.
The id=barcode is also superfluous. Since id codes should be unique, this could be a problem when many QR codes exist on a page.
The background rectangle does not need x=0, y=0 since that is implied.
The 'hard coding' of the black and white is what you want to avoid any dark mode issues, however, I would still use currentColor and transparent rather than black, just to put myself in a world of dark/light mode pain, fixed in CSS.
The SVG is actually generated by Zint itself, only lightly patched in the wrapper. Zint is a pretty old barcode generator (not meant disrespectfully, quite the opposite actually), it's quite possible that some of its decisions when rendering to SVG are out of date or very conservative. The use of id/global namespace does feel like a potential pain point though, which I will take up with the upstream project.
> hopefully that [1MB] will be served from a cache