As I suggested in a comment to another answer, there are numerous ways to accomplish this that don't involve deploying server-side code into SharePoint. Here are a few that I could think of, I may have left some out; each have some advantages and possible challenges.
Edit: Chris O'Brien recently published a timely and more thorough blog post about customization issues in general (since they have been evolving over the past couple of years) over on his blog that does a fantastic job of explaining some of these choices while discussing the decisions the SharePoint team have been making as well as those that developers and designers should be making: http://www.sharepointnutsandbolts.com/2015/01/custom-master-pages-and-web-templates-in-office-365--thoughts.html
Now for the details of some various approaches:
- Leaves master pages unmodified, which allows updates from CUs (on premise) or update releases (SharePoint Online) to be applied to your site as soon as they're published by Microsoft
- Possible to implement as a SharePoint Hosted or Provider Hosted App
- Possible to alter built-in UI elements like the ribbon or
- Single JS source file
- This technique is the current Office Dev Patterns and Practices (PnP) recommended guidance for branding and page customization
Relies on page markup that you may not have direct control over
More complex to setup and update than other solutions
Updating content inserted this way requires an update to the source script (some dev/designer intervention needed) Possible to implement a service call to pull the information from a list or file source in a library; this introduces another HTTP Request into the process (disadvantage) but would allow for simplified editing by end/power users (advantage) and allow the page to render and become usable before all the content was retrieved from the server since standard JS data retrieval methods do not block the UI thread (advantage)
2. Modified SharePoint Master Page / Page Layouts
How it works: Use
oslo.master master pages as a starting point and make modifications to copies of them to suite your specific branding/content needs (you should not modify these master pages directly). Upload your version of the master page to your site collections. Reference this page as the master that should be used in your site settings. For more information, I suggest: "Master pages, the Master Page Gallery, and page layouts in SharePoint 2013" on MSDN; SharePoint 2013 Branding and User Interface Design by Randy Drisgill, John Ross and Paul Stubbs; and Pro SharePoint 2013 Branding and Responsive Web Development By Eric Overfield , Rita Zhang , Oscar Medina , Kanwal Khipple
- Relatively simple to implement
- Greater degree of control over markup, content, and styling
- Breaks inheritance from the built-in master pages; updated functionality added by Microsoft will not automatically be applied to your sites when SharePoint is updated
- Requires uploading to and configuring each site collection individually (or requires you to implement a solution that does this in some automated way, perhaps with PowerShell and/or CSOM)
3. Custom Master Page / Page Layouts
How it works: There are some options in how to approach this, but typically you would start by making a regular HTML page that looks like you want, then convert your HTML file into a SharePoint Master page then proceed as in the edited master page description. See all of the resources listed for customizing the built-in master pages for way more information from people who know a lot more about this than I do!
- Greatest control over structure, style, and content
Disadvantages: Same as disadvantages for "Modified SharePoint Master Page / Page Layouts" but with added complexity of building the entire design yourself.
4. Content Editor WebPart with External Source
How it works: Create a text or HTML file that includes all of the markup you want to place in your footer area. Add a Content Editor Web Part to each page where you want the footer to appear and reference your text or HTML file as the content source. You'll need to include appropriate styles with the content (in a
<style> tag, for example) or somewhere in your own CSS style sheets.
- Simplest solution to implement for small number of site pages or single portal pages
- Single source file to update if changes are needed
- Pretty awful for large-scale deployment. Content editor needs to be added to each page with its source set to the referenced file; possible to mitigate this using CSOM/PowerShell solution but you would need to set this up.
5. Content Editor / Script Editor WebPart with inline Source
How it works: Insert a Content or Script Editor WebPart on each page you need your footer information to display. Instead of defining an external source (as in the previous example) define the markup/script contents directly in the web part source via the web part editor dialog.
- Terrible for large-scale deployment: each content/script editor needs to be modified individually -- possible to automate this using CSOM/PowerShell but you would need to implement this.
6. Themes / Composed Looks
How it works: Allows you to specify a custom master page and color scheme that an end user can apply to their site and customize under "Site Settings" > "Change the look" (see this Office how-to article for more information). Setup is a bit laborious, so I will just provide a link to the relevant MSDN documentation on the subject.
- Provides a high degree of control because you are defining your own master page (see advantages for customized master pages)
- Allows end user site admins to configure and preview the changes to their site, as well as combine different color scheme (theme) combinations with different master pages
Disadvantages: There are a number of disadvantages that are well-covered by Heather Solomon at http://blog.sharepointexperience.com/2013/05/when-to-use-a-sharepoint-2013-composed-look/ as well as better instructions than I have given for how to set this all up. To summarize: the changes they make are difficult to manage in large environments, users are allowed to specify their own background images and color schemes (problem for many designers out there), the solutions are difficult to debug, and you need to re-create your master page design to generate the
.preview files but there are enough differences in the formatting and component use to make this a chore (you need to almost repeat yourself... but not almost enough to copy and paste...).
A note on caching and performance: SharePoint is an ASP.NET application under the covers, and ASP.NET in general and SharePoint specifically have a number of tricks for caching the results of most outputs, to include: page outputs, list contents, query results, and large amounts of binary information (such as videos and other file types -- note binary large object (or BLOB) caching is not enabled by default, it must be turned on by the farm admistrator). You can find a MUCH more thorough explanation of the caching options within SharePoint over at Microsoft's Technet site; here is a particularly good article on the subject. These settings cannot be as fine tuned as something like a farm solution using the server-side object model, but they do offer a mature, well-tuned solution that applies to your entire farm and will suffice for the vast majority of content your SharePoint installation delivers.
The reason I mention any of this is to clarify that SharePoint already has many mechanisms for improving performance through caching; it's not really required that you implement a farm solution to have a performant solution when it comes to customization.
I would also add that performance and the perception of performance are two different things. A web page that waits for a bunch of webparts to render on the server will typically be percieved as having much worse performance than a page that makes a bunch of AJAX calls to load the content without blocking the UI, even though the page using AJAX may actually have taken a longer time to complete its work.
I'm certain I've left out many of the problems and possible mitigating techniques to use for each approach, feel free to add to those that you notice.