Vergleich der Google-Algorithmen

Googles „mobile friendly“-Update hat stärkere Auswirkungen als Panda oder Penguin

“The April 21st update will have more of an impact on Google’s search results than the Google Panda update and the Google Penguin update did.”

Zineb Ait Bahaji,
Webmaster Trends Analyst for Google

Google-Panda-and-Penguin

picture: seo-hacker.com

Bis zu 500 Mal pro Jahr ändert Google seine Suchalgorithmen. Während die meisten Aktualisierungen nur kleine Modifikationen beinhalten, dessen Auswirkungen kaum merkbar sind, führen andere Updates tiefgreifende Änderungen mit sich. Die großen Algorithmus-Updates tragen unter Anderem Tiernamen wie „Panda“, „Penguin“ und „Hummingbird“. Sie klingen harmlos, hier verstecken sich jedoch umfassende Konsequenzen für Webseitenbetreiber.

Reaktion auf Linksfarms und andere Spam-Techniken

Im Zeitraum von Februar 2003 bis Oktober 2005 nahm die Reihe der großen Google Updates ihren Lauf. Die Suchmaschine begann mit Maßnahmen gegen die unsachgemäße Verwendung von Links und Spam-Techniken. Dies galt vor allem der Bekämpfung von „Linkfarms“. Als solche werden Webseiten zur Suchmaschinenoptimierung bzw. -manipulation bezeichnet, die durch eine hohe Anzahl von Verlinkungen auf eine Webseite deren Traffic erhöhen sollen.

Gefolgt wurde dieses Update von „Universal Search“. Im Zuge dieser Neuerungen wurde die Relevanz von Bildern, Videos und Inhalten mit lokalem Bezug im Ergebnisranking erhöht.

Im Februar 2009 wurde die umstrittene „Vince“-Aktualisierung eingeführt, die bei den Nutzern bekannte Marken favorisierte. Diese Marken werden seitdem im Ranking bevorzugt angezeigt, unabhängig von Struktur und Inhalt der Webseite.

Gleich zwei gravierende Änderungen ereigneten sich 2010

Das erste Update wurde im Mai 2010 ausgerollt und „May Day“ getauft, nachdem viele Betreiber immense Einbrüche ihrer Traffic-Zahlen beobachteten. Betroffen sind Suchanfragen, die mehrere Worte beinhalten. So werden nun Ergebnisse höher gerankt, die konkrete Anleitungen oder Diskussionen zu den Suchworten enthalten.

Mit „Caffeine“ optimierte Google im Juni 2010 die technische Grundlage des Suchindexes selbst. Relevante Inhalte können nun zeitnaher nach Erscheinungsdatum gefunden werden und die Suchergebnisse sind präziser als zuvor.

Das Update „Panda“ verursachte bisher die stärksten Einbußen

Top-10-Best-Tips-on-How-to-Survive-Googles-Panda-Algorithm-UpdatePicture: Techchunks

Die neue technische Aufstellung des Algorithmus lieferte die Grundlage für das 2011 eingeführte Update „Panda“, welches rund 12% aller Suchergebnisse betraf. Webseiten und Inhalte von geringer Qualität können durch diese Aktualisierung effizienter gefiltert und im Ranking herabgestuft werden. Dies schlug hohe Wellen in der SEO-Branche und traf viele Webseitenbetreiber unerwartet.

Dabei verlor ebay.de etwas mehr als 30 % an Sichtbarkeit.

Sichtbarkeit bedeutet in diesem Zusammenhang die Besucheranzahl einer Webseite, die durch Google-Anzeigen generiert werden.

Auch die Springer-Tochter Idealo.de musste ca. 29 % Sichtbarkeitseinbußen verschmerzen.

Hart getroffen wurden vor allem auch Portale, die Inhalte anderer Anbieter bewerten oder kommentieren. Dazu gehören Webseiten für Preisvergleiche, Linksammlungen zu Gutscheinen sowie Frage und Antwort-Portale.

Bis zu 50% Traffic-Verluste waren keine Seltenheit.
Viele bekannte Anbieter mussten schwerwiegende Verluste hinnehmen:

  • ciao.de: -58%,
  • gutefrage.net: -57%,
  • shopping.com: -57% ,
  • wer-weiss-was.de: -62%,
  • preisroboter.de_ -54%,
  • geizkragen.de: -59%

Beginn der Sinnsuche – mit dem Update Kolibri kommt die semantische Auswertung

„The name comes from being precise and fast.“

Amit Singhal
Google VP Software Engineer

Das Update Kolibri, welches im August 2013 umgesetzt wurde, war ebenfalls ein Meilenstein, diesmal im Sinne der Nutzer: Die gesamte Suchanfrage sowie die semantischen Beziehungen von Wortgruppen innerhalb dieser können nun zielgerichteter identifiziert und interpretiert werden. Google versteht den Sinn der Suche besser und ist nicht mehr von einzelnen Keywords abhängig. Beim Ranking in der semantischen Suche kommen Faktoren wie Sinngehalt, Kontext, Assoziation, Identität, Intention und Beziehungen zum Tragen.
Der Algorithmus ist seitdem in der Lage die Inhalte einer Webseite besser zu analysieren und den Suchanfragen entsprechend zuzuordnen.

Hiermit wurde erstmals auf Mobilnutzer eingegangen, indem Spracheingaben nun besser interpretiert und umgesetzt werden können. Denn bei der sogenannten Conversational Search wird in den meisten Fällen ein kompletter Satz eingesprochen, auf den – Dank des Updates – besser eingegangen werden kann.

Googles „mobile friendly“-Update hat stärkere Auswirkungen als Panda oder Penguin

Im April steht das neueste Algorithmus Update „mobile friendly“ an und wird das Ranking von Webseiten bei der mobilen Internetnutzung erheblich beeinflussen. Google selbst bezeichnet den Einfluss des neuen Algorithmus als ähnlich gravierend wie Panda oder Penguin.

Die Faktoren, die das Ranking der Suchergebnisse bestimmen, werden sich ab dem
21. April 2015 auch danach richten, ob Webseiten für mobile Geräte verfügbar sind oder nicht. Falls ja, spielt die Qualität der mobilen Darstellung eine Rolle.

Dabei wird das Label „für Mobilgeräte“ eingeführt. Dies soll den Smartphone-Nutzer auf mobil optimierte Seiten hinweisen und ihn dorthin führen.

Bildschirmfoto 2015-04-16 um 14.39.06

Experten vermuten, dass dieses Label abgelöst wird von dem Hinweis „slow“ für mobile Webseiten, die zu lange laden. Neben den eher an der responsiven Darstellung orientierten Kriterien von „mobile friendly“, wird die Performance in Zukunft also eine stärkere Rolle spielen.

google-slow-label

Googles Test Tools

Google hat zur Vorbereitung auf die neuen Kriterien eigens ein Webmastertool zur Verfügung gestellt, mit dem überprüft werden kann, ob eine Webseite mobil optimiert ist oder nicht:
https://www.google.de/webmasters/tools/mobile-friendly/
Die Performance kann mit dem PageSpeed-Test gemessen werden: https://developers.google.com/speed/pagespeed/insights/

Fazit

Nachdem bisherige Updates vorrangig der Qualität der Suchergebnisse galten, zieht Google nun erstmals erhebliche Konsequenzen aus der Entwicklung des Nutzerverhaltens.

So reagiert Google auf die rasante Entwicklung der Mobile-Nutzung und des wachsenden E-Commerce weltweit. 2014 lag der Anteil der mobilen Nutzer im E-Commerce erstmals dauerhaft über 50%. Jährlich steigt die mobile Nutzungsrate um mehr als 20 %.

Jeder zweite Smartphone-Nutzer recherchiert oder kauft mobil und bereits 53% aller Smartphone-Besitzer haben generell schon einmal auf dem Smartphone Produkte recherchiert oder gekauft. Allein im deutschen mCommerce wurden im Jahr 2014 6,6 Milliarden Euro umgesetzt.

Logisch also, dass auch Google den mobilen Trend nicht ignorieren kann.

Was also müssen Webseitenbetreiber jetzt wissen und technisch umsetzen? 

Schneller Shopstart auf allen Kanälen – Intershop und Sevenval vereinfachen Multi Device E-Commerce

Koop

Stellen Sie sich vor, Sie betreiben einen Online-Shop. Ihre Kunden nutzen auch Smartphones oder Tablets für ihren Einkauf im Internet. Mobile Commerce-Umsätze machen eine erheblichen Anteil Ihres Gesamtumsatzes aus.  

Ihre Produktsortimente oder Markenshops sollen:

  • schnell und unkompliziert ausgerollt werden können UND
  • voll responsive über alle Kanäle laufen.

Wie kann so eine Lösung aussehen?


Front-End-Server + Shopsystem
Wir haben Sevenval FIT und Intershop Commerce Suite kombiniert.
Warum? Jedes Tool tut das was es am besten kann: Mit Intershop lässt sich die gesamte E-Commerce-Logistik unkompliziert managen. Sevenval gewährleistet eine optimale Performance und Usability von E-Shop für Desktop-PCs, Tablets und Smartphones.
Zu diesem Zweck wurde Sevenval FIT und Intershops Webadapter zu einem Webserver verzahnt.
Alle Funktionen beider Tools stehen neuen Shops sofort zur Verfügung.

Das bedeutet

Schneller Roll-out von neuen Produktsortimenten

  • Schnelle Erstellung eines neuen Markenshops oder Produktsortiments durch vereinfachtes Aufsetzen des Webservers möglich
  • Agile Entwicklungsumgebung: Built- und DeploymentProzesse laufen automatisch
  • Schnelle Implementierung: Neue Shops erhalten automatisch das Feature-Set zur Front-End-Optimierung für Smartphone, Tablet und Desktop
  • Kundenspezifische, schnelle Feature-Entwicklung für den Shop mit vorgefertigten, anpassbaren Elementen (Adaptive Components)

Full Responsive für Desktop, Smartphone, Tablet

  • Sevenval FIT integriert Feature- und Device Detection für jeden Shop
  • Damit gewährleistet Sevenval FIT eine optimierte Content-Auslieferung für jede Kombination von Gerät und Browser
  • Entlastung der Entwickler durch vereinfachtes Bug-Fixing und Software-Updates für alle Geräte
  • Mobile- und Tablet-Shops sind als Standard-Module bei jedem Webshop verfügbar

Optimale Performance und Usability

  • Entlastung des Browsers
  • Serverseitige Abwicklung von rechenintensiven Operationen
  • Front-End-Acceleration durch:
  • Image Scaling & Handling: Bilder werden auf dem Server skaliert, Bildformate werden angepasst (Beispiel: webp für Chrome)
  • Minifying: Reduzierung des HTML Codes erfolgt automatisch
  • Render Queue Optimization: Optimierung der Ladevorgänge im Browser

Schnelle, agile Entwicklung von neuen Shop-Features

  • Sevenval FIT integriert sich nahtlos in gewünschtes Entwickler-Setup
  • Bisherige Toolchain bleibt erhalten
  • Agile Development und Continuous Integration wird unterstützt
  • Adaptation Instructions ermöglichen Steuerung von CSS und Content bezüglich Gerätefähigkeiten (z.B. Webfonts, Serverseitiges Progressive Enhancement usw.


Fazit:

Sevenval FIT und die Intershop Commerce Suite…

… verkürzen die Time-to-Market
… bieten hochwertiges Responsive Design durch serverseitige Unterstützung
… erreichen perfekte Performance auf allen Kanälen
… sind mit den gängigen Developer-Tools kompatibel

Your Tools, Your Rules!

RESS Server Architektur: Das bessere Responsive Web Design!

Nachdem wir uns in den ersten beiden Teilen dieser Kleinserie zuerst den Definitionen hinsichtlich der Ansätze RWD und RESS sowie den Vor- und Nachteilen des RWD-Konzepts gewidmet haben, folgt nun der dritte Teil, welcher die Stärken und Schwächen einer RESS Server Architektur näher vorstellt.

Die Weiterentwicklung einer RWD Architektur zu einer RESS Server Solution stellt aus diversen Gesichtspunkten einen enormen Mehrwert dar. Maßgeblich sind hier die folgenden Vorteile zu nennen:

Vorteile RESS

Allgemein:

  • Nutzung einer Device Database zur Device- und Feature Detection – optimale Ausgabe für das Endgerät
  • Einfaches Update der Device Database um neue Endgeräte, Browser und Betriebssysteme hinzuzufügen
  • Verringertes Datenvolumen – es wird nur der benötigte Inhalt ausgeliefert
  • Serverseitige Bildkompression und –transformation (z.B. in andere Bildformate)
  • Hohe Performance – durch serverseitige Verarbeitung und entsprechende Caching-Mechanismen
  • Seitenladeverhalten wird positiv beeinflusst durch:
    • Optimale CSS und Images
    • JavaScript Minimierung
    • Reduzierung von http-Requests
    • Reduzierung der Bytes der Webseite (GZIP)

Sichtweise Business:

  • Neue Endgeräte können leichter integriert werden, somit schnellere Marktdurchdringung und bessere Time-to-Market.
  • Saubere Trennung zwischen Front- und Backend, dadurch entkoppelte Entwicklung und Maintenance möglich
    • In der Konsequenz können dadurch aus Business-Sicht Anforderungen schneller im Frontend an die Nutzer ausgerollt werden.
    • Dadurch entsteht eine höhere Innovationsperformance
  • Serverseitige Integration von weiteren Komponenten möglich – wie z.B. A/B Testing Module, Analytics etc.

Optimales Setup für die Analyse von Kennzahlen und Ableitung von geeigneten Maßnahmen zur Steigerung der Conversion Rate.

Nachteile RESS

Eine RESS Server Architektur bedeutet für den Kunden in der Regel ein höheres initiales Investment. Um eine möglichst optimale RESS Architektur erfolgreich zu realisieren, müssen weitere Technologien betrachtet und evaluiert werden, um z.B. das Seitenladeverhalten zu beschleunigen, als auch die Skalierung und Komprimierung von Grafiken performant abbilden zu können.

Ergänzend zum RWD Konzept müssen die serverseitigen Komponenten selbst entwickelt werden oder durch bestehende Technologien am Markt abgedeckt werden. In beiden Szenarien muss sich der Kunde mit diesen Themen auseinandersetzen – unabhängig davon ob er bestehende Lösungen einkauft oder ggf. selbst entwickelt:

  • Erweiterung der Serverkomponente – mehr Intelligenz im Backend bedingt auch eine entsprechende Infrastruktur
  • Definition der serverseitigen Prozesse
  • Evaluierung von Technologien um z.B. Grafiken zu verarbeiten, JavaScripts zu minimieren, oder Seitenladeevents zu beeinflussen etc.
  • Know-how-Aufbau im Entwicklungsteam
  • Kostenbetrachtung im Hinblick auf die Wartung und den Support der eingesetzten Technologien
  • Kosten hinsichtlich der Anschaffung und Pflege einer Device Database

Fazit

Zusammenfassend lässt sich nun sagen, dass durch die beschriebenen Vorteile der RESS Server Architektur im Vergleich zu einem klassischen RWD-Ansatz besser auf neue Anforderungen und Nutzererwartungen eingegangen werden kann. Darüber hinaus ist ein positiver Effekt auf die Maintenance-Aufwände zu erwarten.

Dies kommt den Business-Zielen zugute, da die Nutzerzufriedenheit höher ist, was sich wiederum in der Conversion Rate (CVR) niederschlägt. Der Return on Invest ist hierdurch früher erreicht und die time-to-market für neue bzw. verbesserte Features verkürzt sich durch eine klare Trennung von Frontend- und Backend-Prozessen bzw. deren Logik. Ebenso sind der Betrieb und Wartung deutlich besser kalkulierbar. Anpassungen für neue Geräte und Browser fallen weniger aufwändig aus und sind damit deutlich schneller produktiv ausgerollt. Es entstehen keine, bzw. nur minimale Verzögerungen um neue Endgeräte zu bedienen. Die Total Cost of Ownership sind verglichen mit einem RWD-Ansatz günstiger und mit steigenden Erfahrungswerten langfristig planbar.

Und last but not least: Die Nutzer sind zufriedener und fühlen sich und ihre Erwartungen besser berücksichtigt. Dies wirkt sich positiv auf die Nutzungszahlen, als auch die Conversion Rate aus. Daher sollten die Erwartungen und der mögliche Impact vor einer Technologieauswahl analysiert und unter den vorgestellten Gesichtspunkten bewertet werden.

Warum klassisches Responsive Web Design (RWD) nicht das Maß aller Dinge ist!

Nach dem wir zuletzt die Methoden RWD und RESS kurz verglichen haben, vertiefen wir hier die Betrachtung vom klassischen Responsive Web Design. Mit dem Aufkommen einer neuen Generation von Endgeräten mit unterschiedlichsten Spezifikationen und Bildschirmgrößen hat sich Responsive Web Design als Standard bei der Umsetzung eines Webauftritts etabliert. Dennoch ist dieser Ansatz kein Allheilmittel und es gibt Anforderungen und Herausforderungen, welche mit Hilfe von klassischem Responsive Design nicht optimal gelöst werden können. Nachfolgend werden die jeweiligen Vor- und Nachteile des Ansatzes dargestellt und bewertet.

Vorteile RWD

Das RWD-Konzept bietet viele Vorteile gegenüber Einzelentwicklungen, oder „Sonderkanälen“ für dedizierte Endgeräte. Dies sind unter anderem die folgenden Punkte:

  • Es muss nur eine generische Content-Basis für alle Endgeräte erstellt werden
  • Kein Spezialkanal notwendig (t.example.com, m.example.com,…)
  • Einheitliche Inhalte und Prozesse für alle Endgeräte (z.B. synchroner Warenkorb)
  • Gebündelte Suchmaschinen-Optimierung (für eine URL)
  • Querverlinkungen sind möglich (Newsletter von PC, Tablet, Smartphone…)
  • Einmalige Entwicklung für alle Endgeräte
  • Eine zentrale Präsentationsschicht
  • Sparsame Anforderungen an die Serverlandschaft

Nachteile RWD

Bereits 2011 hat Luke Wroblewski die Nachteile von RWD dargestellt und gilt als „Mitbegründer“ des RESS Ansatzes (Responsive Web Design mit server-seitigen Komponenten). Die Nachteile stellen sich wie folgt dar:

Generell:

  • Es wird eine allgemeingültige Basis für alle Endgeräte vorgesehen – die Qualität der Anpassung ist nicht optimal.
  • Die Darstellung übernimmt das Endgerät, bzw. der Browser. Mittels unterschiedlicher Techniken muss dieser Client entscheiden, welche Inhalte wie angezeigt werden können.
  • Die Adaption kann und muss allein auf dem Client erfolgen.
  • Die Prozesse sind auf allen Endgeräten gleich – und werden ohne Anpassung aus dem Backend übernommen
  • Es werden immer alle Daten übertragen, unabhängig davon ob sie dargestellt werden können oder nicht.

Sichtweise Business:

  • Durch die einheitliche Content-Auslieferung für alle Endgeräte, werden mehr Daten übertragen als für das jeweilige Endgerät nötig sind. Aufgrund der längeren Übertragungszeiten und intensiveren Rechenleistungen verzögert sich die Darstellung auf dem Endgerät.
  • Funktionen werden auf allen Endgeräten gleich abgebildet (keine optimierte Version für das Endgerät des Anwenders, z. B. Touch Eingaben wie Slider o. ä.).
  • Wegen der schlechteren Performance sinkt erfahrungsgemäß die Akzeptanz beim Kunden – die Folge sind Abbrüche, oder eine rückläufige Entwicklung der Conversion Rate (potenzieller Umsatzverlust!)
  • Hohe Investitionen, wenn RWD unternehmensweit eingeführt werden soll. Prozesse müssen neu definiert und aufgesetzt werden. Die Konzeption über sämtliche Ausgabekanäle hinweg ist aufwändig, insbesondere die Harmonisierung der Backendlandschaft (CRM, CMS, ERP, etc.) stellt eine große Herausforderung dar.
  • Durch die steigende Anzahl von neuen Endgeräten, Browsern und Betriebssystemanbietern gestaltet sich die Pflege der RWD Lösung aufwändiger (erhöhte Maintenance).
  • Dadurch, dass immer die komplette Webseite an die anfragenden Endgeräte ausgeliefert wird, muss sichergestellt werden dass keine unerwünschten Nebeneffekte bei neuen Endgeräten auftreten.
  • Die Analyse, wo die Inkonsistenz auftritt und wie der Fehler behoben werden kann führt zu erhöhtem Entwicklungs- und Testaufwand.
  • Die Wartbarkeit der Webseite wird sukzessive erschwert, da der Code durch neue Adaptionsregeln immer komplexer wird.

Fazit

Nach Lesen des Artikels macht es den Anschein, dass das klassische Responsive Web Design ein Auslaufmodell sei, was jedoch so nicht stimmt. Vor allem für Blogs, kurzfristige Kampagnenseiten oder den Webauftritt für KMUs  ist dieses Konzept nach wie vor passend und zeitgemäß.

Größeren Konzernen sowie Unternehmen, welche über den Webauftritt Transaktionen abwickeln, könnte eine solche Umsetzung jedoch Schwierigkeiten bereiten.  Mangelhafte Anpassungen und schlechte Performance einer Webseite werden von E-Commerce-Kunden umgehend bestraft: Laut Kissmetrics verlassen 40 % aller Nutzer eine Webseite, die länger als drei Sekunden lädt. Jede Sekunde Verzögerung verringert die Conversion Rate eines Webshops um sieben Prozent. Infolgedessen führt dies natürlich auch zu einem Imageverlust des Unternehmens.

Des Weiteren sollte man vor der Umsetzung eines Webprojekts die Gesamtkosten betrachten und sich nicht von Initialkosten blenden lassen. Es stellt sich die Frage, welche Betriebskosten anfallen. Welche Kosten entstehen, wenn die Webseite an ein neues Smartphone oder ein Browser-Update angepasst werden muss? Welche Bugs und Anpassungen können inhouse gelöst werden und was muss manuell gemacht werden?

Wer für alle Geräte eine optimale Darstellung ohne Bugs anstrebt, braucht eine RESS-Lösung, um die Betriebskosten für diese Ansprüche niedrig zu halten.

Den Browser entlasten: Responsive Web Design mit serverseitigen Komponenten (RESS)

Responsive Web Design (RWD) – endlich in den Unternehmen angekommen und als Begriff etabliert ist die Technologie auch schon wieder überholt. RESS ist das neue Schlagwort mit dem man sich auseinandersetzen muss, will man seine Webseite nutzerfreundlich über alle verschiedenen Kanäle ausspielen. RESS, genauer gesagt Responsive Web design with server side components – was ist das? Was sind die Vorteile sowie die etwaigen Nachteile? Diese Fragen wollen wir in einer kleinen Serie von Blogeinträgen beantworten, indem der vergleichsweise junge Ansatz RESS mit dem klassischen RWD verglichen wird.

Im ersten Schritt möchten wir die beiden Konzepte definieren und die jeweilige Architektur dahinter vorstellen:

Definition Responsive Web Design (RWD)

Responsive Web Design bezeichnet ein Konzept, bzw. Vorgehensmodell, das die Ansätze wie liquid Design, Adaptive Images und Media Queries kombiniert, um abhängig vom Endgerät bzw. Browser die Darstellung der Webseite anzupassen.

Ziel ist es, eine Web-Ausgabe für alle Endgeräte zu realisieren. Die Web-Ausgabe wird dabei möglichst generisch gehalten – das heißt, dass es keine unterschiedlichen Prozesse auf den Endgeräten gibt und diese immer den vollen Inhaltsumfang erhalten. Der Browser des Endgeräts ermittelt und entscheidet „eigenständig“ welche Inhalte dargestellt werden. Diese werden via HTML5, Media Queries, JavaScript und CSS3 auf dem Client verarbeitet.

Architekturüberblick:

Bei der klassischen RWD Architektur wird aus den Backendsystemen ein einheitliches Frontend erzeugt, welches als Datenpaket einheitlich an die Endgeräte ausgeliefert wird. Es wird vollständig übertragen und auf dem Endgerät „ausgepackt“ und verarbeitet. Bei einer generischen Ausgabe werden die Prozesse aus dem Backend übernommen und endgeräteübergreifend dargestellt. Eine Adaption kann nur auf dem Endgerät erfolgen und setzt somit eine umfangreiche Applikationslogik im Frontend voraus. Hieraus ergeben sich Abhängigkeiten, die sich auf die Performance und Stabilität negativ auswirken.

Definition Responsive Web Design + server side components (RESS)

Bei RESS handelt es sich um eine Weiterentwicklung des klassischen RWD-Konzeptes hin zu einer RWD-Lösung mit serverseitigen Komponenten. Hier werden bestimmte Prozesse vom Server übernommen und damit der Browser entlastet, dazu gehören eine Clienterkennung, Aufbereitung und Modifikation von Bildern und die Anpassung der Inhalte. Durch diese serverseitigen Komponenten wird eine Client-Server-Kommunikation abgebildet, welche die spezifischen Eigenschaften des Endgeräts mit Hilfe einer Device Database ermittelt und mit dem Server austauscht. Somit ist der Server in der Lage die angefragten Inhalte endgerätespezifisch auszuliefern. Frontend- und Backendprozesse können sauber gekapselt werden – wodurch eine kontextabhängige Auslieferung an das Endgerät ermöglicht wird.

Bei der RESS Architektur wird in der Regel ein Progressive Enhancement Ansatz gewählt, um eine Basisversion für alle Endgeräte zu definieren. Aufbauend auf dieser Version wird mittels der Device und Feature Detection der Delivery Context ermittelt. Der Delivery Context setzt sich aus den folgenden Parametern zusammen: Hardwarehersteller, Betriebssystem und Browser inkl. der entsprechenden Version. Ausgehend vom jeweiligen Delivery Context kann der Server alle Features für das Endgerät unterstützen.

RESS_Chart_IllustrationB

Architekturüberblick:

Bei der RESS Architektur wird mittels der Device Database der Delivery Context aufgebaut, um Inhalte möglichst optimal für das jeweilige Endgerät aufzubereiten und auszuliefern. Durch die exakte Kenntnis der Eigenschaften des jeweiligen Clients werden nur die Elemente ausgeliefert, die vom Gerät dargestellt werden können. Dazu gehören zum Beispiel Bilder, die bereits auf dem Server passend skaliert wurden.

Damit wird nicht nur die Anzahl der übertragenen Daten deutlich reduziert sondern auch die Performance signifikant erhöht. Zudem müssen auf dem Gerät keine aufwendigen Prozesse gestartet werden – die rechenintensiven Operationen erfolgen ausschließlich auf dem Server. Dies führt zu einer schnelleren Übertragung, weniger Rechenleistung auf dem Endgerät und somit auch zu einem niedrigeren Stromverbrauch.

Tech News #1/2015

 Some links out of the geek bubble:

“What happens when you type into your browser and press enter?” Heard that before? Well, here is what really happens, described in great detail: 
Standards and browser compatibility: http://mobiforge.com/news-comment/standards-and-browser-compatibility
german links:
Wieviel Millimeter sind ein Pixel? Responsive Tool ?http://www.webrocker.de/2015/01/16/liebe-kreativbranche-wir-sollten-reden/
Neuer Browser von microsoft: http://t3n.de/news/project-spartan-microsoft-589745/?utm_content=buffer527fc&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer
Xiaomi setzt auf das Internet der Ding: http://www.zeit.de/digital/mobil/2015-01/xiaomi-smartphone-china-apple
Übersicht zu KPI-Dashboards für Unternehmen: http://t3n.de/news/kpi-dashboards-startups-525365/

Material Design unter der Lupe

material designCredit: Google
http://www.google.com/design/spec/material-design/introduction.html#introduction-goals

Ende Juni 2014 hatte Google im Zuge des Updates auf Android 5 Lollipop Material Design vorgestellt. Damit hat Google zum ersten Mal eine umfassende Designrichtlinie heraus gegeben und für viel Echo gesorgt.
Material Design basiert eindeutig auf bestehenden Trends wie Flat Design und Content First, geht aber noch einige Schritte weiter.
Mein erster Eindruck von den Richtlinien war sehr gut. Und tatsächlich hatte ich auch als bekennender Apple-Fan zum ersten Mal das Gefühl, dass ein Designansatz von Android dem von Apple überlegen sein könnte.

Deshalb wollte ich mir im Folgenden die vier, meiner Meinung nach, wichtigsten Aspekte von Material Design einmal genauer ansehen. Dabei möchte ich herausfinden was sie besonders macht, und wie sinnvoll sie im praktischen Einsatz sind. Continue reading

Software-Update: Sevenval FIT mit neuen Performance Features

Unser aktueller Release Sevenval FIT 14.0.2 enthält eine große Anzahl von Features, Verbesserungen und Fixes, die ihr im Changelog nachlesen könnt.
Besonders zu erwähnen sind die Verbesserungen an der AC Stage: Neben dem neuen fallback effect swap bei nicht vorhandenem slide, unterstützt die Stage nun autosize und funktioniert im OSS Browser.
Des Weiteren haben wir ein neues Performance Feature: Automatisches JavaScript und CSS Inlining, welches sich ganz einfach über die config.xml einschalten lässt. Darüber hinaus haben wir den Delivery Context um request properties wie frontend-url, host und port sowie pointer events und einen allgemeinen CSS prefix erweitert.

 

Weekly #52 – Rolands Rundown – Tech news of the week

Sevenval FIT – Your Tools, Your Rules

Sevenval FIT ist unsere Software für Responsive Webdesign mit Performance-Boost. Die Vorteile unserer Software:

  • Sevenval FIT14 ermöglicht Responsive Webdesign mit Performance-Optimierung
  • Effiziente Erstellung und Betrieb von One Web-Projekten
  • Alle Freiheiten: Kompatibel mit jedem Editor, CMS, Framework und Shop-System

Details und mehr unter: http://developer.sevenval.com/ Your Tools, Your Rules! Your Tools your rules_grafik_