Even though it is a great library, the final binary size is making it less attractive to use this library. Using go tool nm -size -sort size binary gives this library as the biggest contributor:

  9f9480     525078 T github.com/yuin/goldmark/util.map.init.0
  a797a0     154901 T github.com/yuin/goldmark/util.map.init.1

I guess this is due to the literal maps in https://github.com/yuin/goldmark/blob/master/util/html5entities.go and https://github.com/yuin/goldmark/blob/master/util/unicode_case_folding.go. I'm struggling with a similar issue in my code base but I'm not sure how to improve this. Apparently, having large literal maps excessively inflates the resulting binary. In this case the ~500kB is due to the map in html5entities.go, it doesn't matter if it's global or not. I guess you put this in a once.Do to decrease the start-up time of the program?

Results from some experiments:

• Using the HTML5Entity as a value instead of pointer-to as the map's value improves the binary size slightly (from 525kB to 505kB). Anyways, why do you use a pointer to that structure? Might be worth checking the performance of using a value directly as I suspect it might be faster (unless you already checked!)
• Putting the map's contents in an array of []struct{key, value} and initializing the map in the init() function reduces the binary size from 525kB to 200kB for that particular map. Quite an improvement! Incidentally, the compiler does something similar but poorly? See https://www.dolthub.com/blog/2023-06-16-static-map-initialization-in-go/
• Exporting the map using the gob encoder results in a file of 52kB! Gzipping it is 10kb. Embedding the gob encoded and gzipped map and then initializing it in the init() function results in only a 2.7kB increase in file size!!! This is surprising since the embedded file is 10kB but go tool nm confirms it is included in its entirety.

// generate gob file
func init() {
	w, err := os.Create("html5entities.gob")
	if err != nil {
		panic(err)
	}
	wgzip := gzip.NewWriter(w)
	if err := gob.NewEncoder(wgzip).Encode(_html5entities); err != nil {
		panic(err)
	} else if err := wgzip.Close(); err != nil {
		panic(err)
	} else if err := w.Close(); err != nil {
		panic(err)
	}
}

// include gob file
var _html5entities map[string]*HTML5Entity

//go:embed html5entities.gob
var __html5entities []byte

func init() {
	if rGzip, err := gzip.NewReader(bytes.NewReader(__html5entities)); err != nil {
		panic(err)
	} else if err := gob.NewDecoder(rGzip).Decode(&_html5entities); err != nil {
		panic(err)
	} else if err := rGzip.Close(); err != nil {
		panic(err)
	}
}

Are you interested in this approach? I could generate a PR for you.

Here's an idea if the map is immutable once created. Rearrange the data into 2 arrays and a string. Then for each HTMLEntity only need to know how long the name, and how many CodePoints and Characters it needs to unpack.

func main() {
	var rows []uint8
	var codePoints []int
	var characters []byte
	var names []byte

	for _, v := range util.Html5entities() {
		rows = append(rows, uint8(len(v.Name)), uint8(len(v.CodePoints)), uint8(len(v.Characters)))
		names = append(names, v.Name...)
		codePoints = append(codePoints, v.CodePoints...)
		characters = append(characters, v.Characters...)
	}
	fmt.Println()
	fmt.Println(`const rows = "" +`)

	printGoString(os.Stdout, rows, 70)
	fmt.Println()
	fmt.Println(`const names = "" +`)
	printGoString(os.Stdout, names, 70)
	fmt.Println()
	fmt.Printf(`var characters = %#v`, characters)
	fmt.Println()
	fmt.Printf("var codePoints = %#v", codePoints)
}

The output above made into an experimental html5entities.go replacement.

html5entities.go

Due to the elimination of 6371 allocations, it constructs the map in a third of the time.

BenchmarkHTML5EntitiesNew-4        	    8162	    138637 ns/op	  248528 B/op	      11 allocs/op
BenchmarkHTML5EntitiesOriginal-4   	    2472	    450227 ns/op	  279600 B/op	    6382 allocs/op