Optimización del rendimiento de los sitios y aplicaciones de eBay para una user experience más rápida.
The speed was a enterprise-wide initiative for eBay in 2019, with many teams determined to make the site and apps as fast as possible for users. In fact, For every 100 milliseconds improvement in search page load time, eBay saw a 0.5% increase in the "Add to Cart" count.
100em
Improved loading time
0,5%
Increased "Add to Cart" count
By adopting Performance Budgets (derived after conducting a competitive study with the Chrome User Experience Report) y un enfoque en métricas clave de rendimiento centradas en el Username, eBay pudo realizar mejoras significativas en la velocidad del sitio.
EBay speed improvements.
… And your data from the Chrome User Experience Report also highlights these improvements.
Chrome User Experience Report data for First Contentful Paint and First Input Delay for eBay.com source.
There is still more work ahead, but here are the eBay learnings so far.
«Cortes» de rendimiento Web
The improvements eBay made were made possible by the downsizing or "cuts" (in size and time) of various entities involved in a user's journey. This post covers topics that are relevant to the web developer community in general, rather than eBay specific topics.
Reduce payload on all text resources
Una forma de hacer que los sitios sean rápidos es simplemente cargar menos código. eBay redujo la carga útil de texto recortando todos los bytes innecesarios y no utilizados de las respuestas de JavaScript, CSS, HTML y JSON que se ofrecen a los usuarios. Anteriormente, con cada nueva función, eBay seguía aumentando la carga útil de sus respuestas, sin limpiar lo que no se usaba. Esto se acumuló con el tiempo y se convirtió en un cuello de botella de rendimiento. Los equipos generalmente postergaban esta actividad de limpieza, pero te sorprendería cuánto ahorró eBay.
The "cut" here is the wasted bytes in the response payload.
Optimización de la ruta crítica para el contents de la mitad superior de la página
Not all pixels on the screen are equally important. The content above the fold it is more critical than something below the fold. Native and web applications are aware of this, but what about services? EBay's service architecture has a layer called
Experience services, with which the frontends (native applications and web servers) talk. This layer is specifically designed to be view- or device-based, rather than entity-based, such as items, users, or orders. Then eBay introduced the concept of the critical path for Experience Services. When a request comes to these services, they work to get the content data from the top half of the page immediately, calling other upstream services in parallel. Once the data is ready, it is instantly deleted. The data at the bottom of the page is sent in a later chunk or lazy-loaded. The result: users can see content in the top half of the page faster.
The "cutoff" here is the time the services spend displaying relevant content.
Image optimizations
The images are one of the biggest contributors to page bloat. Even small optimizations are very useful. eBay made two optimizations for the images.
First, eBay standardized the WebP image format for search results across all platforms, including iOS, Android, and supported browsers. The search results page is the page with the most images on eBay, and they were already using WebP, but not in a consistent pattern.
Imágenes WebP que se muestran en browsers compatibles en eBay.com.
Second, although the eBay listing images are highly optimized (both in size and format), the same rigor was not applied to the selected images (for example, the top module in the
Homepage). eBay has many hand-picked images, which are uploaded through various tools. Previously optimizations were uploader dependent, but now eBay enforces the rules within tools, so all uploaded images will be optimized appropriately.
The "cut" here is wasted image bytes sent to users.
Predictive pre-acquisition of static assets
A user session on eBay is not just a page. It is a flow. For example, the flow can be a navigation from the home page to a search page to an item page. So why aren't the pages in the flow helping each other? That's the idea of predictive prefetch, in which one page pre-fetches the static assets needed for the next probable page.
Con la captación previa predictiva, cuando un usuario navega a la página prevista, los activos ya están en la cache of browser. Esto se hace para los activos de CSS y JavaScript, donde las Url se pueden recuperar con anticipación. Una cosa a tener en cuenta aquí es que solo ayuda en la primera navegación. En navegaciones posteriores, los activos estáticos ya estarán en la caché.
The "cutoff" here is the network time for the static CSS and JavaScript assets on the first navigation.
Previous obtaining of the best search results
When a user searches eBay, eBay analytics suggests that the user is highly likely to navigate to an item in the top 10 search results. So eBay now fetches the items from the search and keeps them ready for when the user browses. Pre-uptake occurs on two levels.
El primer nivel ocurre en el lado del server, donde el servicio de elementos almacena en caché los 10 elementos principales en los resultados de búsqueda. Cuando el usuario accede a uno de esos artículos, eBay ahora ahorra tiempo de procesamiento en el servidor. El almacenamiento en caché del lado del servidor es aprovechado por aplicaciones nativas y se implementa globalmente.
El otro nivel ocurre en la caché del navegador, que está disponible en Australia. La captación previa de elementos fue una optimización avanzada debido a la naturaleza dinámica de los elementos. También tiene muchos matices: impressions de página, capacidad, artículos de subasta, etc. Puedes aprender más sobre esto en LinkedIn Performance Engineering Meeting Presentation, o permanezca atento a una publicación de Blog detallada sobre el tema de los ingenieros de eBay.
The "cutoff" here can be server processing time or network time, depending on where the item is stored.
Eager download of search images
On the search results page, when a high-level query is issued, two things happen. One is the retrieve / sort step, where the most relevant items that match the query are returned. The second step is to augment the recalled items with additional information related to the user context, such as shipping costs. eBay now immediately sends the first 10 item images to the browser in a snippet along with the header, so downloads can start before the rest of the markup arrives. As a result, images will now appear faster. This change is implemented globally for the web platform.
The "cutoff" here is the download start time for images from search results.
Edge caching for autosuggestion data
When users type letters in the search box, suggestions appear. These suggestions do not change for letter combinations for at least one day. They are ideal candidates to be cached and served from a CDN (for a maximum of 24 hours), instead of requests reaching a data center. International markets especially benefit from CDN caching.
Sin embargo, había una trampa. eBay tenía algunos elementos de personalización en la ventana emergente de sugerencias, que no se pueden almacenar en caché de manera eficiente. Afortunadamente, no fue un problema en las aplicaciones nativas, ya que la user interface para la personalización y las sugerencias se podían separar. Para la web, en los mercados internacionales, la latencia era más importante que el pequeño beneficio de la personalización. Con eso fuera del camino, eBay ahora tiene autosugestiones servidas desde un caché de CDN a nivel mundial para aplicaciones nativas y mercados no estadounidenses para eBay.com.
The "cutoff" here is network latency and server processing time for automatic suggestions.
Edge caching for unrecognized home page users
For the web platform, the content of the home page for unrecognized users is the same for a particular region. These are users who are using eBay for the first time or starting a new session, so there is no personalization. Although the creatives on the home page change frequently, there is still room for caching.
eBay decided to cache unrecognized user content (HTML) on its perimeter network (PoPs) for a short time. New users can now get home page content from a nearby server, rather than a distant data center. eBay is still experimenting with this in international markets, where it will have the greatest impact.
The "cut" here is again both network latency and server throughput time for unrecognized users.
Optimizations for other platforms
Native app analysis improvements
Las aplicaciones nativas (iOS y Android) se comunican con los servicios de backend cuyo formato de respuesta suele ser JSON. Estas cargas útiles JSON pueden ser grandes. En lugar de analizar todo el JSON para representar algo en la pantalla, eBay introdujo un algorithm de análisis eficiente que optimiza el contenido que debe mostrarse de inmediato.
Users can now view content faster. Also, for the Android app, eBay starts initializing the search view controllers as soon as the user starts typing in the search box (iOS already had this optimization). Previously, this happened only after users hit the search button. Now users can access their search results faster. The "cutoff" here is the time devices spend displaying relevant content.
Native app startup time improvements
This applies to fresh start Time optimizations for native applications, in particular Android. When an application is cold started, a large amount of initialization occurs at both the operating system and application levels. Reducing the initialization time at the application level helps users see the home screen faster. eBay did some profiling and noted that not all initializations are necessary to display content and that some can be done lazily.
More importantly, eBay noted that there was a third-party analysis call blocking that delayed display on the screen. Removing the blocking call and making it asynchronous further helped cold start times. The "cut" here is unnecessary startup time for native applications.
Conclusions
All of eBay's performance "cuts" collectively helped move the needle, and they happened over a period of time. Releases were phased in over the course of the year, with each release dropping tens of milliseconds, eventually reaching the point where eBay is now:
The impact of eBay's speed efforts on its field metrics over time, as illustrated by the Chrome UX Report Dashboard.
El rendimiento es una característica y una competitive advantage. Las experiencias optimizadas conducen a una mayor participación del usuario, conversiones y ROI. En el caso de eBay, estas optimizaciones variaron desde cosas que requirieron poco esfuerzo hasta algunas que fueron avanzadas.
Check out Speed per thousand cuts for more information and to keep an eye out for more detailed articles from eBay engineers on their performance work in the near future.
