Im Homeoffice stehe ich (nicht allzu früh) auf, starte meinen PC, checke meine Tasks und Mails und plane basierend darauf meinen Tag. Um 10 Uhr haben wir unseren Daily, davor gönne ich mir aber erst mal einen Cappuccino. Nach dem Meeting arbeite ich meistens an verschiedenen Programmier-Tasks bis zum Feierabend. Danach bin ich entweder beim Handball- oder Ultimate-Frisbee-Training oder sitze noch am PC für persönliche Projekte wie 3D-Drucken oder Games.
Beim «Travel-Office» hingegen habe ich keine feste Struktur, abgesehen vom Daily-Meeting. Da kommt es halt auch immer drauf an, ob ich nebenbei noch surfe oder sonstige Ferienaktivitäten auf dem Programm stehen.

Viel hab ich im Zug gearbeitet, oder unterwegs im Ausland, meistens für ein Ultimate-Turnier. Ich habe also schon aus Deutschland, Italien, Frankreich, Belgien, den Niederlanden, Spanien und Portugal gearbeitet. Dazu kommen einige «Travel-Office»-Phasen in Italien, Spanien, den Niederlanden und Portugal: Ich war jeweils über längere Zeit dort und habe zwischen Sightseeing, Sonne geniessen und Surf-Sessions ganz normal gearbeitet.

Ein klarer Vorteil: Der Feierabend im Ausland fühlt sich wie kleine Ferien an oder noch im Oktober in der Wärme sitzen und im Meer baden ist schon recht nice. Was ein Struggle sein kann: Es braucht deutlich mehr Selbstdisziplin und über längere Zeit nur mit einem eingeschränkten Setup zu arbeiten fordert seinen Tribut.

Mein Arbeitsgeräts ist ein Gaming Laptop von Captiva mit Intel Core i9 und 64 GB Arbeitsspeicher. Die potente Grafikkarte kann ich für lokale KI nutzen. Und am Wochenende für die gelegentliche Freizeitbeschäftigung.

Der Laptop Stand ist „No Name“, er kühlt das Gerät zusätzlich. In der Mitte habe ich einen grossen Curved Screen, auf dem die Entwicklungsumgebung und ein oder mehrere Claude Code Terminals laufen. Der Hochkant Screen ist zum Testing/Debugging im Browser, während auf dem Laptop ein Browserfenster mit meinen Tasks, E-Mail, Firmenchat etc. läuft. Der Kleine „aufgesteckte“ Screen zeigt meistens das wichtigste Monitoring unserer Web-Systeme. Manchmal auch Trading Charts.

Wir treffen uns 2x pro Monat am Dienstag im Co-Working Villa Loreto an der Florastrasse 14 in Solothurn. Abgesehen davon bin ich immer im Homeoffice, ja. Und ich weiss nicht, ob ich mein Mindset was das angeht jemals wieder ändern könnte.

Wenn die Terminals erstmal zu sind, gibt es viele Optionen:

Deshalb ist Performance bei uns kein Thema, das wir irgendwann am Ende eines Projekts «noch schnell» angehen. Es ist ein integraler Bestandteil unserer gesamten Infrastruktur.

WordPress ist das mit Abstand meistgenutzte CMS der Welt. Gleichzeitig hat es den Ruf, langsam zu sein. Dieser Ruf ist nicht unbegründet – aber er ist auch nicht unausweichlich. Eine gut konfigurierte WordPress-Installation auf einer soliden Infrastruktur ist schnell, stabil und skalierbar. Genau das ist unser Ziel.

Dabei setzen wir nur auf wenige Plugins von Drittherstellern. Ein Set das miteinander funktioniert und sich nicht gegenseitig in Datenbank-Abfrage Schleifen verlangsamt. Yoast SEO darf nicht fehlen und ein WooCommerce baut man nicht über Nacht selbst. Doch seit über 10 Jahren erweitern wir unser eigenes Framework Plugin und programmieren viele Funktionen unserer Kundenwebsites selbst.

In Zeiten von KI-Unterstützter Programmierung kommt uns das sehr entgegen. Nicht nur ist die Software durch „Optimieren auf das Minimum“ sehr performant, wir können mit diesem Ansatz auch genau die Wünsche erfüllen die unsere Kunden haben – und das in sehr kurzer Entwicklungszeit.

Jede dynamische Website stellt ständig Anfragen an eine Datenbank: Welche Seiten gibt es? Was steht auf dieser Seite? Welche Beiträge sollen angezeigt werden? Wie schnell diese Anfragen beantwortet werden, hat einen direkten Einfluss auf die Ladezeit.

Wir betreiben unsere Datenbanken als MariaDB Galera Cluster – das bedeutet, mehrere Datenbankserver arbeiten synchron zusammen. Fällt einer aus, übernehmen die anderen nahtlos. Kein Datenverlust, keine Downtime. Gleichzeitig verteilt der Cluster eingehende Leseanfragen auf mehrere Knoten, was unter Last erheblich zur Stabilität beiträgt.

Dazu kommt ein grosszügig bemessener Datenbank-Cache: Häufig abgefragte Daten werden direkt im Arbeitsspeicher vorgehalten, sodass dieselbe Anfrage nicht jedes Mal von der Festplatte gelesen werden muss. 99% der Anfragen werden aus dem Cache bedient.

Zwischen WordPress und der Datenbank schalten wir Redis als sogenannten Object Cache. Redis ist ein In-Memory-Datenspeicher – er hält berechnete Ergebnisse direkt im RAM vor.

Konkret bedeutet das: Wenn WordPress das erste Mal eine komplexe Datenbankabfrage ausführt (z.B. «gib mir die letzten 10 Blogbeiträge mit ihren Kategorien und Autoren»), wird das Ergebnis in Redis gespeichert. Bei der nächsten identischen Anfrage muss WordPress gar nicht erst zur Datenbank – Redis antwortet in Bruchteilen einer Millisekunde.

Das entlastet die Datenbank erheblich und beschleunigt die Seitenauslieferung spürbar, insbesondere bei Seiten mit vielen dynamischen Elementen.

Auch wenn Redis und der Datenbankcluster schon vieles beschleunigen, entsteht bei jedem Seitenaufruf noch Arbeit für PHP und WordPress.

Unser Full Site Caching geht einen Schritt weiter: Es speichert die fertig gerenderte HTML-Seite direkt zwischen. Kommt eine Anfrage für eine bereits erzeugte Seite rein, wird sie ausgeliefert, ohne dass WordPress überhaupt gestartet wird. Der Server liefert statischen HTML-Code aus – so schnell wie es eben geht. Die reine Server Ladezeit beträgt so mit Übertragung zu dir noch 10 – 50 Millisekunden.

Ein gutes Setup bringt wenig, wenn niemand bemerkt, wenn es schlechter wird. Deshalb überwachen wir kontinuierlich:

In unserer Statistik sehen wir welche Anfragen am längsten dauerten – indes wissen wir von jeder Seite, wie schnell sie erzeugt wurde. Bei über drei Millionen Seiten die unser Cluster täglich ausliefert ist das zentral. Eine kleine Veränderung kann in der Masse fatale Folgen haben.

Technologie entwickelt sich weiter, Traffic-Muster verändern sich, neue WordPress-Plugins können plötzlich unerwartete Datenbankabfragen erzeugen. Deshalb ist Performance-Optimierung kein einmaliges Projekt, sondern ein fortlaufender Prozess.

Wir analysieren regelmässig:

Einmal im Monat nehme ich mir ausserdem Zeit, die „langsamsten“ Seiten zu analysieren und deren Ladezeit zu verbessern soweit es noch möglich ist.

Unit-Tests und API-Tests sind unverzichtbar, aber sie können nicht alles abfangen. Was passiert, wenn:

Diese Szenarien erfordern Tests mit echten Browsern, echten Renderingprozessen und echten User-Interactions. Während Unit-Tests in der Regel ein bestimmtest Feature testet, kann ein Browser-Test einen kompletten Prozess testen.

Screenshots sind mehr als nur Dokumentation. Sie sind unser Frühwarnsystem:

Gibt es in einem Prozess ein Problem werden wir darüber sofort benachrichtigt. Der gelaufene Test enthält genaue Informationen an welchem Punkt etwas scheiterte – sofern möglich mit Screenshot des letzten Punkts vor dem scheitern. Auch du als Kunde kannst optional informiert werden.

Dieses System ist mehr als nur ein technisches Tool. Es spiegelt in gewisser Weise unsere Philosophie wider. Wir glauben daran, dass nachhaltige Software-Entwicklung proaktive Qualitätssicherung erfordert.

Nicht jedes Problem braucht eine Standard-Lösung. Manchmal ist der beste Weg, eigene Tools zu bauen, die perfekt zu den spezifischen Anforderungen passen und langfristig wartbar sind.

Unser Browser-Testing-System zeigt, dass schlanke, durchdachte Eigenentwicklungen mächtiger sein können als komplexe Enterprise-Lösungen. Es ist ein Beleg für unseren Anspruch, nicht nur heute funktionierende Software für dein Unternehmen zu entwickeln, sondern Lösungen, die über Jahre hinweg zuverlässig ihren Dienst verrichten.

Das SEO Plugin Yoast hat eine ähnliche Funktion kürzlich veröffentlicht. Doch bei der werden lediglich ausgewählte oder die letzten fünf Blog Beiträge ohne jegliche Erklärung in die Datei geschrieben. Das ist nur leider gar nicht, was eine KI an der Stelle erwartet. Daher haben wir das ganze auf verschiedene Felder aufgeteilt:

Wenn du einen WooCommere Shop bei uns hast, gibt es noch weitere Möglichkeiten, der KI wichtige Informationen mitzuteilen. Darunter:

All diese Informationen werden mittels Markdown strukturiert ausgegeben, damit die KI den Text korrekt einordnen und verarbeiten kann. Auch etwas, was weder Yoast SEO noch Rankmath tun, obwohl es durchaus das Tüpfelchen auf dem i sein kann.

Bei einer Website oder einem Firmenblog kann es tatsächlich Sinn machen, die aktuellsten Beiträge oder zumindest eine Zusammenfassung davon in die llms.txt einzutragen. Aber nur, wenn regelmässig neuer Inhalt erzeugt wird, der für potentielle Kunden relevant ist. Alternativ fügt man besser von Hand ein paar Evergreen-Beiträge hinzu.

Die neue Funktion findest du im WordPress Backend unter Einstellungen > llms.txt. Die Funktion können bei den meisten, aber nicht überall automatisch aktivieren – sofern du diese nicht siehst, melde dich einfach kurz bei support@comotive.ch.

Immer öfter erhalten Nutzerinnen und Nutzer Antworten direkt von KI-gestützten Systemen wie ChatGPT, Siri, Gemini oder Alexa, Claude und wie sie alle heissen. Diese Antworten stammen häufig aus öffentlich zugänglichen Inhalten von genau den Websites, die Unternehmen sorgfältig pflegen. Doch was bedeutet das für Websites und Onlineshops? Und wie kann man sich als Unternehmen darauf vorbereiten?

Wenn eine KI eine Produktfrage beantwortet, zum Beispiel „Welches E-Bike ist für den Stadtverkehr geeignet?“, dann geschieht das auf Basis öffentlich verfügbarer Inhalte. Die Informationen dafür stammen meist direkt von Websites, die gut strukturiert, sauber geschrieben und suchmaschinenfreundlich aufgebaut sind.

Anders gesagt: Inhalte auf deiner Website werden nicht nur für Menschen, sondern zunehmend auch für Maschinen erstellt. Und genau diese Maschinen entscheiden, welche Information dem Menschen am Ende angezeigt oder vorgelesen wird – oft ohne dass dieser überhaupt noch die Website besucht.

Diese Entwicklung ist eine Herausforderung und eine Chance. Denn wer seine Inhalte jetzt gut strukturiert und für Maschinen lesbar aufbereitet, kann sich in einer Welt der KI-basierten Antworten einen entscheidenden Vorteil sichern. Zwei Dinge sind dabei besonders wichtig:

Wir setzen bei allen Websites und Onlineshops unserer Kunden bwährte SEO Plugins. Das Plugin hilft durch seine Analyse den Text besonders gut lesbar zu machen. Für Menschen und moderne Sprachmodelle / KI. Es kümmert sich aber auch automatisch um viele technische Details:

Wir arbeiten aktuell an einer NLWeb-Schnittstelle (Natural Language Web), die es allen unseren Kunden ermöglicht, ihre Inhalte noch besser für KI-Systeme nutzbar zu machen. Ziel ist es, Inhalte so bereitzustellen, dass moderne Sprachmodelle noch effizienter darauf zugreifen können: Sei es für Produktempfehlungen, FAQs oder sogar automatisierte Bestellprozesse.

So kann zum Beispiel eine KI bald nicht nur erklären, warum dein Produkt eine gute Wahl ist, sondern es auch direkt für den Kunden in deinem Onlineshop bestellen. Und das ohne, dass der Kunde deinen Onlineshop jemals gesehen hat.

Auch wenn der klassische Website-Besuch nie ganz verschwinden wird: Die Rolle der Website verändert sich. Von einem Ort, den Menschen besuchen, wird sie immer mehr zu einer Wissensquelle für Maschinen. Wer jetzt in saubere Struktur, gute Inhalte und eine KI-freundliche Aufbereitung investiert, ist der Konkurrenz einen Schritt voraus oder wird früher oder später abgehängt.

Wir helfen unseren Kunden, diesen Wandel nicht nur zu verstehen, sondern aktiv mitzugestalten. Denn am Ende gilt: Nur wer für Maschinen lesbar ist, wird auch in Zukunft sichtbar sein.

Während du deinen Suchbegriff eintippst, prüfen wir bereits während der Eingabe, ob wir „wissen“, was du suchst. Dazu führt der Code eine Reihe von Abfragen aus:

Die Funktion ist noch nicht lange online, aber die Anzahl der Klicks auf Vorschläge hat sich erhöht. Die meisten Sucheingaben liefern nun erstmals überhaupt Vorschläge – oder mehr und passendere als zuvor. Intern zeichnen wir weiterhin anonym auf, was passiert, damit wir und in Zukunft auch der Suchalgorithmus daraus lernen können.

Die WordPress-Suche ist im Standard einigermassen ausgereift. Aber sie liefert keine Vorschläge und scheitert sofort bei Schreibfehlern. Auch bei Suchanfragen mit mehr als einem Wort stösst sie schnell an ihre Grenzen. Daher testen wir derzeit auf einigen Websites einen teilweise KI-erweiterten Index, der auch für die Suche und die Korrektur von Schreibfehlern genutzt wird.

Sobald wir dieses Feature für rund 200 Websites ausrollen, wird es für alle unsere Kunden – oder vielmehr für deren Besucher und Endkunden – einen positiven Effekt haben.

Die bisherigen Websites waren vor allem eines: Träge. Gerade Suchanfragen, das wichtigste bei einer Job-Plattform, waren sehr langsam. Manchmal wartete man nach eintippen oder anklicken einer Kategorie 5 – 10 Sekunden, sehr oft lief es auch in eine Fehlermeldung – Timeout!

Wer uns kennt weiss: Wir lieben schnelle Websites. Google liebt das übrigens auch, die entsprechenden „Core Web Vitals“ haben wir massiv verbessert. Sie stehen nun alle im grünen Bereich. Neu läuft die Suche grösstenteils nicht mehr auf dem Server sondern im Client ab. Das ermöglicht, alle Seiten grösstenteils zu Cachen – ein Klick in eine Kategorie dauert gemessen nur wenige Millisekunden, wo es vorher ewig dauerte. Die Ergebnisse im Filter erscheinen sofort, so schnell wie man tippen oder klicken kann.

Ein zweites Thema ist die Datenübertragung zwischen der Software von 4future und der Website. Bisher griff die Software von extern (einem anderen Server) direkt auf den offenen Port des MySQL Servers zu. In unserer Welt ist es nicht denkbar, solche Tore zu öffnen. Wie umgesetzt, hätte das keinem Security Audit standgehalten.

Neu gibt es eine striktere Trennung zwischen der Software, die 4future für die Verwaltung der Job-Angebote nutzt und der Website, die diese darstellt. Die Kommunikation zwischen Website und Software geschieht über REST Schnittstellen, welche auf beiden Seiten neu implementiert wurden um den Anforderungen 1:1 gerecht zu werden.

Die Menge der Übertragenen Daten ist relativ gering und die Schnittstellen sind eindimensional – also simpel, schnell implementiert und mit den üblichen Standards abgesichert. Das programmieren von individuellen Schnittstellen in WordPress ist seit vielen Jahren eine gängige Praxis. Für mich nicht mehr wegzudenken, wenn es darum geht Daten automatisch auszutauschen.

Rauszufinden, was an den Standard Suchfunktionen von WordPress nicht gut ist, fällt nicht schwer. Was wir angehen müssen ist:

Nach Analyse der verwendeten Suchbegriffe sehen wir Tippfehler als eines der akuten Probleme. Ganz oft gibt es Buchstabendreher, die mit minimaler Intelligenz in der Software korrigiert werden können. Um das zu ermöglichen, müssen wir eine Liste mit korrekten Wörtern haben: Ich habe also einen Index erstellt, der alle Wörter in der gesamten Datenbank enthält, sowie einige Zusatzinformationen wie die Anzahl der Zeichen, die Wortart (sofern möglich) und wie oft das Wort vorkommt.

Mittels einer Kombination der PHP-Funktionen similar_text() und levenshtein() habe ich dann eine Funktion gebaut, die aufgrund des Indexes mögliche Korrekturvorschläge liefert. Durch similar_text() ist es sogar möglich, diese nach „Grad der Übereinstimmung“ zu sortieren. Zu einfachen Buchstabendrehern, aber teilweise auch bei gröberen Schreibfehlern, kann ich so mit grosser Wahrscheinlichkeit das oder die Wörter finden, die der Besucher tippen wollte.

Wörter, die wir in der Datenbank nicht kennen, kann ich so jedoch nicht korrigieren. Doch das ist fürs Erste nicht schlimm, denn ein nicht bekanntes Wort würde in der Suche sowieso zu keinem Ergebnis führen.

Hierbei handelt es sich eher um ein Komfort-Feature, doch es ist nicht unwichtig. Manchmal versucht man, etwas zu finden, weiss aber nicht genau, wonach man suchen muss. Da wir Suchanfragen aufzeichnen und auch deren Ergebnisse kennen, kann ich nun beim Tippen des Suchbegriffs bereits Vergleiche anstellen mit vormals erfolgreichen Suchanfragen. Hierbei habe ich priorisiert, dass gleich beginnende Zeichenketten zuerst erscheinen, danach solche, die mittels similar_text() hinzugefügt werden. Gibt man nun „Tell“ ein, zeige ich die relevantesten Suchanfragen an, wie „Teller Dessert“, „Teller rot“ oder eben auch „Suppenteller“.

Diese Funktion planen wir im weiteren Verlauf der Optimierungen noch weiter zu verbessern. Je mehr Informationen wir hier aufzeichnen können, desto mehr lernen wir und schliesslich auch die Software, wie und wonach die Leute suchen.

Zugegeben, vor diesem Projekt war mir gar nicht klar, was ein Volltextindex in einer SQL-Datenbank eigentlich genau ist. Es ist nicht das gleiche wie ein Index – ich dachte einfach, dass es genau das ist: ein Index für eine Spalte mit Text, also dem Datentyp CHAR, VARCHAR oder TEXT. Ähnlich, aber nicht ganz.

Ein wesentlicher Punkt ist, dass man einen Volltextindex über mehrere Spalten erstellen kann. Das kann, sofern man genau das will, erübrigen, dass man über mehrere Felder mit OR und LIKE sucht, was gerade bei mehr als einem Wort in einem Suchbegriff schnell schwierig wird. Und genau deshalb funktioniert auch die WordPress-Suche mit einem Begriff ganz okay, aber bei mehreren Worten wird’s schon schwierig. Einen Volltextindex hat WordPress weder auf der „posts“- noch auf der „postmeta“-Tabelle.

Im ersten Schritt wollte ich einfach einen Volltextindex über die Titel-, Exzerpt- und Content-Felder erstellen. Doch ich hatte noch ein paar weitere Ideen, um den Index zu füllen. Auch Informationen aus den Kategorien, Schlagworten oder – bei Produkten – deren gesamten Eigenschaften müssen in den Index. Teilweise auch Metadaten, die sonst schwer oder gar nicht auffindbar wären. Und wir leben ja im Zeitalter der KI – warum also nicht auch noch eine oder zwei Spalten von einer KI erzeugen lassen?

All das habe ich getan, in einer eigenen Tabelle, die speziell als Suchindex dient. Besonders eingehen möchte ich auf Letzteres: Mit der ChatGPT-API übergeben wir einen Prompt mit den Informationen zu unserem Inhalt – dies kann ein Beitrag, ein Produkt oder irgendein kundenspezifischer Datentyp sein. Diese Informationen und den vorhandenen Text gebe ich automatisch ChatGPT, um daraus weitere Informationen zu erzeugen.

Ich muss nun selbst definieren, ob ich einen Volltextindex über alle Spalten erstelle oder mehrere Spalten in verschiedene Indizes aufteile. Ich weiss, dass ich mit MATCH und AGAINST in SQL meinen Index (oder mehrere) mittels OR abfragen kann. Wenn ich die Indizes trenne, habe ich die Möglichkeit, einem Index in der Sortierung nach Relevanz mehr Gewicht zu geben.

Im ersten Schritt hatten wir pro Spalte einen eigenen Volltextindex. Das führte zu einem langen Statement mit vielen OR-Bedingungen und einer entsprechend längeren Relevanzberechnung – diese übernimmt MariaDB (wahrscheinlich auch MySQL und jedes andere Datenbanksystem) automatisch bei der Nutzung eines Volltextindex. Die Berechnung fällt je nach Modus unterschiedlich aus, abhängig davon, ob der „Natural Language“- oder der „Boolean“-Mode verwendet wird. Auch hier musste ich zunächst einige Tests durchführen.

Derzeit habe ich es auf zwei Volltextindizes beschränkt: Einen für die eigenen Inhaltsfelder und einen für die von der KI hinzugefügten Inhalte. Je nach Anzahl der Suchwörter und deren Länge wechsle ich im SQL-Statement automatisch zwischen den beiden Modi, da jeder je nach Suchbegriff seine eigenen Vor- und Nachteile hat.

Wie man es aus Onlineshops kennt, kommen sowohl auf Kategorieseiten als auch auf Suchergebnisseiten Filter zum Einsatz, um die Ergebnisse weiter einzuschränken. Ich experimentiere derzeit damit, einzelne Suchwörter aus der Anfrage bei (fast) eindeutigen Ergebnissen automatisch einem passenden Suchfilter zuzuordnen und diesen direkt zu aktivieren.

Gibt jemand beispielsweise „Fussball Übungen Torhüter“ ein, selektieren wir automatisch die Kategorie „Fussball“ sowie die Inhaltsart „Übung“ und durchsuchen die gesamte Datenbank nach Inhalten, in denen eines bis alle dieser drei Wörter vorkommen – sinnvoll nach Relevanz sortiert. In Onlineshops führt dies oft dazu, dass ein allgemeinerer Suchbegriff direkt auf eine Farbe und/oder ein Material eingeschränkt wird. So erkennt der Nutzer sofort, dass er den Filter anpassen und nach weiteren Eigenschaften einschränken kann. Eine voreingestellte Farbe wie „Rot“ kann dann beispielsweise entfernt und durch „Violett“ ersetzt oder ergänzt werden.

Ich plane, dieses Konzept auch für Suchbegriffe mit Zahlen einzuführen – das ist allerdings ein eigenes kleines Projekt. Eine Suche nach „Trinkglas 1,5 – 3 dl“ soll künftig nicht mehr zu „Keine Resultate“ führen sondern Trinkgläser finden mit genau diesem Bereich an Fassungsvermögen. Die kontinuierliche Verbesserung der Suchfunktion steht bei mir regelmässig auf dem Plan, damit die Kunden unserer Kunden genau das finden, wonach sie suchen.

Um für uns und unsere Kunden für Kostensicherheit zu sorgen, wählten wir einen von zwei möglichen Ansätzen. Wir erzeugen über die Schnittstelle eine MP3 Audiodatei im Hintergrund, sobald ein Beitrag oder eine Seite bereit ist aufgeschaltet zu werden. Das hat ein paar Vorteile:

Die Alternative wäre, keine initiale Erzeugung von Audio-Dateien. Elevenlabs bietet die Möglichkeit, das Audio erst zu erzeugen, wenn es benötigt wird (Streaming). Dies geht mit einer kurzen Verzögerung einher, ausserdem lässt sich das Audio so nicht lokal speichern, womit sukzessive laufende Kosten entstehen, die nicht immer vorhersehbar sind.

Ein Nachteil ist, dass man sich einmal auf eine Stimme festlegen muss. Elevenlabs bietet sehr viele professionelle Stimmen, die man beliebig ausprägen oder verändern kann. Ist das Audio jedoch einmal erzeugt, müsste man alle Dateien bei einem Stimmenwechsel potentiell neu erzeugen.

Ein sehr interessantes Feature, gerade für’s Personal Branding: Mit Elevenlabs kann man nicht nur vordefinerte, sondern auch seine eigene Stimme verwenden. Bereits mit einer 30-Sekunden Aufnahme der eigenen Stimme, bekommt man gute Resultate. Je länger die Beispielaufnahme, desto besser wird die Qualität. Bei einer kurzen Aufnahme und typischem «Schweizer hochdeutsch» klingt die eigene KI-Stimme dann ein wenig bayrisch bis österreichisch. Ein Beispiel meiner Stimme:

Hier in unserem Blog nutzen wir für’s erste eine der Standard-Stimmen. In meinem Sideventure erneuer.bar plane ich allerdings meine eigene Stimme als «Erzähler» zu verwenden.

Unseren Kunden steht die neue Vorlesefunktion nach erstmaliger Konfiguration der Stimme ab sofort zur Verfügung. Dabei fallen lediglich die Nutzungskosten der Schnittstelle von Elevenlabs an: Etwa 30 Rappen pro vorgelesene Minute – das sind jenachdem etwa 125 bis 150 Wörter. Das Erzeugen dieses Beitrags hat einmalig etwas weniger als einen Franken gekostet.