Suchmaschinenoptimierung bei ASP.NET Teil 1 – Der Viewstate

 in .NET Entwicklung  verschlagwortet ASP.NET / Google / SEO / Suchmaschinenoptimierung / Viewstate von

Suchmaschinenoptimierung ist in alle Munde bei den Website Entwicklern. Bei ASP.NET gibt viele Dinge zu beachten, denn man wird mit den ein oder anderen Stolpersteinen konfrontiert werden, und die ein oder andere Unwegsamkeit entdecken. Der folgende Artikel Handelt von der Suchmaschinenoptimierung mit ASP.NET in Verbindung mit dem Viewstate.

Meine Artikel beschränken sich hier auf ASP.NET, hier ist die Dichte von entsprechenden Artikeln ziemlich gering im Internet. Vorweg, ich bin sicherlich kein SEO Experte, das ist eine Wissenschaft für sich. Sollte ich in diesem oder einen der folgenden Beiträge Fehlinformationen vebreiten, so würde ich mich freuen wenn Ihr mich darüber informiert. Gerne auch über die Kommentarfunktion!

Der Viewstate

Ich denke der Viestate hat in diese Zusammenhang eine große Bedeutung. Der Viewstate speichert Inhalte von Steuerelementen der angezeigten Website um diese bei einem Postback oder Callback an den Server zu übermitteln. Der Viewstate wird in einer verschlüsselten Weise im Head abgelegt. Und genau hier liegt das Problem was die SEO Optimierung betrifft. Der Viewstate kann je nach Dichte der angezeigten Steuerelemente sehr umfangreich werden. Ich habe Projekte da erreicht der Viewstate gut und gerne mal 512 KB und mehr. Mehr als 5 bis 10 KB Viewstate können bereits ein Problem darstellen. Google liest zum einen nicht die Gesamte Seite, sondern nur einen Bestimmten Teil (mir leider unbekannt) von Anfang der Seite. Des Weiteren bewertet Google den Content nach seine Position in der Seite, sprich Keywords haben eine höhere Gewichtung je weiter oben Sie stehen. Genau diese Gewichtung verringert uns im Idealfall der Viewstate, ist der Viewstate zu groß kann es u.U, sogar dazu führen dass Google gar keinen Content zu Gesicht bekommt.

Die Lösung(en)

Ich stelle nun zwei Möglichkeiten vor wie man diesem Problem entgegen wirken kann. Die erste Lösung ist so einfach wie ein Radio auszuschalten. Der Viewstate lässt sich durch eine Page Direktive schlicht deaktivieren.

<%@ Page Enableviewstate=“false“ %> 

Allerdings ist diese Variante nicht immer erwünscht, denn der Viewstate macht in manchen Situationen durchaus auch Sinn und wird benötigt. Die zweite Lösung liegt darin, den Viewstate an eine Stelle zu verschieben, an dem er bei Google und Co. keinen Schaden anrichten kann. Sehr gute Erfahrungen habe ich gemacht in dem ich den Viewstate in eine Session Variable geschrieben habe. Damit bekommt Google und auch der Client erst den Viewstate gar nicht zu Gesicht, und sorgt nebenbei auch noch dafür dass etwas Traffik gespart wird, bzw. sich die Seite schneller aufbaut.

Zunächst braucht man dafür eine neue Klasse in ASP.NET:

Partial Public Class BasePage
    Inherits System.Web.UI.Page
Protected Overrides Sub SavePageStateToPersistenceMedium(ByVal viewState As Object)
        Dim Key As String = Request.Url.ToString & "__VIEWSTATE"
        Dim memStream As New System.IO.MemoryStream
        _formatter.Serialize(memStream, viewState)
        memStream.Flush()
        Session(Key) = memStream
        Writelog("SavePageStateToPersistenceMedium", "Time")
    End Sub

    Protected Overrides Function LoadPageStateFromPersistenceMedium() As Object
        LoadPageStateFromPersistenceMedium = ""
        Dim Key As String = Request.Url.ToString & "__VIEWSTATE"
        If Not Session(Key) Is Nothing Then
            Dim memStream As System.IO.MemoryStream = CType(Session(Key), System.IO.MemoryStream)
            memStream.Seek(0, IO.SeekOrigin.Begin)
            Return _formatter.Deserialize(memStream)
        End If
        Writelog("LoadPageStateFromPersistenceMedium", "Time")
    End Function
End Class

Diese Klasse muss dan auf der ASP.NET Seite in der Code behind Datei anstatt System.Web.UI.Page per Inherit importiert werden. Die Basisklasse System.Web.UI.Page wird dabei mit vererbt.

Die Beiden Funktionen Überschrieben Funktionen aus der Basisklasse und sorgen dafür dass der Viewstate in einer Session Variable gespeichert, bzw. abgerufen wird.

Fazit

Wenn Möglich sollte man auf den Viewstate verzichten, in den meisten Fällen ist dies problemlos möglich. Denn der Viewstate bringt leider auch noch ein paar weitere Unwegsamkeiten mit sich. Diese hat wie die Session nur eine bestimmte Lebenszeit bis er in einen Timeout läuft. Das bedeutet dass der Viewstate nach Ablauf des Time to Live ungültig wird, und ein Postback oder Callback in eine Exception läuft.

Sollte dies nicht möglich sein, so empfiehlt sich die Verwendung der obigen Lösung. Es gibt noch eine dritte Lösung inder der Viewstate ans Seitenende in ein Hiddenfield verschoben wird. Diese Variante habe ich bislang noch nicht eingesetzt oder getestet. Sollte ich das mal tun, werde ich meine Erfahrungen damit hier veröffentlichen.

Schreibe einen Kommentar