ASSESSMENT OF CONTENT DELIVERY SERVICES USING PERFORMANCE MEASUREMENTS FROM WITHIN AN END USER CLIENT APPLICATION
A system for measuring and monitoring performance of online content is provided. In one embodiment, the system includes an intermediary device, such as a web proxy, that receives client requests for content, such as requests for web pages. The device obtains the requested content, modifies it by applying one or more performance optimizations, and serves it to the client. The device also inserts code into the content for execution by the client to gather and report data reflecting, e.g., how quickly the client is able to get and process the content. The code includes information identifying the modifications the device made, and this is reported with the timing data, so that the effect on performance can be analyzed. In other embodiments, the device selects one of multiple versions of content, and the inserted code contains information identifying the selected version. The foregoing are merely examples; other embodiments are described herein.
Latest Akamai Technologies, Inc. Patents:
- CDN CONFIGURATION TUNING FOR TRAFFIC SHARE
- Method and apparatus to detect non-human users on computer systems
- Virtual private network (VPN)-as-a-service with delivery optimizations while maintaining end-to-end data security
- SYSTEMS AND METHODS FOR AUTOMATICALLY SELECTING AN ACCESS CONTROL ENTITY TO MITIGATE ATTACK TRAFFIC
- Internet address structure analysis, and applications thereof
This application is a continuation of U.S. application Ser. No. 15/261,026, filed on Sep. 9, 2016, which is a continuation of U.S. application Ser. No. 13/720,636, filed Dec. 19, 2012, which claims the benefit of priority of U.S. Provisional Application No. 61/579,674, filed Dec. 23, 2011. The teachings of all of the foregoing applications are hereby incorporated by reference in their entireties.
This patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of this patent document, as it appears in Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever.BACKGROUND Technical Field
This application relates generally to distributed data processing systems and to the delivery of content to end users over computer networks, and more particularly to the measurement and assessment of content delivery services.Brief Description of the Related Art
Distributed computer systems are well-known in the prior art. One such distributed computer system is a “content delivery network” or “CDN” that is operated and managed by a service provider. The service provider typically provides the content delivery service on behalf of third parties. A “distributed system” of this type typically refers to a collection of autonomous computers linked by a network or networks, together with the software, systems, protocols and techniques designed to facilitate various services, such as content delivery or the support of outsourced site infrastructure. Typically, “content delivery” refers to the storage, caching, or transmission of content—such as web pages, streaming media and applications—on behalf of content providers, and ancillary technologies used therewith including, without limitation, DNS query handling, provisioning, data monitoring and reporting, content targeting, personalization, and business intelligence.
In a known system such as that shown in
Typically, content providers offload their content delivery by aliasing (e.g., by a DNS CNAME) given content provider domains or sub-domains to domains that are managed by the service provider's authoritative domain name service. End user client machines 122 that desire such content may be directed to the distributed computer system to obtain that content more reliably and efficiently. The servers respond to the client requests, for example by obtaining requested content from a local cache, from another content server, from the origin server 106, or other source.
Although not shown in detail in
As illustrated in
The machine 200 shown in
The CDN may include a network storage subsystem for the content providers to store and originate content (sometimes referred to herein as “NetStorage”) which may be located in a network datacenter accessible to the content servers, such as described in U.S. Pat. No. 7,472,178, the disclosure of which is incorporated herein by reference. For live streaming delivery, the CDN may include a live delivery subsystem, such as described in U.S. Pat. No. 7,296,082, and U.S. Publication No. 2011/0173345, the disclosures of which are incorporated herein by reference.
As an overlay, the CDN resources may be used to facilitate wide area network (WAN) acceleration services between enterprise data centers (which may be privately managed) and third party software-as-a-service (SaaS) providers.
Given the ability to configure the CDN servers described above, a wide variety of content delivery features may be implemented in the CDN platform generally and by the CDN servers specifically. For example, a server may be configured to apply modifications to a given web page as it traverses the server (e.g., going from an origin/source to an end-user client) so as to reduce the number of requests the client has to make, to reduce the payload of the content, to accelerate client application processing/rendering, to tailor the content for a particular client device (and its capabilities), or otherwise enhance the performance and functionality of the content. A wide variety of such treatments are known in the art and often referred to as ‘front-end’ web optimizations or as ‘web content’ optimizations.
By way of example, U.S. Publication No. 2011/0314091 describes systems and methods for applying performance-enhancing modifications to web pages, and teachings of this publication are hereby incorporated by reference herein. A dynamic image delivery system is described in U.S. Pat. No. 8,060,581, the content of which are hereby incorporated by reference. U.S. Patent Publication No. 2012/0265853 and U.S. Patent Publication No. 2012/0259942 describes systems and methods for streaming media and for executing a byte-based interpreter in a proxy server that can be used to modify content, to add rights management information and/or watermarks and the like. The content of all of the foregoing patent documents are hereby incorporated by reference in their entireties.
Other performance-enhancing aspects of the CDN platform relate to the ability to intelligently map end-user clients to servers, and to the ability to intelligently route and manage the transmission of content across the network. For example, the CDN may operate a cache hierarchy to provide intermediate caching of customer content; one such cache hierarchy subsystem is described in U.S. Pat. No. 7,376,716, the disclosure of which is incorporated herein by reference. A transport and routing mechanism for arbitrary data flows is described in U.S. Pat. No. 7,660,296, the disclosure of which is hereby incorporated by reference. A system and method for delivery of content using intermediate nodes to facilitate content delivery is described in U.S. Pat. No. 6,820,133, the content of which are hereby incorporated by reference. A global hosting system that can utilize a network map is described in U.S. Pat. No. 6,108,703, the contents of which are hereby incorporated by reference.
There are many ways to measure the performance of web pages (and of a CDN) in a general sense, be it using synthetic monitoring or so-called real-user monitoring from within a browser. However, current performance measurement approaches are limited. It would be desirable to be able to better show the value of individual features or enhancements offered by a CDN on page performance. Furthermore, it is desirable to improve the ability to identify and address performance issues that may be affecting particular features or particular aspects of the CDN platform, or particular kinds of end-user clients (particular browsers or other client applications or particular devices) served by the CDN, or particular combinations of the foregoing. The teachings herein address such needs and offers and other benefits and advantages that will become clear in view of this disclosure.BRIEF SUMMARY
This disclosure describes, among other things, a performance monitoring and measurement system which may be implemented within a CDN. In one embodiment, the system includes an intermediary device, such as a web proxy server, that receives requests for content from clients, such as requests for a web page. The intermediary device obtains the requested content, modifies it (e.g., by applying one or more performance-enhancing optimizations), and serves the modified content to the client. Though not limiting, the modifications are typically products and/or features offered by a service provider managing the intermediary device and/or a content delivery network (CDN) of which the device is a part. Continuing the example, the device also inserts code into the content that will be executed by the client so as to cause the client to gather timing data reflecting how quickly the client gets and is able to process the content for the end-user, and to report that data back to a back-end processing system. The code further includes information identifying the modifications that the intermediary device made. This information is included in the reported data, so that the effect of the modification(s) on performance can be analyzed. The back-end processing system receives the data and processes it so that it can be viewed in a user interface (e.g., visualized in various ways to show the performance improvements associated with the performance features provided by the service provider), analyzed by CDN service provider personnel, and/or fed into mapping/configuration systems in order to tune the operation of the device and the CDN.
In other embodiments, rather than making modifications to the content, the intermediary device can select one of multiple versions of content, and the inserted code can contain information identifying the selected content version, so that performance data can be correlated with content versions selected by the intermediary. In other embodiments, the intermediary device can send the content with or without modification, and the inserted code can contain information relating to or identify the intermediary device, devices from which the intermediary device obtained the content, or information about the client (e.g., characteristics of the client device, etc.), so that performance data can be correlated with these factors.
As those skilled in the art will recognize, the foregoing merely refers to examples provided for purposes of overview and introduction. They do not represent all possible variants or embodiments. Other embodiments are described below. The foregoing is not limiting, and the teachings hereof may be realized in a variety of systems, methods, apparatus, and non-transitory computer-readable media. The appended claims define the subject matter for which protection is sought. It should also be noted that the allocation of functions to particular machines is not limiting, as the functions recited herein may be combined or allocated amongst different machines in a variety of ways.
The disclosure will be more fully understood from the following detailed description taken in conjunction with the accompanying drawings, in which:
The following description sets forth embodiments of the invention to provide an overall understanding of the principles of the structure, function, manufacture, and use of the subject matter disclosed herein. The systems, methods and apparatus described herein and illustrated in the accompanying drawings are non-limiting examples; the scope of the invention is defined solely by the claims. The features described or illustrated in connection with one exemplary embodiment may be combined with the features of other embodiments. Such modifications and variations are intended to be included within the scope of the present invention. All patents, publications and references cited herein are expressly incorporated herein by reference in their entirety.
1.0 Performance Measurement and Monitoring System
It should be noted that the insertion of code can be performed by any intermediary device, and is not limited to the example of CDN proxy servers, which are merely examples. The intermediary might be another device or a software module residing in the communication path between the content origin and the client. Moreover, the client can be any application and is not limited to a browser 306, though that is used herein for illustrative purposes.
As shown in
A visualization system 310 extracts data from the database on-demand and produces charts for display to participating content providers in the service provider extranet web portal.
A control system 312 can be used to process the performance information and identify and address performance issues affecting the operation and performance of the CDN platform. The system may identify, for example, that certain web page optimizations/treatments are causing a problem for a particular content provider or particular category of client (e.g., a client device running a particular browser). It might determine, by way of further example, that a particular set of end-user clients is receiving poor performance because certain proxy servers are functioning sub-optimally, or those proxy servers are being mapped to sub-optimal cache hierarchy parents, or those clients are being mapped sub-optimally to the proxy servers, or otherwise. Using this kind of information, new control information to address the performance issue, in the form of an updated configuration file for example, can be fed back to the proxy server 300 (or to another component of the CDN such as the mapmaker in
2.0 Gathering Performance Data from Browsers
Browsers have varying abilities to gather more detailed data. Many different techniques are available to capture the point in time at which a page becomes “ready” for use by the end-user, and to capture estimates of network time. These techniques are generally browser-specific and known to those skilled in the art. Many of them have been incorporated into general-purpose libraries like jQuery and Boomerang.
Browsers that are compliant with W3C Navigation Timing (referred to herein as “NavTiming”) or Resource Timing (referred to herein as “ResTiming”) specifications offer another option for gathering performance data. These specifications describe a framework via which a browser can directly export page timing data. These specifications specify a framework via which a browser can export timing data about the base page and about embedded objects. As those skilled in the art will appreciate, more information about the specifications can be found at the W3C website.
From the browser's point of view, an HTTP request for a page can be broken into a series of phases: Prompt for unload, Redirect, App cache, DNS, TCP, Request, Response, Processing, and onLoad. A browser implementing the Navigation Timing specification makes available a timestamp (milliseconds since the epoch) at a variety of points in each phase, including the start and stop time of each phase. Notably, five distinct timestamps are made available during the “Processing” phase of the transaction: start time, the time at which the page becomes interactive to the user, the time at which the browser fires the content-loaded event, the time at which the content-loaded event completes, and the time at which the document object model (DOM) is complete in memory. The specification provides more precise definitions for all these events.
The Resource Timing specification provides timing data for each embedded object on a page. A variety of timestamps (including start and stop times) for the phases of Redirect, App Cache, DNS, Request, Response. The level of detail in the Resource Timing specification is available only when the server sending the embedded object includes a particular response header with that object. In the absence of that header, the browser makes available only the end-to-end timing for each embedded object. With a content provider's permission, however, a CDN proxy server can insert the header on any CDN-directed object on a hostname controlled by the same content provider as the base page.
The data available through the Navigation Timing/Resource Timing-compliant browsers may not correlate exactly to that obtained through other approaches described above. Therefore, preferably the system 300 displays results from Navigation Timing data separately from non-Navigation Timing data.
This section describes example implementations of the system components.
If used, this body of code can be inlined directly as the first element of the <head> section in the content provider page.
3.1.2 Site Beacon
3.1.3 Beacon Data
The beacon payload may vary, but for illustrative purposes, an example of a base set of information to be carried is tabulated below. All the NavTiming data is expressed as the delta in milliseconds between the domainLookupStart timestamp and some other NavTiming timestamp. Absolute timestamps can be used, but are not preferred since they are based on the end-user's clock. To use absolute timestamps, though, the raw domainLookupStart time can be sent back, in addition to the other data. The NT column indicates whether or not the datum is derived from the NavTiming data, which clarifies what data would be received from non-NT browsers. All integers are signed in this implementation. The back-end 308 can discard malformed data such as strings in the integer columns or strings of excessive length.
3.2 Beacon Rate Control
The design described herein gives control over the beacon insertion rate to the content provider or the service provider. The insertion rate is controlled because the beacon has the potential to impact page performance and so the content provider will likely want to restrict it to a fraction of all page loads. Further, the beaconed data has the capability of overwhelming the back-end system 308 with data; restricting the insertion rate is a way to control load on the back-end system 308.
Rates can be set depending on the page being delivered, the type of client device (e.g., OS, browser, device type such as mobile) requested the page. Beacon insertion rates may also be controlled by whether or not the proxy server is applying some feature (e.g., a web content optimization) to the page.
3.3 Configuration and Insertion of the Code
Edge node-supported code is used to insert the body of asbw.js immediately after the <head> tag in the page markup language.
- A method for selecting pages into which the beacon should be inserted. It can support controls by filename, path, and extension.
Configuration might be controlled on many parameters beyond those above: cookies, A/B testing, specific browser types, geographies, and so on.
For illustration (only),
From this (and again only for illustration), the configurator might generate metadata control information that looks like the following pseudo-code:
In a preferred embodiment, the system maintains a base rate of beacon insertion and then for certain content-provider-specified categories of traffic, it increases the insertion rate so as to ensure the sample size of data for those categories is sufficiently large to be useful (e.g., high resolution, statistically significant) in performance analyses. To accomplish this, in one embodiment the system activates the beacon insertion function on all pages of a content provider's site, except for a set of pages that the content provider can optionally specify to be excluded. As the CDN serves pages to clients, the system maintains the beacon insertion rate within certain bounds. Since the CDN is serving the pages to end-user clients, the CDN knows the historical page-request rate and the capacity of the back-end system 308 to handle the performance data that will be sent by the beacons. The CDN can use these two pieces of information set the beacon insertion rate within acceptable bounds, e.g., so that the back-end 308 is not overwhelmed. Through the portal, the content-provider can specify that particular traffic categories of interest (e.g., certain geographies, browsers, feature sets, etc.), and the CDN can increase the beacon insertion rate for those categories. For example, as a given proxy server 302 in the CDN fields client requests, it will determine whether a given request falls within a particular category (e.g., by mapping client IP address to geography, by examining the user-agent header to determine browser or other client device characteristic, or any such technique known in the art). For requests falling within the category, the proxy server 302 inserts beacons at a particular rate ‘N’. For requests falling outside the category, the proxy server 302 inserts beacons at another rate ‘M’, which would usually be lower than ‘N’.
3.4 Delivery of Sitebeacon.js
The configuration that delivers sitebeacon.js to the browser is an object delivery service of the CDN service provider.
In the current embodiment, an infrastructure (servers, databases, software, APIs, and so forth) is used for receiving beacon data generated from end-user clients 306. The beacon data is sent from the browser by executing an http GET on a hostname private to the company collecting the data; that hostname points to the back-end 308. The configuration validates any associated authentication token and sends a download receipt to additional back-end infrastructure, where it is consumed by a processing engine that writes the data to a database.
Recall the wireframe diagram of the configuration page shown in
The visual layout of the console might include a set of tabs via which various different graphs can be selected. The interface preferably supports the metrics listed below, in one embodiment. In each case, the portal user can have the option of selecting subsets of these parameters to be displayed on the same graph, and of saving that report definition for future use.
- NavTiming average page-ready timing data: A graph giving average values for page-ready timing metrics that the customer might be interested in. These will be line graphs with time on the X axis. Some parameters of interest are:
- End-to-end time: defined as loadEventEnd—domainLookupStart
- Onload event time: loadEventStart—domainLookupStart
- DOM complete time: domContentLoadedEventStart—domainLookupStart
- Page interactive time: domInteractive—domainLookupStart
- Download compete time: responseEnd—domainLookupStart
- NavTiming 90th percentile page-ready timing data: the same graph as above, calculating the 90th percentile values of the metrics rather than the averages.
- Non-NavTiming average page-ready timing data: A graph with time on the X axis and three lines:
- Estimated round trip time from client to edge proxy: elapsed time to fetch the test object, if any such object has been configured
- Non-NavTiming 90th percentile page-ready timing data: the same graph as above, calculating 90th percentile values of the metrics rather than averages.
- Sample counts: a count of the number of samples that went into the plots being displayed, for both NavTiming and non-NavTiming plots, as specified by the current filter.
- NavTiming page load phase breakdown: a graphic showing the average values for the components of the HTML transfer, as shown in
- NavTiming average page-ready timing data: A graph giving average values for page-ready timing metrics that the customer might be interested in. These will be line graphs with time on the X axis. Some parameters of interest are:
The infrastructure provides support for reporting and viewing the data by population group rather than globally. All of the visualizations mentioned in the above section may be available broken down along the following axes:
- Country-level geography, and/or state- or metro-area-level.
- Connection speed category
- Connection type (e.g. cable, DSL, mobile)
- Platform (e.g. iPhone, Android, Windows, Linux_×64) as returned in the platform field of the beacon data.
- Browser+version (e.g., IE9), or just browser (e.g., IE), or if neither of those is possible, User Agent.
Each of these can be selected independently of the others, making all combinations possible.
4.0 Custom Beacon Fields
- What web content optimizations the proxy server 302 applied to the page. As previously described (and as noted in U.S. Publication No. 2011/0314091), a wide variety of performance-enhancing modifications can be automatically applied to a page (or other content). Specific examples of such treatments include in-lining content, resource consolidation, minification, image optimization, domain sharding, version control for cacheability, just-in-time loading, adjusting the time at which page scripts are run, device-adaption modifications, and so on. Other treatments might involve compression and/or de-duplification of content. The proxy server can embed identifiers in the beacon to indicate what content optimization treatments it applied to the page, or more generally, what features of the server and CDN (e.g., possibly corresponding to products offered by the CDN) were engaged when processing the page. The resulting data can be interpreted and visualized to indicate the effect of particular optimizations/features and combinations thereof on each page of a content provider.
- What version of a page was selected and delivered by the proxy server 302. Thus the variable could indicate whether an A or B side of a test was executed at any given page load.
- Information relating to the proxy server 302, the CDN platform, and/or delivery circumstances. For example, the information can include an identifier for the given proxy server, or for the CDN region or point-of-presence of the CDN within which the proxy server resides. Further, information about where the proxy server 302 fetched the page (e.g., from local cache, from a particular cache-hierarchy parent or PoP, from NetStorage, or from a content-provider-managed-origin server, etc.) Note that this information might also reflect where the proxy server 302 has or will fetch embedded objects on the page, and thus be useful in assessing performance related to the delivery of embedded objects. The information might also identify which intermediate nodes within the CDN are being used for routing content (the page or the embedded objects) to the proxy server for delivery to the client. The resulting data can be interpreted and visualized to indicate whether certain servers or clusters or network functions are presenting performance issues. The data can also be sliced to focus on particular clients or categories of clients (e.g., certain browsers, mobile devices, etc.).
- Information relating to the client and/or determined from the client's request. In addition to client IP address and other client identifiers, information derived from client request headers can be included in the beacon. Examples include a determination of geography based on client IP address, and a determination of client device identity or characteristics based on, e.g., the user agent. In the latter case, the proxy server can run an edge device identification module that ingests the user agent given by the client with its initial request for content, and based thereon returns a client device identifier (i.e., which may be an identifier internal to the CDN) and/or characteristics of the device like operating system, physical dimensions, etc. The resulting performance data can be interpreted and visualized to indicate the performance (or lack thereof) for certain clients or categories thereof.
To enable the insertion of custom values, the proxy server's request processing function may expose internally what features it had applied to any given page load. The server could include these variables as internal uses of the custom beacon fields feature.
Visualization based on these fields can be made available to network operations personnel (e.g., in the NOCC) as well as content providers on the portal. The information can be used to validate the effect of features, to make recommendations about configuration of the features that the content provide has signed up for, and/or making changes to the content itself, to improve performance.
5.0 Conversion Rate Tracking
In a further embodiment, the system 300 can be extended beyond performance and into conversion rates. The portal could allow commerce content providers to specify that certain URLs or combinations of URLs indicate that a conversion event (e.g., an online sale) occurred, and the visualization system might give feedback on conversion rates as a function of performance or as a function of certain CDN features.
6.0 Use of Computer Technologies
The clients, servers, and other computer devices described herein may be implemented with conventional computer systems, as modified by the teachings hereof, with the functional characteristics described above realized in special-purpose hardware, general-purpose hardware configured by software stored therein for special purposes, or a combination thereof.
Software may include one or several discrete programs. A given function may comprise part of any given module, process, execution thread, or other such programming construct. Generalizing, each function described above may be implemented as computer code, namely, as a set of computer instructions, executable in one or more processors to provide a special purpose machine. The code may be executed using conventional apparatus—such as a processor in a computer, digital data processing device, or other computing apparatus—as modified by the teachings hereof. In one embodiment, such software may be implemented in a programming language that runs in conjunction with a proxy on a standard Intel hardware platform running an operating system such as Linux. The functionality may be built into the proxy code, or it may be executed as an adjunct to that code.
While in some cases above a particular order of operations performed by certain embodiments is set forth, it should be understood that such order is exemplary and that they may be performed in a different order, combined, or the like. Moreover, some of the functions may be combined or shared in given instructions, program sequences, code portions, and the like. References in the specification to a given embodiment indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic.
Computer system 600 includes a processor 604 coupled to bus 601. In some systems, multiple processor and/or processor cores may be employed. Computer system 600 further includes a main memory 610, such as a random access memory (RAM) or other storage device, coupled to the bus 601 for storing information and instructions to be executed by processor 604. A read only memory (ROM) 608 is coupled to the bus 601 for storing information and instructions for processor 604. A non-volatile storage device 606, such as a magnetic disk, solid state memory (e.g., flash memory), or optical disk, is provided and coupled to bus 601 for storing information and instructions. Other application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or circuitry may be included in the computer system 600 to perform functions described herein.
Although the computer system 600 is often managed remotely via a communication interface 616, for local administration purposes the system 600 may have a peripheral interface 612 communicatively couples computer system 600 to a user display 614 that displays the output of software executing on the computer system, and an input device 615 (e.g., a keyboard, mouse, trackpad, touchscreen) that communicates user input and instructions to the computer system 600. The peripheral interface 612 may include interface circuitry and logic for local buses such as Universal Serial Bus (USB) or other communication links.
Computer system 600 is coupled to a communication interface 616 that provides a link between the system bus 601 and an external communication link. The communication interface 616 provides a network link 618. The communication interface 616 may represent an Ethernet or other network interface card (NIC), a wireless interface, modem, an optical interface, or other kind of input/output interface.
Network link 618 provides data communication through one or more networks to other devices. Such devices include other computer systems that are part of a local area network (LAN) 626. Furthermore, the network link 618 provides a link, via an internet service provider (ISP) 620, to the Internet 622. In turn, the Internet 622 may provide a link to other computing systems such as a remote server 630 and/or a remote client 631. Network link 618 and such networks may transmit data using packet-switched, circuit-switched, or other data-transmission approaches.
In operation, the computer system 600 may implement the functionality described herein as a result of the processor executing code. Such code may be read from or stored on a non-transitory computer-readable medium, such as memory 610, ROM 608, or storage device 606. Other forms of non-transitory computer-readable media include disks, tapes, magnetic media, CD-ROMs, optical media, RAM, PROM, EPROM, and EEPROM. Any other non-transitory computer-readable medium may be employed. Executing code may also be read from network link 618 (e.g., following storage in an interface buffer, local memory, or other circuitry).
26. A proxy server in a content delivery network (CDN) for measuring the performance effect of modifications applied to given content as part of the delivery of the content to the client, the proxy server comprising:
- a network interface for receiving a request for a markup language file for a web page, the request being received from a client;
- circuitry forming one or more processors and memory holding instructions to be executed by the one or more processors to cause the proxy server to respond to the request by: obtaining the markup language file from any of a source computer and a local cache that stores a copy of the markup language file previously obtained from the source computer; applying a particular feature of the proxy server when processing the request, the particular feature corresponding to a product offered by the CDN to content provider customers; in addition to said application of said particular feature, inserting code in the markup language file for execution by the client when processing the markup language file, wherein execution of the code will cause the client to gather timing information reflecting the client's processing of the markup language file in order to display the web page, and will cause the client to transmit the timing information in a beacon to any of the computer apparatus and another computer; sending the markup language file with the inserted code to the client, in response to the request; wherein said code includes an identifier that identifies the particular feature that the proxy server applied in when processing the request, the code specifying that the identifier will be transmitted with the timing information as a field in the beacon.
27. The proxy server of claim 26, wherein the client comprises a web browser.
28. The proxy server of claim 26, wherein the markup language file comprises an HTML file.
30. The proxy server of claim 26, wherein the timing information includes information specified in the Navigation Timing or Resource Timing specification.
31. The proxy server of claim 26, wherein the timing information includes one or more timestamps for a processing phase at the client.
32. A method performed by a proxy server in a content delivery network (CDN) that comprises a network interface, circuitry forming one or more processors, and memory holding instructions for execution by the one or more processors to effect the method, the method comprising:
- receiving a request for a markup language file for a web page, the request being received from a client;
- in response to the request, the proxy server: obtaining the markup language file from any of a source computer and a local cache that stores a copy of the markup language file previously obtained from the source computer; applying a particular feature of the proxy server when processing the request, the particular feature corresponding to a product offered by the CDN to content provider customers; in addition to said application of said particular feature, inserting code in the markup language file for execution by the client when processing the markup language file, wherein execution of the code will cause the client to gather timing information reflecting the client's processing of the markup language file in order to display the web page, and will cause the client to transmit the timing information in a beacon to any of the computer apparatus and another computer; sending the markup language file with the inserted code to the client, in response to the request; wherein said code includes an identifier that identifies the particular feature that the proxy server applied in when processing the request, the code specifying that the identifier will be transmitted with the timing information as a field in the beacon.