SEO Considerations

[tbreuss]

I know this isn't an alphaTab topic per se, but I'll ask anyway ;-)

Has anyone here ever thought about optimising the sheet music generated by JavaScript for SEO?
And do you have any ideas or suggestions that would also work in a non-JS server environment, such as PHP?

For example, with the idea that generated sheet music could appear as SVG or another graphic format in Google & Co search results?

[Danielku15]

SEO is always a tricky thing to handle in the world of dynamic JavaScript stuff.

In terms of alphaTab the main music sheet is anyhow rather a graphical object and not really "search indexable". Beside the general song/file information there is not much "text" a robot could add to the search index.

Until some extend engines like Google will execute dynamic JavaScript and re-scan the updated DOM, but it has a lower search ranking. Having server-side generated HTML has generally a higher rank on indexing.

I guess the main question is what parts should be indexed and how do search engines support it. This also depends on how the "content" is presented (is it mainly an alphaTab player, some sort of lecture where alphaTab provides some interactive UI etc.) From a gut feeling the most important parts are:

• General Song / File Information should be server-rendered
• Semantic HTML tags and the right meta tags need to be used on the server.

---

Looking more concrete to alphaTab it can help there in these ways:

1. Extracting Meta Data via Low Level APIs

• JavaScript: General Node.js can be used, or some frameworks might provide Server-Side Components (e.g. React SSR). Only the main AlphaTabApi object is browser dependent. Anything else can be used in a headless environment.
• .net: If you build a small .net app you could also use it to extract information in server environments. I haven't tried compiling .net self-contained or AOT apps with alphaTab but theoretically the core should be compatible too.
• Java: There is a plan to provide a standard Kotlin/JVM lib for the core which doesn't depend on Android
• Other platforms: I have some other new platforms on the radar but no specific plans until an alphaTab 2.0 is out. Mainly Python and Go are on my radar. PHP is rather not in my focus.

2. (Pre-)Rendering Files (limited)

• Rendering SVGs doesn't depend on the browser and can be done in server environments. Obviously this is no interactive editor and some manual plumbing for web fonts has to be done. But the SVGs could serve as initial content being sent before the client side component kicks in and re-renders stuff.
• For rendering PNGs you would need to use AlphaSkia to produce PNGs.
• Technically all UI things are implemented via the IUiFacade. Technically any custom UI layer (also headless-server) can be implemented as long as the environment allows some state management.

In all cases, you would likely to some sort of server-side caching in a database and on file system to avoid recomputing things on every page load.

[tbreuss]

Thank you for the very detailed answer.

I will focus on generating PNGs or SVGs in an offline process. So when I'm producing a new alphaTab score I will also do some offline pre processing and generate a PNG or SVG. And upload those images to the server, of course with a naming that can be resolved by the custom made alphaTab widget.

I did already a small PoC but with some browser JavaScript that was generating a PNG from one or more SVGs. Another try was using a Chrome extension, there are a few for this. For both quick tests the only thing that was missing was the Bravura Font, that wasn't used when creating a PNG (or SVG). But I'm quite sure that this can be made to work somehow.

[tbreuss]

have now built a workflow based on Pupetteer that is simple but works really well.

I display all alphaTab scores on an internal page of my website. In my case, this is easy to do because all scores are managed centrally.

Then I use a Puppeteer script to take screenshots of the individual elements in WebP format. The name of the image was defined in the backend and is specified in the "data-uid" HTML attribute.

import puppeteer from "puppeteer";

async function takeScreenshot(url) {
    const browser = await puppeteer.launch();
    const page = await browser.newPage();

    await page.setViewport({
        width: 1800,
        height: 3600,
        deviceScaleFactor: 2, // retina
    });

    await page.goto(url, { waitUntil: "networkidle2" });

    await page.screenshot({
        path: "screenshots/page.webp",
        type: "webp",
    });

    const elements = await page.$$(".at-elements");
    for(const element of elements ) {
	const uid = await page.evaluate(el => el.getAttribute("data-uid"), element);
	await element.scrollIntoView();
	await element.screenshot({
            path: "screenshots/" + uid + ".webp",
            type: "webp",
        });
    }

    await browser.close();
}

takeScreenshot("https://my-page-with-all-alpha-tab-scores");

I then manually upload the screenshots to my web space. This step can, of course, be automated.

For this to work, the backend must of course check whether a WebP image is available for the score. If so, it will be displayed. If not, the alphaTab element will be displayed as normal.

Perhaps this will help someone else in a similar scenario.